ARM WINCE application, anti-hacker solutions

I'm creating an app for WINCE 6.0 with ARMV4i CPU. I would like to add extra security to my app by using assembly packer. But I couldn't find a good one except UPX (which is too easy to unpack). can anyone point me one?

UPDATE: My target is to protect a WinCE app from cracking and reverse engineering. Please kindly advi开发者_如何学编程ce whatever way to have extra security though no app is 100% secure.

Almost every packer has an unpacker, and when it doesn't it is easy for someone experienced to unpack it manually. You should make an embedded USB/RS232 dongle device and put some important and complex function in it, and then call that from your WinCE device. If you protect your dongle by setting fuses that do not allow reading, then it will be quite hard for someone to break it (even protected memory can be hacked and read, but it will take 10.000$ and hacker will need to have knowledge in many different areas and specific MCUs).

You might want to checkout "nicetext". It is a scheme for converting encrypted data into natural language text, so that it doesn't exhibit the statistal structure of encrypted data. You could create a similar scheme that generates machine code instead of text. You could even pull the machine code snippets from real places, like static link libraries lying around on your machine. The idea would be to:

1. Encrypt the program
2. Apply something like nicetext to convert the encrypted program into machine code.

That would make it look, on the surface, like a valid unpacked executable. Attackers would have to figure out, in the first place, that what looks like machine code generated by a normal compiler, isn't, all before even trying to break the encryption.

There are a few points:

1. This is only an "obscurity" thing. Reversing something like nicetext is easy, once you know to try.
2. You would still need a way to protect the key used to do the decryption, probably involving hardware.
3. Combining this with the other suggestion of moving code off to a hardware device is probably good too.
4. This may all be a bit expensive to implement. Are you sure you need it?