PocketMatrix

Try diProtector - software protection against reverse engineering on different platforms for PDA developers (http://www.diprotector.com)

RE: Windows CE file system compression.

Windows CE supports 3 different 'compression' schemes (NONE, XPRESS, and LZX.) Each is a trade-off between decompression speed and compression rate. It's possible to use different schemes on different paritions within the flash, but usually things break down thus:

If the device has NOR flash, we recommend NONE for non-pageable code paritions (so they can XIP,) and possibly XPRESS for other code paritions or maybe still NONE if there is sufficent flash. If the OEM uses NONE all throughout, the entire OS can XIP, in which case there is no page pool, resulting in megabytes of RAM savings against a modest hit in code fetch time.

If the device has NAND flash (and most new ones do,) then compression is highly recommended, as you must block fetch for the flash part anyways.

Now, this really only applies to the OS paritions. I'm not really aware of anyone using compression on the user store parition, or on SD storage. I'll have to check to see if code executing from those paritions is even pageable.

I guess what I'm saying is don't rule out compaction because of the OS. On NAND espicaly, when data fetch is slower, there could be a load time advantage to be had.

It should be noted that a classic packer is different, and has a different purpose usually, than OS-level file system compression.

The way packers work (or at least did last time I wrote one) is to take an executable, and basically encode the entire thing in some fashion (whether compressed, encrypted or both) and then put a "wrapper" executable around that which knows how to decompress the real executable.

I've never dealt with one on any version of Windows, my experience was all back in the DOS days (and the C64 days before that). There, it was pretty easy to do... once you compressed the real executable, your "decompaction" routine would just reverse the process and place the real executable into memory at an appropriate location (like DecompactionRoutineLength+1) and jump to the first instruction. I'm not sure how you do the same thing with a Windows PE, be it desktop or not, but the theory has to be essentially the same.

File system compression on the other hand... wait, it actually is the SAME THING, its just that the decompaction routine is built into the OS. As well as the compaction routine, and both are done on-the-fly.

Still, usually different goals though. Classic compactors were more about obfuscation than space saving.

UPX is now updated to compress WinCE excecutables. Currently it can compress WM2003[se] apps without problems, WM5 apps can be compressed after some manual hacking.