Re: [WM]: software watermarking

[Gonzo <davec@netsoc.ucd.ie>]

> Whether quines (and their variants such as selfmd5) place a limit on 
> what can be watermarked, tamper-proofed and obfuscated depends on how 
> you define "functional program behaviour".
Agreed. Your definitions of functional program behaviour seem to allow either 1. It still prints out what its hash used to be.
2. It prints out its new hash.
I have written modifications to this program that take in input and so prevent the first case from applying.
In the second case the observable program behaviour has changed. The program still carries out the same actions(or call them
functions). Does this really mean the functional program behaviour is maintained? RFC Say you have a program that 1. Contains its
own hash as a string 2. Calculates its own hash into variable myhash 3. Calls MD5sum onitself 4. Checks that these three values are
equal and if they are carries out an action
	i.e if(myhash==MD5sum self.c=="8d2...813"){print hash(myhash+Inputed variable);}

Now any modification to this program will change the results.
You could still get true predicates for the conditional be altering the string that holds the hash to match whatever the hash has
changed to. Then you are changing conditional checks which I think is altering the functional program behaviour.
	All this assumes a secure hash function, which MD5 is not. My view is "If there exists a secure hash function then there
exists programs that cannot be modified without changing their program behaviour"
	Regards
	David Curran


In obfuscation/watermarking
> literature, functional program behaviour is usually defined as the 
> observable behaviour or I/O relationship.  If we obfuscate/watermark 
> the binary of a quine (or selfmd5) - the IO relationship *is* maintained.
> The program still takes no input and still prints out the same output 
> it did before obfuscation/watermarking. What may not be maintained is 
> intent - the program should print out its own source code or md5. (In 
> fact, in the particular case of selfmd5.c which prints out the 
> checksum of its source and not its binary, one could argue that intent 
> was also
> maintained.)
>
> On the other hand, if we define this *intent* to be the functional 
> program behaviour - then selfmd5.c can still be transformed during 
> watermarking/obfuscation provided any additions are made both in the 
> body of the program and in data[] array that contains a copy of itself.
>
> Whether this can be automated or not I cannot say - however the mere 
> existence of quines does NOT show that 
> obfuscation/watermarking/tamper-proofing is impossible for all 
> programs
> - under either definition of functional program behaviour.
>
> Programs which query for their actual own source code or running image 
> are, I believe, a different matter.  But this is usually expressly 
> forbidden to quines.
>
> Regards
> Jasvir Nagra
>
>
> > On Wed, 2004-12-08 at 11:08 +0000, Gonzo wrote:
> > > embedding the hash into the software itself can be a solution, 
> > >while keeping ping the hash unchanged after embedding.
> > From reading the piece I don't believe it is possible to keep the 
> > hash of a file unchanged after adding to the file the value of the hash. It seems only possible to add a value to two files that
hash to the same value and still have them hash to the same value.
> > 	It is possible for a program to contain its hash, by fixed point reasoning.
> > Interstingly it is also possible for a program to print its own MD5 hash.
> > ftp://quatramaran.ens.fr/pub/madore/misc/selfmd5.c
> > Such a program cannot be altered without changing its functional 
> > program behaviour. This places limits on the power of software watermarking, tamperproofing and obfuscation as it shows they
cannot be used on all programs.
> > 	Regards
> > 	David Curran
> >
> >  On Wed, 8 Dec 2004, Ersin Esen
> > wrote:
> >
> > >
> > > regarding hashing, the following discussion can be interesting:
> > >
> > > http://developers.slashdot.org/developers/04/12/07/2019244.shtml?t
> > > id=9
> > > 3&tid=172&tid=8
> > >
> > > embedding the hash into the software itself can be a solution, while keeping the hash unchanged after embedding.
> > >
> > > -ersin esen
> > >
> > >
> > >
> > >
> > >
> > > ----- Original Message -----
> > > From: "mahdavi" <mahdavi@ec.iut.ac.ir>
> > > To: <watermarking@watermarkingworld.org>
> > > Cc: <watermarking-owner@watermarkingworld.org>
> > > Sent: Monday, December 06, 2004 1:35 PM
> > > Subject: Re: [WM]: software watermarking
> > >
> > >
> > > > there must be a hash on your software on server. (eg an md5 hash).
> > > whenever you want to verify file integrity you should calculate
> > > > hash of your software and compare it to the hash on server.
> > > >
> > > > On Fri, 03 Dec 2004 16:51:58 +0100 (MET), 2630370 wrote
> > > > > hello,
> > > > >
> > > > > i'm looking for techniques to produce software watermarking, 
> > > > > i.e., a way any user can verify if an application or update 
> > > > > downloaded from the internet really has been released by the 
> > > > > right producer and has not been alterated.
> > > > >
> > > > > i would really appreciate any hint,
> > > > >
> > > > > thanks,
> > > > > mh
> >
>
> --
> Jasvir Nagra
> http://www.cs.auckland.ac.nz/~jas
>


______________________________________________________________________________

Watermarking Mailing List - http://www.watermarkingworld.org/ml.html
To unsubscribe send email to "majordomo@watermarkingworld.org" with
"unsubscribe watermarking YOURMAIL" in the body.
______________________________________________________________________________