We are planning to create a MS-Windows simulation of an embedded product for after-sales/training usage. The actual embedded product contains some sensible algorithms, which we would like to protect from reverse engineering, because we suspect that the Windows app might spread outside of company. In the embedded product, sensible algorithms are no problem, because the microcontroller has internal mask-ROM.
What should we do to protect the algorithms in Windows environment? This is what comes to my mind:
- create "dummy" versions of the algorithms for windows simulation. Put them under some precompiler flag. The dummy algorithms are good enough for after sales/training, because after sales mainly focus on the UI and general functions of the product. If someone reserse-engineers them from exe, all they found is some trivial code.
- compile the executable to release mode, so there will be no debugging information (=source codes) in the exe
- Dongle protection? Well, I guess this wouldn't stop anyone from reverse-engineering anything, because they still can disasseble the exe, even though they may not be able to run it?
We already have the Windows simulation for R&D usage, so we just have to strip down some code from there. In Windows simulation UI, we also have some debugging windows/dialogs, which indicate the internal state of the embedded SW, variable values etc. We have to strip also this UI stuff away. What is the easies way to do it? Put all R&D only purpose windows/dialogs to seperate resource file, and all common UI stuff to common resource file?
Can Windows application have more than one resource file? We really don't want to create two versions of resource files, so splitting resources to R&D only and common would be nice from SW maintenance point of view.
Any comments? Anonymous
Follow-ups to Windows programming newsgroups