eekee wrote:
Note that the majority of today's commercial software licenses don't give you right of ownership. They only give you a right to use it in the ways they permit, and they always explicitly deny reverse engineering. There are exceptions, of course.
I would argue if that's even legit. I mean I'm not buying a service with a monthly fee, rather something for a single price. As long as I pay the entire price for something, then ownership must be mine. Retaining the ownership wouldn't be the first illegal move on big corps' part... just because they have an armada of lawyers looking for loopholes in law, doesn't make this morally right (but this is very off-topic)
nullplan wrote:
What is the point? I mean, you give the hackers the run-around for a while, but it will only hinder them, not make it impossible for them to understand your code. And it will make your code slower even for all of your legitimate users.
This is very true.
pranavappu007 wrote:
I was wondering, can you encrypt, or obfuscate parts of your code, and decrypt it at runtime and run? On non-OS environment, I think it's easier, as you have to write the function in assembly, and hardcode the encrypted binary as an array or something in the OS code, along with the decryptor and caller.
You can obfuscate without encrypting. For example, instead of
Code:
char hello[12] = "Hello World";
one could do
Code:
char hello[12];
hello[0]='H'; hello[1]='e'; hello[11]=hello[1]-1; hello[2]=hello[3]=hello[10]='l'; hello[4]=hello[7]='o'; hello[5]=' '; hello[6]='W'; hello[8]=hello[7]+2;
This way the executable would be obfuscated, as there would be no clearly readable "Hello World" bitchunk in the binary. Problematic to use, granted, but might be useful to hardcode passwords or encryption keys into executables.
pranavappu007 wrote:
Have you guys ever tried to do stuff like this?
Yes, and it's problematic. It's easier if you put the decrypter in your ELF/PE loader (that way the files are encrypted on disk, but decrypted in memory on load before relocation takes place). Once I had to reverse engineer a virus which used a simple XOR as a cypher on the instructions, but only decrypted a small window around the current IP, so it was a nightmare to debug (it was in the DOS era, long before the NX bit). I've always found Russian coders are very creative about these things. It worth study some of their code (most notably some viruses, they are often polymorphic too).
nullplan wrote:
On Linux, you have fexecve(), so you can do the decryption in a temporary file and just run it.
Not a good idea, because then you'll have the decrypted file on your disk (or tmpfs). It's better if you put the decrypter in the ELF/PE loader as I've said and only decrypt in memory where other processes can't access it.
pranavappu007 wrote:
I was just curious to know what others have to say about this, as I have already found it's a bit higher than my current level. More like about other people experiences of stuff like this. And also opinions like this one.
I've used a simpler approach in my
boot loader. It can load an SHA-XOR-CBC or AES-256-CBC encrypted initrd. On disk, the entire initrd is a bit-sausage, but when booted it becomes clear data, and the kernel is none the wiser. (FYI I place the kernel inside the initrd, so this encrypts the executable as well).
Cheers,
bzt