Protecting sensible algorithms from reverse-engineering (Win32)

Do you have a question? Post it now! No Registration Necessary

Translate This Thread From English to

Threaded View
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

Re: Protecting sensible algorithms from reverse-engineering (Win32)

Quoted text here. Click to load it

I meant sensitive, of course. ;)

Quoted text here. Click to load it

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



Re: Protecting sensible algorithms from reverse-engineering (Win32)

Quoted text here. Click to load it

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

Re: Protecting sensible algorithms from reverse-engineering (Win32)

Quoted text here. Click to load it
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



Re: Protecting sensible algorithms from reverse-engineering (Win32)
Quoted text here. Click to load it
...<snip>

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).

Re: Protecting sensible algorithms from reverse-engineering (Win32)
Quoted text here. Click to load it

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.

Quoted text here. Click to load it

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).

Re: Protecting sensible algorithms from reverse-engineering (Win32)
Quoted text here. Click to load it

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.

Quoted text here. Click to load it

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

--
    Sander

+++ Out of cheese error +++

Re: Protecting sensible algorithms from reverse-engineering (Win32)
Quoted text here. Click to load it

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
We've slightly trimmed the long signature. Click to see the full one.

Site Timeline