Message-ID: <4B198B26.2030601@nc.rr.com>
Date: Fri, 04 Dec 2009 17:20:22 -0500
From: Ed Gaines <egaines AT nc DOT rr DOT com>
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.1; en-US; rv:1.8.1.23) Gecko/20090812 Thunderbird/2.0.0.23 Mnenhy/0.7.6.666
MIME-Version: 1.0
To: cygwin <cygwin AT cygwin DOT com>, moss AT cs DOT umass DOT edu, cygwin AT cygwin DOT com
Subject: Re: Confusion re: use of rebaseall vs. rebase to relieve BitDefender  woes REDUX
References: <4B18F846 DOT 60300 AT cs DOT umass DOT edu> <4B196F53 DOT 6010603 AT nc DOT rr DOT com>
In-Reply-To: <4B196F53.6010603@nc.rr.com>
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 7bit
Mailing-List: contact cygwin-help AT cygwin DOT com; run by ezmlm
Sender: cygwin-owner AT cygwin DOT com
Mail-Followup-To: cygwin AT cygwin DOT com

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,so.in"
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,so.in > 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,so.in file and retried:

     $ /bin/rebase -d -b 0x61000000 -o 0x20000 -v -T dll,so.in > 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,so.in (!) and reran the
command -- but I didn't feel
good about it :-|

     $ /bin/rebase -d -b 0x61000000 -o 0x20000 -v -T dll,so.in > 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,so.in 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,so.in > 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 dotexe.in > 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 <moss AT cs DOT umass DOT edu> wrote:
>> Dear Ed -- I posted this a couple of days ago under another
>> thread. 
> 
> 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).
> 
>>
>> and
>>
>> /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:       http://cygwin.com/problems.html
FAQ:                   http://cygwin.com/faq/
Documentation:         http://cygwin.com/docs.html
Unsubscribe info:      http://cygwin.com/ml/#unsubscribe-simple