Comments (19)
  1. Anonymous says:

    This didn’t post until 07:02.  Check the server’s time!!!

  2. PatriotB says:

    Hmm, maybe Raymond manually changed the post time, as it says 7:00 on my screen…

  3. Anonymous says:

    raymond why the hell did you use

    _IsNonwritableInCurrentImage

    in CRT’s code??? Now most of exe-packers wont be able to compress VS8 executables, another great idea from MS, to kill its own market.

  4. Anonymous says:

    People are still using exe packers? What a terrible thought.

  5. Anonymous says:

    People are still using exe packers? What a terrible thought.

    As opposed to worse compression (.ZIP) or installers? Anytime.

    As long as you don’t have to share code, it’s a great idea; with disk I/O being so slow and CPUs so fast, it’s often a speedup. Granted the extracted image will have to be paged back to the swapfile on memory pressure, but it’s usually a speedup. (Relocated DLLs are a much bigger problem with everyone using 0x10000000 as the base address and MS shipping several system DLLs with 0x20000000)

    There are still many applications distributed packed. uTorrent and VirtualDub come to mind.

  6. Dean Harding says:

    How on earth could an exe packer give you better compression than a standalone compressor? You’ve got to at least include the unpacking program uncompressed with your data, so if the algorithm it uses is so great, why wouldn’t you just include the decompressor separately, unpack the exe once and delete the decompressor?

    Once you’ve unpacked the executable, there’s no reason to keep it compressed (and plenty of reasons not to)

  7. Richard McNally says:

    Another quick overview that attmpts to assist in the digestion of those documents is given by Kevin Frei (http://blogs.msdn.com/freik/archive/2005/03/17/398200.aspx)

    I don’t think that ‘-‘ is suggesting that a packer will achieve better compression than a standalone compressor. What I think he’s suggesting is that you could speed up load time.

    This would be possible because with a seperate compressor you still end up having to load an uncomressed image off the disk to execute it. On the other hand a packed EXE could expand itself directly into memory and execute pass execution to its uncompressed version.

    I’m not sure it would be worth it though, it’d probably mean that you have to do some extra work, either calling GetProcAddress a whole bunch of times or implementing some kind of indirect calling scheme for imported functions.

  8. Anonymous says:

    Any clues as to why the x64 compiler doesn’t support inline assembler?  I realize you’re not on the compiler team.  This makes it difficult to use for OS dev…  but tell whoever’s responsible thanks for all those useful intrinsics!

    Mike

  9. Anonymous says:

    Regarding EXE packers, what about copy protection systems like Armadillo?

  10. Anonymous says:

    Adam G. where were you in the past 10 years???

    Get real man, now most of the software (shareware, freeware, even spyware) is packed/protected, even video codecs are protected by exe-protectors and this is common practice.

    And MS with each new OS is trying to make harder and harder to deploy this wonderful software by adding some unnecessary code checks (which can be easily bypassed) while at the same time they’re doing completly stupid things (like a lame DEP patch in WinXP kernel for aspack/starforce/safedisc applications).

  11. Anonymous says:

    Officially, I believe anything using the VC8 runtime MUST use an installer anyway.  Have to add the CRT to the SxS assemblies doodad.

  12. Anonymous says:

    There are compression algorithms specific to binary code that are not always used by general purpose compressors. I believe the Windows 95 compressor attempted to detect and compress relative branches as though they were absolute. And it is not always desirable or even possible to have a separate installer, or to cache the uncompressed copy in persistent storage.

    I was under the impression that the x64 ABI information in the DDK was out of date compared to the SWConventions.doc file in the Bin/win64/x86/AMD64 folder of the Platform SDK. Is this incorrect? SWConventions.doc appears to be newer and has more information. For instance, the DDK says that x87/MMX registers are preserved across context switches; the PSDK clarifies this by saying that they are unusable in kernel mode, but preserved and merely unspecified for user mode. Testing shows that the registers are indeed preserved in user mode. Also, the DDK makes no mention of the requirement for hot-patchable functions (2-byte first instruction + 6 unused bytes prior).

  13. Anonymous says:

    pourpose-made exe packer: http://www.crinkler.net/

  14. Anonymous says:

    Yes, I was implying good EXE packers will defeat ZIP. Why compare against ZIP? Because ZIP is what everybody will be able to decompress.

    EXE packers have entropy reduction filters such as jump converters (as Phaeron said) and have a specialized algorithm specially targeted towards code. See UPX, it beats ZIP every time (even including the decompressor stub, which is tiny).

    Of course there are better compressors, for example both RAR and 7z do have filters for executables, that when combined with their robust general-purpose compression algorithms will give better compression. But you need to either have an application that decompresses them, or make a SFX (self-extractor) (And usually the SFX module is packed too!)

  15. Anonymous says:

    As Raymond mentioned in his post, the MSDN site finally has some decent documentation on the x64 calling…

  16. Anonymous says:

    I use exe packers to save download time, and save the user the hassle of having to decompress it.

  17. Anonymous says:

    I ran into the craziness of the CRT security stuff recently.  I couldn’t use the CRT as-is because my code was not a real PE image (it’s VirtualAlloc’d into memory).  When an exception occurred, it didn’t trust my address and threw a security error up.

    The problem I had was that Microsoft doesn’t disclose the source to the whole CRT – the function I needed to modify, __ValidateEH3RN, was not in the CRT source.  So I had to hex edit the .obj file to get my code to work – not fun at all.

    x64 support was much easier.  RtlAddFunctionTable on the copied .pdata section did the trick.

    Melissa

  18. Anonymous says:

    Why are ecx and edx still used? especially ecx which has very special meaning (rep, jcxz). Why couldn’t they use r12-r16 for example? Fastcall was stupid in 16 bit code, and is even more stupid now.

    More here: http://board.flatassembler.net/topic.php?t=4155

  19. Anonymous says:

    vid, you have to draw the line somewhere.  Every x86 register is special in some way.  edx is an implied target of a 32×32=64 multiply and an implied source of a 64/32=32 divide.

    eax = too many to list

    ebx = xlatb

    ecx = jecxz, rep, shifts

    edx = (i)mul, (i)div, cmpxchg8b

    esp = push, call, SS default

    ebp = enter, leave, SS default

    esi = string ops source

    edi = string ops destination

    ebx is I think the least special of all the registers, but that was long ago defined as nonvolatile.  I’m guessing that it’s a carryover from x86-16, where it was special because you could use it in addressing.

    Melissa

Comments are closed.