[1.7] rebaseall doesn't solve the problem

Charles Wilson cygwin@cwilson.fastmail.fm
Sat Feb 28 21:19:00 GMT 2009


Corinna Vinschen wrote:
> Uh, ok.  In that case, yes, it needs some tweaking.  Actually, maybe
> the tool should really be named differently.  Something suggesting
> that it in general changes Win32-related PE/COFF header flags.  ASLR
> and TS-aware are just some of them, in theory.

I'm open to suggestions.  "peimgflags"?  Currently, aslr only
manipulates the OPT_IMG_HEADER:DllCharacteristics field (which is a
misnomer, because some of the values apply to exe's).

We might also want to be able to set IMAGE_FILE_AGGRESIVE_WS_TRIM in the
IMAGE_FILE_HEADER:Characteristics field for things like sshd.



As currently coded, it *appears* that neither rebase nor aslr adapt to
the (slightly different) 64bit pe format.  Actually, I think only rebase
is affected by this, because the variations in the format occur past the
OPT_IMG_HEADER:DllCharacteristics offset.

I don't have a 64 bit machine to test on, so I'll have to pass on
"fixing" the imagehelper library used by rebase...

The differences are minor; larger field sizes for some values (and
therefore different field offsets for values past them). Just compare
and contrast IMAGE_OPTIONAL_HEADER32 and IMAGE_OPTIONAL_HEADER64 in
w32api/winnt.h.  From dlltool:

/*  & NumberOfRvaAndSizes.  */
#ifdef pe_use_x86_64
  num_entries = pe_get32 (dll, opthdr_ofs + 92 + 4 * 4);
#else
  num_entries = pe_get32 (dll, opthdr_ofs + 92);
#endif

#ifdef pe_use_x86_64
  export_rva  = pe_get32 (dll, opthdr_ofs + 96 + 4 * 4);
  export_size = pe_get32 (dll, opthdr_ofs + 100 + 4 * 4);
#else
  export_rva = pe_get32 (dll, opthdr_ofs + 96);
  export_size = pe_get32 (dll, opthdr_ofs + 100);
#endif

but I don't think #ifdefs are the way to go. We want to be able to
manipulate 64bit images on a 32bit machine, and vice versa -- based on
the value of the IMAGE_FILE_HEADER:Machine field.

IMAGE_FILE_MACHINE_I386		0x014c	x86
IMAGE_FILE_MACHINE_IA64		0x0200	Itanium
IMAGE_FILE_MACHINE_AMD64	0x8664	x64

Then again, maybe this isn't all that important, as the only 64-bit
image we have is cyglsa64.dll -- and my patch to rebaseall forces it to
skip that one anyway. Everything else in the cygwin distro is strictly
32 bits.

> I have to test if the TS-aware flag makes any difference on
> a 2K8 TS machine anyway.  I think (and hope) that this flag will
> persuade tsappcmp.dll into igoring an executable instead of scrambling
> its page executable protection flags.  If so, we should really set this
> flag in all applications.  Well, not that I gave up the idea that
> Microsoft should fix that bug in tsappcmp.dll in the first place...

Ha!

>> Should I also add a switch to rebaseall that means: ONLY alsr,
>> NO rebasing.  There's already a flag that allows you to add .exe's to
>> the "rebase" list -- but you can't remove dll's and .so's from the list.
> 
> Makes sense to me.

Or a separate aslrall (peimgflags(?)_all) script...it would share a lot
 of code with rebaseall, but it's not really all THAT big a script.  The
reason I didn't do that originally was I wanted to reuse the same
(generated) filelist in each case.  But, it seems that the flexibility
in having aslrall(?) make its own file list -- which may include exe's
as well as dll's -- is more important.

>>> That would also allow to drop the ugly TS hack I added to Cygwin 1.7.
>>> All newly built binaries would have the flag set already, and older
>>> binaries could be tweaked with the aslr utility.
>> That would be nice.  However, ONLY exe's linked with cygwin1.dll should
>> be marked this way, right?  Not cygcheck, strace, and whatever other few
>> exes we might find in the cygwin installation lists.
> 
> Hmm, I'm not sure about that one.  At least only EXEs should be marked
> TS-aware automatically.  The flag has no meaning on DLLs, afaik.
> *Iff* the TS-aware flag helps to avoid tsappcmp.dll entirely, it's a big
> help in all cases.  Cygwin applications are TS-aware by default anyway.
> If somebody actually manages to write a non-TS-aware Cygwin application,
> I'd say this guy should reset the TS-aware flag manually.

Oh, ok.

--
Chuck


--
Unsubscribe info:      http://cygwin.com/ml/#unsubscribe-simple
Problem reports:       http://cygwin.com/problems.html
Documentation:         http://cygwin.com/docs.html
FAQ:                   http://cygwin.com/faq/



More information about the Cygwin mailing list