Watermarking
in [Embedded]
|
From: D Yuniskis on 11 Apr 2010 20:17 Hi, Anyone with FIRST HAND experience deploying watermarking technologies? Comments re: static vs dynamic techniques? Also, any FIRST HAND (not hearsay) experiences with its use in litigation -- that you can *discuss* openly? Or, pointers to cases of interest? I only know (first hand) of two and technology has changed considerably in the years since... Any pointers to (market) perceptions of watermarking? Comp.realtime included as to any insights regarding how RT characteristics could be exploited to provide other watermarking opportunities (not typically available to non-RT applications). Finally, any pointers to techniques to circumvent these? And, the effort required? Thx, --don
From: whygee on 12 Apr 2010 01:18 D Yuniskis wrote: > Hi, <snip> > Finally, any pointers to techniques to circumvent these? > And, the effort required? Sorry, I have no experience in this, I've read several articles about this subject. However, you don't give any hint about your problem so : - what do you want to watermark ? - how ? - why ? - what is the connection with real-time ? because from the little I know, there is not "one" watermark, there are as many as applications. And most can be easily circumvented, as soon as the watermark method is understood by the attacker. good luck, > Thx, > --don yg -- http://ygdes.com / http://yasep.org
From: D Yuniskis on 12 Apr 2010 03:40 whygee wrote: > D Yuniskis wrote: >> Finally, any pointers to techniques to circumvent these? >> And, the effort required? > > Sorry, I have no experience in this, I've read several > articles about this subject. However, you don't > give any hint about your problem so : > - what do you want to watermark ? The application. > - how ? That was the point of the post :> > - why ? To track "leaks" from the preproduction release. > - what is the connection with real-time ? Because you can exploit temporal characteristics of the application to implement the watermark. Since nonRT applications *don't* have well-defined temporal behavior, trying to exploit that capability isn't robust in those arenas. > because from the little I know, there is > not "one" watermark, there are as many as > applications. There are many different approaches to watermarking. It's essentially a steganographic problem -- except the amount of data is small. > And most can be easily circumvented, > as soon as the watermark method is understood > by the attacker. *Trivial* approaches can be circumvented. E.g., rearranging the string space, etc. But, more dynamic techniques require a greater effort to reverse engineer the code to understand how the watermark is even implemented (since you never *know* -- without "insider information" -- what characteristics are being used to implement it). E.g., you can readily see how the string spaces of two (uniquely watermarked) versions of the same executable differ. But, if the two applications look "entirely different" in their binary images yet "execute the same" (functionally), the effort to reverse engineer can quickly become comparable to the effort required to design from scratch. That, after all, is the easiest deterrent.
From: Mark Borgerson on 12 Apr 2010 11:27 In article <hpuihe$onj$1(a)speranza.aioe.org>, not.going.to.be(a)seen.com says... > whygee wrote: > > D Yuniskis wrote: > >> Finally, any pointers to techniques to circumvent these? > >> And, the effort required? > > > > Sorry, I have no experience in this, I've read several > > articles about this subject. However, you don't > > give any hint about your problem so : > > - what do you want to watermark ? > > The application. > > > - how ? > > That was the point of the post :> > > > - why ? > > To track "leaks" from the preproduction release. > > > - what is the connection with real-time ? > > Because you can exploit temporal characteristics > of the application to implement the watermark. > Since nonRT applications *don't* have well-defined > temporal behavior, trying to exploit that capability > isn't robust in those arenas. > > > because from the little I know, there is > > not "one" watermark, there are as many as > > applications. > > There are many different approaches to watermarking. > It's essentially a steganographic problem -- except > the amount of data is small. > > > And most can be easily circumvented, > > as soon as the watermark method is understood > > by the attacker. > > *Trivial* approaches can be circumvented. E.g., > rearranging the string space, etc. But, more dynamic > techniques require a greater effort to reverse engineer > the code to understand how the watermark is even > implemented (since you never *know* -- without "insider > information" -- what characteristics are being used > to implement it). > > E.g., you can readily see how the string spaces of > two (uniquely watermarked) versions of the same > executable differ. But, if the two applications > look "entirely different" in their binary images > yet "execute the same" (functionally), the effort > to reverse engineer can quickly become comparable to > the effort required to design from scratch. That, > after all, is the easiest deterrent. > This sounds like something that might be amenable to a custom linker or linker script. You could rearrange the application and library functions in the code space. That would require a reverse-engineering effort to rebuild the function call tree each time. Mark Borgerson
From: whygee on 13 Apr 2010 04:31
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. 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. however these "protection layers" often have a big price in execution performance, maintainance and bloat... yg -- http://ygdes.com / http://yasep.org |