Possible "reverse engineering"?

Discussion to talk about software related topics only.
Post Reply
premiaware
Posts: 11
Joined: Tue Jun 17, 2008 5:25 am

Possible "reverse engineering"?

Post by premiaware »

Hello, my question is simple, if I sento to my customer the file "XXXX_APP.s19" for update my application, is possible to "reverse engineering" it and understand the logic of operation?

Thank you.
User avatar
lgitlitz
Posts: 331
Joined: Wed Apr 23, 2008 11:43 am
Location: San Diego, CA
Contact:

Re: Possible "reverse engineering"?

Post by lgitlitz »

Hi,

Yes it is possible.... but very, very difficult. Your customer would first have to have good knowledge of the NetBurner environment. The _APP.s19 is a compressed image so they would need to run the application so it is loaded into RAM, then halt the processor and read all the data from RAM. They would then have access to the machine code which can be converted to assembly language. This assembly language will not be very organized for human reading. There are no function / variable names that can be retrieved, these are all replaced with address pointers and constants. If all he is interested in is a small function in your application then reverse engineered is a bit easier but still pretty challenging. If they want to get usable/modifiable source for the whole application then this would likely take a team of engineers a long time to accomplish. It would probably be much easier to write the code they hired you to do rather then reverse engineer your completed application.

You can also add additional security or reverse engineering deterrent to your code. There are tons of different ways to do this and I suggest researching it a bit with Google. One method I like it replacing constants with values pulled from a running hardware timer. For example.... Say you have a big block of computations with no branches that you want to protect. At the beginning of this block of code start a DMA timer. Then replace any constant values in this computation with the running hardware timer count plus the offset needed to equal that constant. So say your constant is 100 and you started the timer 500 clock cycles ago. Then in your code read this timer and subtract 400. Since there are no branches the timer will always be 500 at this point in your code unless someone uses a BDM to step through your application, then the timer will be much higher and your code will not function correctly. It will also make understanding the assembly much more difficult. The draw back here is that modifying any of your code will require readjusting all the timer offsets used for your constants.
Post Reply