topic Re: deception in Operating System - HP-UX

deception

U.SivaKumar_2 — Wed, 12 Mar 2003 07:41:02 GMT

Hi all ,

How to conceal the programming logic , library details and other unwanted details in a binary in unix to prevent Unix binary piracy ?

I am aware of strip command. Please suggest more .

regards,

U.SivaKumar

Re: deception

Stefan Farrelly — Wed, 12 Mar 2003 10:20:41 GMT

Run;
/opt/ifor/ls/bin/i4target

On any HP box this gives a unique SPU Target id (like a serial number) which you can then hardcode into your binary (to check it matches). Ive known other 3rd parties which do this. That way if the user copies the binary to any other HP server it wont run.

Re: deception

harry d brown jr — Wed, 12 Mar 2003 12:01:49 GMT

Interesting question. I used to write de-compilers, basically converting binary back into code. I've even written code to rip word processing files (in the Word Perfect days).

I really don't think there is a way to totally insure that someone can do something to the code, other than encrypting the code, and then decrypt it just before it's execution.

You could build a pseudo run-time engine or use the java engine and then decrypt the encrypted pseudo-code and feed it to a pseudo run-time engine at run time.

Of course the encryption/decryption would have to be "strong".

Good luck!

live free or die
harry

Re: deception

H.Merijn Brand (procura — Wed, 12 Mar 2003 12:23:03 GMT

?? Stripping does help much if it uses shared libraries, so the first step is to build static binaries. Stripping static binaries removes a lot more info than stripping binaries that need shared libs.
?? If you have to use shared libs, use misleading sub names. Don't call you subroutine 'get_password ()', or 'check_license ()' or 'validate_key ()'. These are hotspots for reverse engineers.
?? Spread static strings accross your code, and assemble them in the init phase, preferably not in consequtive lines

static char password[40];

int init ()
{
password[4] = 'a';
password[0] = (char)sqrt (16) + 'd';
:
:
} /* init */

of course you did not call this routine init, but 'print' or 'timeofday' or 'reply' or ... :)

Enjoy, have FUN! H.Merijn

Re: deception

John Bolene — Wed, 12 Mar 2003 13:40:24 GMT

I can tell you how it was done on other game platforms.

They did xor's on part of the binary, and stored that at different places in the binary, overwriting the parts that were encrypted with xor.

When the binary started execution, there was a stub loader that jumped around in the binary, executing the instructions to reassemble the binary in memory for execution. IE, the reassemble code was not consecutive.

I'm sure that an encrytpion processor was written to process these binary's and add the needed code to decrypt them.

Hard in HPUX to do it like the Apple did, they stored parts of the encrypted binary at different 1/4 track intervals on the floppy, or punched a hole at a specific place and then looked for a bad sector read at that place.

Re: deception

U.SivaKumar_2 — Fri, 21 Mar 2003 03:50:14 GMT

any more ideas ?

Re: deception

Sridhar Bhaskarla — Fri, 21 Mar 2003 04:26:55 GMT

Hi Siva,

One way is to provide a key to the end user that can be used to decrypt another key inside the binary using which the original code is encrypted. That can actually initiate a CBC (cypher block chaining) which means successful decryption of one cipherblock will ensure successful decryption of the following cipherblocks.

This way, you can protect the legality as well the code.

-Sri

Re: deception

Steven E. Protter — Fri, 21 Mar 2003 04:29:23 GMT

I'm for the activation key concept. With some pretty basic tools you can make your application require a key that you generate and that's only good for one day.

That's how Easyspooler does it with their print spooler.

SEP

Re: deception

Frank Slootweg — Fri, 21 Mar 2003 12:36:59 GMT

I think in order to get meaningful responses, you should explain what *you* *precisely* mean by "Unix binary piracy".

For example Stefan and Harry address totally different aspects of 'piracy' (copy/installation protection versus reverse-engineering protection). So what do *you* want?

Re: deception

Balaji N — Fri, 21 Mar 2003 13:08:17 GMT

hi,

on a lighter vein, see this
http://www.exmsft.com/~hanss/badcode.htm

i remember reading another excellent article but unable to locate it now. :-)
-balaji