Jonathan Henderson <jh********@preemptive.com> wrote:
Obfuscators aren't only used for protecting intellectual property.
See the hacker demo at this link:
http://www.preemptive.com/documentat...ackerDemo.html
LOL - 'cos everyone ships debug versions including the PDB files.
Also interesting is the fact that he talks about user input validation,
when none is actually required, given that the customer ID is specified
as a parameter, not injected directly into the SQL statement.
Furthermore, he's suggesting making changes to the app in order to use
random bits of SQL, despite the fact that the connection string is in
the code anyway, so the more sensible thing to do would be to use that
connection string to do stuff directly to the database. Of course, with
a sensibly administered database, the user which could log in wouldn't
have access to any "dodgy" things, regardless of how they tried to do
it.
I'm not saying that obfuscation is a bad thing, but I do wish that
they'd put a bit more time into a *sensible* demo. In this case, the
connection string is the sensitive part, and so long as you could
decompile (with a suitably powerful decompiler) and then recompile the
code, it wouldn't be hard to find the places where the SqlConnection
constructor is called, insert something to write the value out
somewhere, and then recompile and run. Bingo, you're in the same boat
as you were before - all you need is a better decompiler. In fact, you
don't even really need a decompiler - just a disassembler (eg ildasm)
and enough nous to inject a single method call into the flow near the
SqlConnection constructor.
--
Jon Skeet - <sk***@pobox.com>
http://www.pobox.com/~skeet
If replying to the group, please do not mail me too