Obfuscation

I’ve seen a bit of talk about hiding sensitive data in an executable… I wrote an obfuscator that I think should be almost impossible to reverse aside from modifying the binary to capture the string from ram… I wanted to get feedback from some of the people around here more familiar with this sort of security thing. I was thinking it would be best to not use strings (even encoded or encrypted since you’d still need the key)

[code] dim chars() as integer=Array(115,32,99,105,101,107,105,104,116,121,101,101,103,32,39,111,105,98,120,97,116,46,32,116,101,32,104,102,110,115,105,101,116,110,101,116,32,101,105,108,97,33,105,46,108,116,32,32,101,101,116,32,110,32,107,111,115,115,115,116,108,97,32,46,117,32,32,104,32,115,76,105)

dim indexes() as integer=Array(84,37,279,9,69,185,20,208,132,194,94,261,217,30,82,151,229,288,272,36,1,311,138,74,96,125,5,116,233,92,114,277,42,210,187,246,191,297,183,290,286,58,209,307,143,57,242,86,43,271,284,12,193,63,161,159,164,22,10,201,176,192,105,303,283,268,172,253,225,52,64,129)

indexes.sortwith(chars)

dim s() as string
for each c as integer in chars
s.append chr©
next

msgbox join(s,"")[/code]

I’m essentially creating two arrays, sorted in a random order together to be sorted at runtime and then converted back to a string. I’m unsure if these arrays exist in a form in the binary that could be easily found and decoded… I was thinking about adding more levels of obfuscation, but I’m unsure of how the compiled binary holds predefined integer arrays… I could pad the array and set an offset in code.

Please comment and let me know if there are improvements to be made. I’ll post the generation code soon… the goal is to provide reasonable security, even while everyone knows how it works…

At some point, your app has to do something with the strings. If that involves calling any function, a motivated hacker with very minimal skills can set a breakpoint at the start of any function and sniff the stack/registers.

If you’d like to know why ultimately, I’m beyond annoyed that someone claimed to be helping by exposing a particular product’s systemic vulnerability in order to promote his own product, re-read the above sentence 20 times. And before Kem goes off on how obscurity is not security, real security is a whole picture thing that considers costs/benefits of blocking all available vectors, not just those that someone sensationalizes.

Easy there Brad

Brad, don’t hijack the thread. If you want to discuss the other thing further, do it in the other thread.

Jim, I like your scheme. I’m just concerned how the arrays would show up in a hex editor. In other words, someone might see this as the actual characters, just in a different order. For short strings, that might hurt.

Perhaps another variable called “adder” that will hold a random number from, say, 1000 to 2000 that would be needed for each value:

    s.append chr(c-adder)

You could even make a third array with each adder so every character has to be adjusted with the corresponding value in the third array. That would make it even more annoying. :slight_smile:

This looks good to obfuscate a few strings, presumably serial numbers. Now, this will work only if pluggins can process serial numbers dynamically.

An idea … don’t know if it would work or not.

RANDOM given the same seed will always produce the exact same sequence of values on a given machine.
IF it gives the same sequence on different machines… then all you need it to hardcode a specific SEED
and let the program generate all the rest… There would be no way in H*LL to back track that… since the key arrays would never exist except at run time.

Just an idea… and dependent on RANDOM be not so “random” :slight_smile:

Kem, not hijacking. I’m responding to this:

Effort put into obfuscation above a pretty simple baseline is wasted effort.

Nothing that provides a learning experience is “wasted effort”… even if the result of that learning is that the idea isn’t viable

That’s a good idea Kem. I was thinking of using doubles for the char array, each character multiplied by a random value, ei. multiplier=rnd()+1, but an array of random multipliers would surely make it unreasonable to decode from the binary. A hacker could still find the info with a breakpoint, etc… but I’d like a simple way to obfuscate things…

The info (in my case) will be sent to system calls, so probably not difficult to sniff. I just don’t want to make it obvious to a quick ‘strings’ scan.

Dave, his stated goal was making strings difficult to recover, not finding better ways to hold hands on a forum.

That’s not a bad idea, but I doubt you could count on it. Even if it’s true now, an OS vendor may decide to change the way they handle random in the future.

[quote=92788:@Brad Hutchings]Effort put into obfuscation above a pretty simple baseline is wasted effort.
[/quote]

Brad, I learned long ago that in a collective endeavor, dismissing ideas outright is counterproductive. You may be angry at Matthew, please don’t take it on other members trying to find ways to counter string collection.

Yeah, I assumed that’s all we were talking about, not hardcore security.

A code generator for this could be make into an IDE script. Highlight the text you want to obfuscate and it would replace it with that line commented, then the code to generate that string.

I think that may be a goal for Facebook :wink:

Michel, it was a TECHNICAL statement. Read it as such, take it as such. If you disagree with TECHNICAL aspect of the statement, disagree with it as such. IMO, he is already past the point of diminishing returns with what he’s done. The cost to a hacker to decode the strings encoded as such is much higher than the cost to breakpoint and stack sniff.

You roll up the windows and lock the doors to stop the joyrider. You add a steering wheel lock to discourage them further, knowing full will that the professional will still get your car. That’s all we are talking about here. We all know the hardcore guys are not going to be stopped.

[quote=92798:@Brad Hutchings]The cost to a hacker to decode the strings encoded as such is much higher than the cost to breakpoint and stack sniff.

[/quote]
I also wanted to make it fast, so that my app doesn’t have to suffer performance loss trying to do some very basic obfuscation…

sending Brad a care package full of cheese and crackers…

I doubt that would matter much since not every string has to be encoded this way, and the decoding only has to be done once per string.