This is the mail archive of the cygwin mailing list for the Cygwin project.

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: Confusion re: use of rebaseall vs. rebase to relieve BitDefender woes REDUX

Alas, I ran the commands as you recommend below, and there is yet no joy
here in Mudville.

I apologize in advance for the length of this -- I'm ignorant, so I don't
know which details I can omit -- but as you'll see when you arrive at the
end, the questions I'm asking are in fact quite few and quite simple. I
hope :-)

Okay, bear in mind that I'd already run the following commands prior to
attempting to use your method:

    $ /bin/rebaseall -b 0x35000000 -v
    $ /bin/peflagsall

I should have asked you in my last email: should I have reloaded cygwin
prior to attempting to use the steps you prescribed in your response?

Anyway, here's what I did, and here're the results (the file "dll,"
contains all the .dll and .so files I dug up running a "find" command
from within the c:\cygwin directory):

    $ /bin/rebase -d -b 0x61000000 -o 0x20000 -v -T dll, > rebase.out
    ./bin/cyglsa64.dll: fixing bad relocations
    FixImage (./bin/cyglsa64.dll) failed with last error = 13

Okay, it makes some sort of intuitive sense that trying to rebase a 64b dll
in a 32b system should be dicey [incidentally, is there a guide somewhere to
these "last error" codes?].  So I removed "./bin/cyglsa64.dll" from
the dll, file and retried:

    $ /bin/rebase -d -b 0x61000000 -o 0x20000 -v -T dll, > rebase.out
    ReBaseImage (./bin/cygwin1.dll) failed with last error = 6

Alas, still no joy.  And this time it's barfing on cygwin1.dll, pretty much
one of the prime dlls I would have thought needed rebasing...  Not sure what
error 6 means, but according to the rebase-3.0.1.README, file:

    If you get any errors due to DLLs being in-use or read-only,
    then take the appropriate action and rerun rebaseall.  Otherwise,
    you run the risk of fork() failing.

But of course, cygwin1.dll IS in use because it underlies ash.exe. So maybe it's to be expected. I removed cygwin1.dll from dll, (!) and reran the command -- but I didn't feel good about it :-|

    $ /bin/rebase -d -b 0x61000000 -o 0x20000 -v -T dll, > rebase.out
    ./bin/tclpip84.dll: skipped because not rebaseable
    ./lib/perl5/vendor_perl/5.10/i686-cygwin/auto/Win32/GUI/Scintilla/SciLexer.dll: skipped because not rebaseable
    ./usr/share/doc/freetype2/VERSION.DLL: skipped because not rebaseable

Now, not knowing any better, I figured I'd better remove the above files,
the ones that didn't get rebased, from dll, prior to using it as input to
the peflags -d0 command; under the completely naive assumption that if they
didn't get rebased, they probably shouldn't have their flags tinkered with,
either.  And then I ran peflags as follows:

    $ /bin/peflags -d0 -v -T dll, > peflags-d.out
    Warning: file is non-executable but has tsaware set (./bin/cyglsa.dll).

Don't know whether that warning's important, but with the confidence born
of total ignorance, I press on:

    $ /bin/peflags -t0 -v -T > peflags-t.out
    Error: could not update pe characteristics (./bin/peflags.exe): Device or resource busy

To the error above, I can only respond, "DOH!"

Okay, now I reboot, re-activate BitDefender's "Advanced Virus Control" (as opposed, I guess, to its sister feature, "Nothing Special Virus Control." And I bring up an rxvt-native window. Windows's annoying little rotating circle cogitates for about 10 seconds before I get a prompt (reproduced below) and attempt to run an "ls" command. Notice that the prompt does not, as is ordinary, show the current directory:

$ ls

Yet more blue spinning circle for about the same length of time, followed by


Yep. That's what i get. Nada.

Just to be safe, I run a few more random commands under both rxvt and
a cygwin bash shell, with precisely the same results.

So at last, the questions:

1) Should I have reloaded cygwin prior to running your command set?

2) Should I have rebased cygwin1.dll from a cmd shell prior to or after
   running your commands?  As follows, perhaps?

      c:> cd \cygwin\bin
      cp cygwin1.dll cygwin1.dll.orig
      cp cygwin1.dll cygwin1.dll.tmp
      /bin/rebase -d -b 0x61000000 -o 0x20000 -v cygwin1.dll.tmp > rebasecyg1dll.out
      cp cygwin1.dll.tmp cygwin1.dll

3) OPTIONAL QUESTION: Odd that I didn't notice before, but you used the -d flag to rebase, which the rebase.3.0.1.README file tells me means "rebase down memory (default: up)." I'm assuming that means that you're proceeding by establishing an upper bound for these libraries and executables (in this case, virtual memory location 0x61000000, or approx. the 1.63 GB mark) and rebasing the zero-th byte of each successive executable or library at a VM address 0x20000 bytes (approx. 131KB) lower than the rebased VM starting address. Am I correct? Any particular reason for rebasing in a downward direction? Why, in other words, did you need to limit the virtual memory address of the cygwin libraries and executables to exist at or below the 1.63GB/0x61000000 virtual memory address limit?

As before, if one or more of the above questions can be answered by
reference to documentation, that will be just fine.  I very much
appreciate the time and patience you've devoted to making my blunders
wise thus far, and I hope not to press my luck :-)

-- Ed

Ed Gaines wrote:
Thanks so much for your response!  A few mop-up questions below. Hope you
don't mind.

Eliot Moss <> wrote:
Dear Ed -- I posted this a couple of days ago under another

My apologies. I thought I'd researched this carefully before posting. Should have cast my net a bit wider, I guess.

Here is the rebase procedure that works for me:

/bin/rebase -d -b 0x61000000 -o 0x20000 -v -T <file with list of dll and so files> > rebase.out

I notice that the rebaseall defaults (assuming I have them correctly) for
the -b and -o flags are:
-b: 0x70000000
-o: 0x10000
Was there some bit of information in particular that caused you to choose
0x61000000 and 0x20000, respectively, or was it a matter of trial and error?
(If you know of a good reference for windows's memory model and layout, feel
free to point me in that direction).


/bin/peflags -d0 -v -T <file with list of dll and so files> > peflags-d.out

Okay, so with the -d0 flag, you're telling peflags to set the dynamicbase flag
to 0 on all specified files - meaning, I guess that these libraries and
executables should NOT be "randomly rebased at load time by the OS?" A naive
question: why wouldn't you want that to occur? (again, if the answer to that
question is too involved, feel free to point me to documentation).

/bin/peflags -t0 -v -T <file with list of exe files> > peflags-t.out

And here the -t0 flag sets the "tsaware" flag to 0 on the specified files --
i.e., the executable/library should not be reconfigured as multi-user. Correct?

I note from microsoft's site that "/TSAWARE is not valid for drivers, VxDs, or
DLLs." But is there some reason you wouldn't want the .exe files to to be
mult-user aware? Other than the fact that on a standalone desktop PC, it wouldn't
really make much sense :-> ?

Note particularly the base and -o values, and be sure the check the output. Also, you have to do all this under ash, etc., and build a list of files first with find (or just list particular directories' files). I found there ae one or two files I had to exclude because rebase halts on them.

Best wishes -- Eliot Moss

Thanks again for your help and patience! And again, a pointer to documentation
will suffice to answer my questions -- particularly if any or all of them would
require a treatise by way of answer ;-)

-- Ed

-- Problem reports: FAQ: Documentation: Unsubscribe info:

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]