Watermarking
in [Embedded]
|
From: D Yuniskis on 13 Apr 2010 09:11 whygee wrote: > hi, > > D Yuniskis wrote: >> The trick is finding a technique that is robust enough >> ("This is copy #..." is NOT) yet *simple* enough to >> implement (you don't want to burden *your* development >> effort unduly -- you want to burden the *thief's*!) > > What you describes looks more like the techniques used > by virus writers to escape detection by pattern matching. <frown> I'm not sure this could (by itself) be of any "help", there. I.e., the goal isn't really to disguise what you are doing. Rather, just to change the way it's "packaged". You would, for example, see *huge* chunks of identical code (assuming it was written as PIC) that was just "located in a different place" in the executable. E.g., you would still find "This is copy #..." *somewhere* in the executable -- it just wouldn't be in the same place in each copy. (My understanding re: virus writers want to *disguise* "This is copy #..." ?) > There is a lot of research in this domain, if the security > magazine I read is right. Self-modifying codes, > hashes, RSA keys, equivalent codes sequences > (like a++ = a-= -1, a+=1...) etc. are well known > in the security world. They are also supplemented > with Virtual Machine and debugger detection and avoidance > so when the code detects that it is being single stepped, > it branches to dumb stupid code that does nothing, > or executes differently. Again, I think that's a different beast. I think that is just intended to complicate reverse engineering. The (primary) goal, here, is just to make each instance of the executable slightly different -- yet functionally identical (i.e., in an RT application, it still has to execute in exactly the same time, etc. -- this can be an issue as locality of reference can invalidate cache lines with different frequencies from one "copy" to the next.) > however these "protection layers" often have a big price > in execution performance, maintainance and bloat... The instances of which I have first-hand knowledge made that very apparent. :> But, they went beyond simple watermarking to also try to thwart copying. I'm not trying to prevent that -- just *track* where the copy came from. (If client wants more, they'd have had to *ask* for more! :> ) And, to make it difficult for a thief to alter the image in a way that would enable him to make it look like the original (counterfeited) image came from a *different* instance (E.g., "This copy was issued to John Doe") Note that this doesn't have to add any bloat -- since the goal isn;t to mask your actions, just "permute" them.
From: whygee on 13 Apr 2010 09:08 D Yuniskis wrote: > Note that this doesn't have to add any bloat -- since the > goal isn;t to mask your actions, just "permute" them. OK then let me clarify : you *can* leave a mark in your binary. One simple example is : you select 60 (or more) locations in your code where for example you increment a variable, or add a constant. In each of them, you define (#ifdef) that the operation is done with adding, or else with substraction of complementary value. so your source code has a lot of #ifdef WATERMARKxyz a += 42; #else a -= 42; #fi you can then make a script that goes through all the WATERMARK000, WATERMARK001, WATERMARK002, ... and makes a binary combination based on a given serial number, like : define an arbitrary client number, store it in your database. For eache client, apply a DES block cypher and/or Hamming code to his client number to provide more strength and resilience to the value that you will then encode. Then you give this set of defines to the compiler who will hopefully not optimise the subs with adds. And you have your watermarked executable. The issue is that if someone happens to have 2 or more different copies of your code, he'll be able to XOR them and forge a new executable. Hence Hamming and DES, the more you put watermarks, the more chances there are that some original marks are not uncovered by the XORs. For example : - with 2 XORed copies, 1/2 of the marks can be removed - with 3 copies, only 1/4 of the marks remain... - etc. each new found copy leaves less and less marks. so redundancy is paramount if you want to be sure to retrieve your data in case of conflict. Furthermore, if you have more choices than just 2 different ways to do the same operations, it's even better as it might confuse the differential attack even more. contact me in a private message for my consultancy fees ;-P yg -- http://ygdes.com / http://yasep.org
From: whygee on 13 Apr 2010 12:58 D Yuniskis wrote: > Hi, hi ! > I.e., these sorts of transforms give the end result > desired (watermark) without interfering with the > developer's actions -- yet make it considerably more > difficult for a thief to permute any instance into > any other instance WITHOUT A SERIOUS INVESTMENT OF > TIME/EFFORT. In the end, we will all be eaten by the Chinese, then they will eat themselves. So why care ? ;-) anyway, I see your points. Hope you'll succeed, yg -- http://ygdes.com / http://yasep.org
From: Oliver Betz on 14 Apr 2010 02:28 D Yuniskis wrote: >Anyone with FIRST HAND experience deploying watermarking >technologies? Comments re: static vs dynamic techniques? has your hardware external program memory or do they run from internal flash? If the latter, distribute encrypted binaries. Oliver -- Oliver Betz, Munich despammed.com might be broken, use Reply-To:
From: D Yuniskis on 14 Apr 2010 03:27
Hi Oliver, Oliver Betz wrote: > D Yuniskis wrote: > >> Anyone with FIRST HAND experience deploying watermarking >> technologies? Comments re: static vs dynamic techniques? > > has your hardware external program memory or do they run from internal > flash? If the latter, distribute encrypted binaries. Encrypting tries to *prevent* counterfeiting. That's not the goal (too often, there are ways to access internal resources by exploiting something in the device). Stated goal is to track where "copies" came from. Presumably, prosecute the source of the leak -- who probably doesn't have very deep pockets (whereas counterfeiter *might* -- and might be overseas, etc.) and would be seriously concerned to see him/herself named in such a lawsuit. (I suspect just the threat of this is the bigger deterrent. Dunno, I'm not the client) |