![]() ![]() The software which it protects is in high demand in it's market segment, and the client is aware of several competitors actively trying to reverse engineer (without success so far). Since that software was released about 5 years ago, not one new pirate of the product has been found. As best I can tell from profiling and benchmarking, the HASP HL protection only slowed the intensive calculations by about 3%. We added the HASP protection at the same time as a major update to the software, which performs some heavy calculation on video in real time. Their SDK is not very developer friendly, and is quite painful to integrate adding protection with an automated build process (but possible).īefore we implemented the HASP HL protection, there were 7 known pirates who had stripped the dotfuscator 'protections' from the product. The Key even uses a customized USB communication protocol (outside my realm of knowledge, I'm not a device driver guy) to make it difficult to build a virtual key, or tamper with the communication between the runtime wrapper and key. Without a USB key provided and activated by the licensor, the software can not decrypt and hence will not run. Their SDK encrypts and obfuscates your executable & libraries, and allows you to tie different features in your application to features burned into the key. It requires a proprietary USB key fob which acts as the 'license' for the software. I've used their hardware protection method ( Sentinel HASP HL) for many years. Caveats though - their API sucks, documentation sucks, and both of those are great in comparison to their SDK tools. Is there anything else alternative I have? I mean these are some of the things I've thought of but they can all be worked around and or figured out by code analysts given the right time frame. Tons of casting (for obfuscated disassembly). ![]() Pointless dummy calls and trampolines (tons of jumping in disassembly output).Pointless allocations and deallocations (stack changes a lot) Void trampoline(void (*fnptr)(), bool ping = false) Runtime check for debuggers (and force exit if detected) Write my own startup routines (harder for debuggers to bind to) Code obfustication (mangles the disassembly of the binary).Code injection (calling dummy functions before and after actual function calls).Some of the things I've thought of so far are: Now this is a new subject to me, and the internet is not really resourceful for prevention against reverse engineering but rather depicts tons of information on how to reverse engineer Normally I would never condone this behavior myself in my code however the current protocol I've been working on must not ever be inspected or understandable, for the security of various people. I've been contemplating how to protect my C/C++ code from disassembly and reverse engineering. ![]()
0 Comments
Leave a Reply. |
AuthorWrite something about yourself. No need to be fancy, just an overview. ArchivesCategories |