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/
