View Full Version : Brute Force Software Cracking

February 23rd, 2013, 20:53
Is something like this possible?
Maybe it's a stupid question,because it already exits or my idea has a serious flaw, therefore I put it into offtopic. The reason why I'm asking this is that CPUs are so much faster than my brain and fingers and I've a shitload of them available, so why not let them do the hard work.

So say I know that program X makes some checks, like for hardware installed on a machine or some serial, then displays a messagebox "I don't like you and your hardware/serial/keyfile" and then exits. And I also know that the software certainly runs some subroutines after the check is successful.

My idea is that if it's possible to disassemble the program, then the brute force cracker could sequentially replace jumps by their complement, like JNE <=> JE or JNB <=> JB and sweep selected return values/memory locations trough a defined range. (disassemble once, then the program simply changes the opcodes inside the binary and runs it or sets a breakpoint on certain locations to modify memory/return value)

The brute force cracker does this until the known subroutine is reached (e.g. registration complete messagebox) and logs every change it makes to get there. It breaks after a certain time, when it's obvious it has trapped it inside an infinite loop and kills the program. A more advanced form could capture a trace run with a good ending (program runs, valid serial) and a bad run (invalid serial/software aborts) and compare the flow. Then it would rerun the bad serial and modify the codeflow with the jumps/memory contents of the known good run until the software reaches the location defined as "successful".

In big programs it would certainly take a long time, maybe even nearly infinitely long, because the time to solve the problem grows exponentially O(2^n) for n branches or even worse by O((reg/mem sweep range)^n) for sweeps of n values in memory/register. But in case there is a known good trace, the cracker could break as soon as the code flow deviates from the known good one, reducing the problem significantly.

The host system should IMHO be save from harm (e.g. buffer overflow that overwrites system code) as long as the cracker runs in userspace, => not as root in linux/unix or admin in windoze.

Where is the flaw?

February 23rd, 2013, 21:44
Isnt that kinda the way patches work ?

Replace what is known badboy to goodboy ?


February 24th, 2013, 00:03
you should probably google for conditional branch logging plugin for ollydbg and take a look at it

February 24th, 2013, 08:07
Replace what is known badboy to goodboy ?

Trouble is, how do I know what is badboy and goodboy. If the program perform several operations on a string, how do I know (without studying each subroutine) which part of the program scans the length, which part does bogus to confuse me and which part does decide if the string is valid.
You might say that I'm a bit lazy but I think that if a program could automate that, some cracks could be done relatively quickly, supposed a lot of strong CPUs work on it, since it would parallelize well (every cpu runs a copy of the program and changes a different thing)

Blabberer, thank you for the "conditional branch logging plugin", I'll take a look at it

February 24th, 2013, 21:08
(without studying each subroutine)

ay, there's the rub.


February 25th, 2013, 11:58
[Originally Posted by Garrett;94308]Where is the flaw?

You have no idea what you are talking about?

February 25th, 2013, 12:07
See http://thunkers.net/~deft/code/toolbag/docs.html#Pathfinding

February 25th, 2013, 16:05
Awww...... 6.2

I wish the pirates would hurry up and release 6.4

THEN, I could work in this plugin.

Thanks Disa.

Have Phun

February 26th, 2013, 05:03
Aimless, you've got a PM.

February 26th, 2013, 06:27
And, you too, thusly!

Have Phun

February 26th, 2013, 07:50
You should stick to what disavowed suggested. Make yourself familiar with path walking / tracing and tainting.

Infrastructure for stuff like that is already there (e.g PIN, dynamo rio, and similar) but you will have to extend those tool a lot.

Nevertheless you will have to define what your "final" result/outcome is ( for example defining a path you want to walk ). Without doing so your brute force tool will end up in an infinite loop. I doubt that it is even possible then if you don't reduce the the "brute force space" by giving some reasonable starting points ( addr, where brute forcing should be started and so on )

One more word: Even if possible for one person more than a year of coding/researching work to do!

So the question is more of a theoretical nature I assume, right !? ;D


February 26th, 2013, 18:25
Genetic Algorithms have potential to optimize the brute path at least. Hey, if you're going to build a new cracker's Eniac, might as well do it up right