Quote:
Originally posted by t0xic
If you are the same manko that writes aspr debugger, I've tried your tool a few times (and admittedly it confuses the hell out of me since it tells me the stolen bytes are at some very high memory range that makes no sense to me... I should probably see if there is documentation or something as I get lost very fast when using it =)
|
Hi, again Toxic!
I am.
Yep. Aspr-code is always in some high memory area... The reason it's called "stolen bytes" is cause he ripp them and execute them in his own memory space before he jump to proggies memory-space...
The problem now is that stolen bytes are not in plain view, like before... There are some obfuscated code embedding it and sometimes it's atleast partly mutated, meaning he does what it should with other instructions... If you study the normal start of an app from the same language... And take the time to trace through the whole block (starting from where my asprdbgr reports it...) a number of times, you will start to see what's what...
Also, with newest aspr he often emulate part of code he didn't rip and dive into code at places that are not near OEP.
Often inside the first call... or even deeper... I have honestly done too few of these to have had time to figure out some smart method to arrive nearer to the stolen bytes... except traceing... (dont wanna bpm on stack as that is so easy to break... he has before...)
Can I buy moore time please??
There's no documentation for AsprDbgr yet and that might not happen very soon, though it WOULD be good...
It is assumed that one already knows a great deal about aspr for it to be of any use...
If I had time I WOULD like to make some document that explains everything, but... I don't have much time... Hmm...
/Manko