I was wondering; I have been trying to find ways to protect an exe from piracy by protecting them from dissaseemblers, hex editing, memory dumpers, ect. It seems like all the info I can find is only direct related to the assembly language this may be good and all but I am trying to make it an encapuslated C++ class to protect your app.
True, its always possible to pass a protection scheme yet, I simply would like to make it harder for someone to pass through it. I was wondering if anyone knew of websites or any techniques at that matter that would help protect applications; that can be implemented into C/C++ source. I also plan to add some type of PE encryption to the app.
So far I have decided to make a checksum on the app some how... And possibly do a few other rountines does anyone have any suggestions or tips they could share?
coder requires 0xf00d before continue().
Killer Eagle Software
Protecting apps from decompilers ect...
You certainly will not be able to secure an app simply by including a class in the EXE. It just doesn''t work that way.
However, it is fully possible to do something similar to UPX; encrypt the actual ASM code, obfuscate the decryption to make it very very difficult to crack. When the program runs, decrypt the ASM into memory, and jump to the address of the decrypted code. You will HAVE to use an external utility to secure apps this way; it cannot be done by compiling in a class. The utility can likely be done mostly in C/C++ but you''ll need ASM for the decrypting stub, etc.
However, it is fully possible to do something similar to UPX; encrypt the actual ASM code, obfuscate the decryption to make it very very difficult to crack. When the program runs, decrypt the ASM into memory, and jump to the address of the decrypted code. You will HAVE to use an external utility to secure apps this way; it cannot be done by compiling in a class. The utility can likely be done mostly in C/C++ but you''ll need ASM for the decrypting stub, etc.
Author
heh Its mainly so I have the functions that will be used throughout the app not really as much encapsulated as it is just a reference sheet.
[edited by - DevLiquidKnight on August 17, 2003 7:31:22 PM]
[edited by - DevLiquidKnight on August 17, 2003 7:31:22 PM]
Here''s an idea.
Encrypt the main program, and have a loader that decrypts it to ram, then creates a process from that RAM (Low-level OS-specific code required). It would be easier to decrypt to a temp file, but that could be accessed a lot easier.
Another way would be to use SMC to decrypt and reencrypt certain parts of your source when the program is active. Again, OS-specific code required (to use SMC).
You could use an external encrypter to encrypt parts of your machine code that the program knows it needs to decrypt before accessing. (Finding the right areas might be a bit difficult, but you might be able to modify a linker to output the required data).
Then distribute the machine code with the encrypted segments. If your code reencrypts (or deletes if it''s not needed again) the protected code, it will be hard for a hacker to dump the memory of the decrypted source currently executing.
You would need to make sure the encryption key and/or algorithm were secure enough, though.
The third idea is to try to jump on the trusted computing bandwagon. But don''t expect your software to be popular if it requires trusted computing, and don''t expect this to guarantee the safety of your code.
Here''s some logic, though:
You generally want the machine executing the most optimised (and therefore not unmangled) machine code.
This machine code sits in the virtual address space of your program.
It is possible to read this code from RAM into a file (if the architecture and software supports something like palladium then this may require some high-tech equipment).
Once on disk, the code can be hex-edited, decompiled, etc, and there''s nothing you can do about it.
Encrypt the main program, and have a loader that decrypts it to ram, then creates a process from that RAM (Low-level OS-specific code required). It would be easier to decrypt to a temp file, but that could be accessed a lot easier.
Another way would be to use SMC to decrypt and reencrypt certain parts of your source when the program is active. Again, OS-specific code required (to use SMC).
You could use an external encrypter to encrypt parts of your machine code that the program knows it needs to decrypt before accessing. (Finding the right areas might be a bit difficult, but you might be able to modify a linker to output the required data).
Then distribute the machine code with the encrypted segments. If your code reencrypts (or deletes if it''s not needed again) the protected code, it will be hard for a hacker to dump the memory of the decrypted source currently executing.
You would need to make sure the encryption key and/or algorithm were secure enough, though.
The third idea is to try to jump on the trusted computing bandwagon. But don''t expect your software to be popular if it requires trusted computing, and don''t expect this to guarantee the safety of your code.
Here''s some logic, though:
You generally want the machine executing the most optimised (and therefore not unmangled) machine code.
This machine code sits in the virtual address space of your program.
It is possible to read this code from RAM into a file (if the architecture and software supports something like palladium then this may require some high-tech equipment).
Once on disk, the code can be hex-edited, decompiled, etc, and there''s nothing you can do about it.
Don't use upx or any other exe packing/encryption program and think it's secure for crackers.
It's really simple to put a breakpoint when the exe is fully unpacked, and then dump the unpacked memory into a file, and then run a disassembler on that.
Another possibility is to rip the unpacking functions of the unpacker and then make an external program that uses the exact same functions, but unpacks to a file instead of into ram.
Microsoft's upcoming security plan NGSCB, formerly known as palladium, might offer some services to encrypt the software and have processor unpack it, but no one seems to know how the concept will actually look like when it's ready.
But a hardware solution is definitely needed for something like that, preferably something that is directly attached to the processor, or a part of the processor. And probably some encryption based on a two keys, so that each processor has a different private key, and a special encrypted program for each computer. A one key solution would only work if the algorithm stayed secret forever, because once it is public, someone will make a decrypter program. And the key that's sent to the processor must be stored somewhere, probably in the exe. So then any program could easilly be decrypted.
But for now just assume you can't hide anything from crackers, you can make it harder for them to find what they are looking for, but never hide anything.
Edit:
I was wrong about NGSCB (next generation secure computing base) Microsoft has released a whole lot of info about it at http://www.microsoft.com/resources/ngscb/default.mspx. But I haven't read it so I can't tell exactly how it will work, or if it will solve those kinds of problems. But according to the short description there, it will.
[edited by - fredizzimo on August 17, 2003 8:30:04 PM]
[edited by - fredizzimo on August 17, 2003 8:31:42 PM]
It's really simple to put a breakpoint when the exe is fully unpacked, and then dump the unpacked memory into a file, and then run a disassembler on that.
Another possibility is to rip the unpacking functions of the unpacker and then make an external program that uses the exact same functions, but unpacks to a file instead of into ram.
Microsoft's upcoming security plan NGSCB, formerly known as palladium, might offer some services to encrypt the software and have processor unpack it, but no one seems to know how the concept will actually look like when it's ready.
But a hardware solution is definitely needed for something like that, preferably something that is directly attached to the processor, or a part of the processor. And probably some encryption based on a two keys, so that each processor has a different private key, and a special encrypted program for each computer. A one key solution would only work if the algorithm stayed secret forever, because once it is public, someone will make a decrypter program. And the key that's sent to the processor must be stored somewhere, probably in the exe. So then any program could easilly be decrypted.
But for now just assume you can't hide anything from crackers, you can make it harder for them to find what they are looking for, but never hide anything.
Edit:
I was wrong about NGSCB (next generation secure computing base) Microsoft has released a whole lot of info about it at http://www.microsoft.com/resources/ngscb/default.mspx. But I haven't read it so I can't tell exactly how it will work, or if it will solve those kinds of problems. But according to the short description there, it will.
[edited by - fredizzimo on August 17, 2003 8:30:04 PM]
[edited by - fredizzimo on August 17, 2003 8:31:42 PM]
hi guys
i have a program(write in delphi) that protect by unknown protector
the header of file begins with "MZp"(common pe32 have MZ section)
and i use most common deprotector an decompreesor that i know
(deshrink,upx,unpack,,....)
pleas help what can i do?
i have a program(write in delphi) that protect by unknown protector
the header of file begins with "MZp"(common pe32 have MZ section)
and i use most common deprotector an decompreesor that i know
(deshrink,upx,unpack,,....)
pleas help what can i do?
Clueless necro by cracker. Closed.
AP: if you wanna re-ask your question, feel free to start a new thread (most likely in the Lounge) to do so.
"Sneftel is correct, if rather vulgar." --Flarelocke
AP: if you wanna re-ask your question, feel free to start a new thread (most likely in the Lounge) to do so.
"Sneftel is correct, if rather vulgar." --Flarelocke
This topic is closed to new replies.
Advertisement
Popular Topics
Advertisement
