Protecting sensible algorithms from reverse-engineering (Win32)

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

Reply to
Anonymous
Loading thread data ...

I meant sensitive, of course. ;)

We propably have to create to workspaces (Visual C++ 6.0). The R&D version would include both R&D and common resource files, the after sales/training/demo version only the common, "non-secret" one. Or is there some other way to do this? Anon

Reply to
Anonymous

Having the device act a coprocessor through USB is not an option I guess. Such the algorithm would never leave the hardware.

Rene

--
Ing.Buero R.Tschaggelar - http://www.ibrtses.com
& commercial newsgroups - http://www.talkto.net
Reply to
Rene Tschaggelar

version

If the algorithm contains tables, you can encrypte the tables with the output a of dongle. It makes static reverse engineering more difficult.

Wim

Reply to
Wim Ton

...

If it can be run, it can be reversed.

If you are going to distribute it, your best bet is probably to entertwine it w/ some sort of encryption routine (this may be true w/ the physical device, too), since it makes you more highly protected under drm laws (IIRC).

Reply to
anon luker

Okay - First of all, it does not matter what you do, in any way - if your algorithm has value to someone else, and you release it (even on a secured microcontroller), it will be broken. Of course, a general-purpose PC executable is much more vulnerable than a piece of code in a secured microcontroller.

If it is really critical to your survival that you keep this algorithm secret, then I suggest that you DON'T release the algorithm. How much data transfer is required? How much realtime responsiveness is required? If there are no realtime constraints, and the data rates are reasonably low, you can consider running your algorithms only on your own backend server, as an oracle. Your released Windows code is just a frontend that sends data to the backend you control.

Of course, you can load resources from anywhere. I suggest you compile the "secret" resources into a separate DLL. On application startup, you check for presence of the DLL. If there, you load the special resources, otherwise fallback to the default resources.

I don't read either of the NGs you posted followups to, so if you want to continue this discussion move it back to comp.arch.embedded - since all I'm willing to talk about is the embedded side of it anyway :) (Praise God, I don't write Windows code any more).

Reply to
Lewin A.R.W. Edwards

This is a training program - so instead of teh algorithm, include a table with a set of some precomputed values that correspond to known inputs.

Umm... You should never release debug enabled code anyways.

--
	Sander

+++ Out of cheese error +++
Reply to
Sander Vesik

In message , Sander Vesik writes

Thats funny, sometimes my brain throws an "out of tea exception" and I have to go and boil a kettle.

--
Stephen Kellett
Object Media Limited    http://www.objmedia.demon.co.uk
 Click to see the full signature
Reply to
Stephen Kellett

ElectronDepot website is not affiliated with any of the manufacturers or service providers discussed here. All logos and trade names are the property of their respective owners.