Including a pre-compiled image in a project

[estersci2]

Posted on October 05, 2015 at 21:35

Hi,

I am interested in including a sort of fake secure bootloader in my application on the usart, which would purport to offer the option to download the firmware image, but which would actually serve up a fake image that looked like the genuine article, but would reac havoc in the marketplace for my adversary.My product includes several components that are sensitive to manufacturing process variances that have to be calibrated, thus it is possible to lock the image to a product signature that cannot be replicated to match the partially encrypted firmware, but I would like to go one step further as outlined above.So my question is, is there a way, with keil, that I can create a project, compile it, and then include the binary image to be flashed as part of a second larger project in a known location as dead (unexecuted) code, which my fake bootloader could then stream out to my adversary purporting to be the image (whilst at the same time blowing a few holes in the genuine image)? Sorry if it sounds a bit mad! P.S open source not an option.  

[jpeacock]

Posted on October 05, 2015 at 22:57

Place the binary image in the upper region of flash starting at a known location above your code.  Or if you have external flash put it in an unused region.

FYI anyone who does reverse engineering for a living will immediately spot that your image doesn't match what's stored in low flash.  You won't fool anyone who would represent a real threat to code theft.  The vector page is a known constant region; it's the first place to look when reversing code since it points to functions with known purpose.

[estersci2]

Posted on October 05, 2015 at 23:15

Hi,

Ok its too simple a plan...suppose I go back to a single monolith.Is it possible, say through code annotations, to force certain functions and variables to be placed at certain memory locations within the monolith?My thinking is to have certain areas to present, and certain areas to overwrite (triggered by various traps to try and catch infiltration attempts) in case subsequently accessed successfully.Thanks

[Tesla DeLorean]

Posted on October 06, 2015 at 00:18

From where I'm sitting the part of the threat matrix that would keep me up at night is if the competition hired a couple of developers who understood their tools.

[jpeacock]

Posted on October 06, 2015 at 14:16

Self-modifying code was a common way to secure code...35 years ago.  Someone who does reverse engineering (just a conjecture here, of course) would have a new image from out of the box plus an image after power up to find differences, and if it's possible to run an instruction trace (like on ARMs) then a breakpoint for flash writes will trap self-modifying code easily.  No instruction trace?  Then run on a virtual machine and all is revealed.

As Clive points out, the real threat is someone who's level of expertise is as good or better than your own, plus has the experience and tools to work around whatever you come up with.  There's a whole industry dedicated to reverse engineering ICs and code with a lot of sophisticated equipment and plenty of experience using it.  Unless you have something truly revolutionary, say a software algorithm to implement secure comm links with quantum entanglement, it isn't worth the effort.  Better to spend the time keeping ahead to ensure the copiers are always playing catch up. Aside from all that, if your ''gotchas'' ever go wrong and break customer equipment you are far worse off than if someone ships a few copies out the back door of your Shenzen factory.   Jack Peacock

[walworc]

Posted on October 09, 2015 at 19:23

You don't need to obfuscate the entire block of code ... too much work.  Also, too much work directed at just one guy/company/firm, IMHO.

An easier way (again in IMHO) is to obfuscate just a portion of the code.  The potion of code I would choose is the interrupts.  For example, within some interrupt(s) place a  random RETURN if such-and-such variable is SET/NOTSET.  Imagine PRINTFs that sometimes drop a character or two at random times.  Or a PWM that misses a beat, but only 1% of the time. So, sometime, everything works well … sometimes there are glitches, etc.  It will drive the poor dumb debug guy to FITS!  Plus, he will always be on his Boss’s radar for the next layoff round. Years ago (~1995), some un-named person wrote a piece of code called SLOWFAST, a TSR designed for the Boss’ computer (windows.)  [The Boss started this contest of wits by placing some semi-devious SW scheme onto unsuspecting new employee’s computer.) The Slow-fast code did nothing except during certain random times.  During these random times, the PC’s entire ability to work was consumed servicing timer interrupts.  I’m not kidding. Sometime all was well with the PC.  But sometimes, menial tasks took hours.  One could always tell when the Boss’ PC was “Acting-up�? because of the amount of blasphemy emanating from his cubicle.  It was quite funny.  In fact, the Boss took apart his PC and rebuilt it at least once.  The code did not kick-in for an hour+some random minutes  after reboot, so you could imagine his delight after the rebuild when (for the first hour) everything ran successfully. After his first rebuild, He began boasting about his PC rebuild skills at about minute 45.  I recall that someone told him a robust test should last at least two hours. The cursing and blasphemy began in earnest a half-hour later.  I still smile when I recall the events. In closing, if you detect copyright violation, sometimes a subtle tapping is more effective than a door slamming.