Re: Password on code - what's the best way to obfuscate it?

Thanks for clearing that up, I should've been more specific...

On Saturday 12 September 2009 12:15:53 am Ben Giddings wrote:
> On Sep 12, 2009, at 01:08, 7stud -- wrote:
> > 1) What does "even strip the result" mean?
>
> 'strip' is a tool for removing all symbols from an object file or
> executable.  It  means that if you try to debug the code you get no
> meaningful breakpoints, function names, variable names, etc.  On the
> other hand, it doesn't remove any string constants that are used.

Right. Basically, it removes so-called "debugging symbols", returning a binary 
that is smaller, more optimized in theory, but harder to debug. Ubuntu, at 
least, seems to ship stripped binaries, with the debugging symbols elsewhere.

But the resultant binary is functionally identical. In order for the program 
to run, it needs to have a string somewhere.

> > 2) What does "run strings on it" mean?
>
> 'strings' is another tool used to see "strings" in a binary file.  It
> basically looks through the entire file and when it encounters 4 bytes
> in a row that are ASCII characters, it assumes it's a string and
> prints it out.  This means it finds a lot of junk that isn't really a
> true string, but it also finds any actual string in the file that's at
> least 4 chars long.

Interesting. I assumed it actually analyzed the binary, somehow...

Of course, you can easily see how one might fool 'strings' -- something as 
simple as xor'ing the string constant would probably make it seem to be 
unprintable characters. But the same thing is going to apply to a scripted 
language -- the only difference is that it's harder for most people to 
disassemble a binary and reverse engineer what's going on, than simply read 
through source code.

I should point out, again, that if the intent is to store a password inside 
your program, such that people with a copy of the program can't get the 
password, this presents roughly the same reverse-engineering difficulty as DRM, 
which is known to be ineffective.

The reason I asked for more details was, maybe we could help rethink the 
design, to provide real security, not just obfuscation.

To take a really simple example, suppose I wanted to distribute a program 
which tied into some Amazon S3 storage that I control. I could try to stick my 
Amazon credentials into the program, but then anyone could find them and delete 
everyone's stuff.

The right solution isn't to hide them better, it's to never send those 
credentials in the first place. Instead, I can set up a server which holds my 
AWS credentials. The client then pings that server with an S3 request, the 
server signs the request, then S3 knows it's approved -- and the server can be 
smart enough not to let the client delete anything it's not supposed to.

But to know how to do this right, I'd still have to know what he's actually 
trying to do.