|ANNOUNCE: SandMark - A Software Protection Research Tool email@example.com (Christian S. Collberg) (2003-02-05)|
|Re: ANNOUNCE: SandMark - A Software Protection Research Tool firstname.lastname@example.org (Stefan Monnier) (2003-02-11)|
|Re: ANNOUNCE: SandMark - A Software Protection Research Tool collberg@CS.Arizona.EDU (2003-02-12)|
|From:||collberg@CS.Arizona.EDU (Christian S. Collberg)|
|Date:||12 Feb 2003 13:44:51 -0500|
|Organization:||University of Arizona CS Department, Tucson AZ|
|Posted-Date:||12 Feb 2003 13:44:51 EST|
Stefan Monnier <email@example.com> wrote:
>>>>>> "Christian" == Christian S Collberg <firstname.lastname@example.org> writes:
>> * The embedder takes a Java jar-file
>> and a string (the watermark) as input and produces
>> the a new jar-file that embeds the string.
>> * The recognizer takes the watermarked
>> jar-file as input and produces the watermark
>> string as output.
>What do you get if you do:
> embedder string1 <foo.jar | embedder string2 | recognizer
>do you get string2 only ?
It depends on the algorithm. Most software watermarking
algorithms are keyed, so you'd say
embedder string1 key1 < foo.jar | embedder string2 key2 > foo1.jar
recognizer key1 foo1.jar # gets you string1
recognizer key2 foo1.jar # gets you string2
However, even some keyed algorithms have the problem that
a second embedding is likely to destroy the first. For
example, for algorithms that embed the watermark in the
instruction frequencies of the program (e.g. Stern's
algorithm which is one of the algorithms implemented
in SandMark), multiple embeddings are unlikely to survive.
Christian Collberg | "It's wondrous, with treasures to
email@example.com | satiate desires both subtle and
University of Arizona | gross; but it's not for the timid."
Return to the
Search the comp.compilers archives again.