Thanks for clearing that up, I should've been more specific...
> 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
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.
On Saturday 12 September 2009 12:15:53 am Ben Giddings wrote:
On Sep 12, 2009, at 01:08, 7stud -- wrote: