Garrett
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?
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?
