Kayaker
December 20th, 2001, 00:18
Quote:
Originally posted by SpeKKeL
Thanks,
Ok, about inline patching > there are to much jumps/calls to the
high area where the original code is to make an inline patch(there are not only little checks but big routines)
So i want to copy memory loc xxxxxxx till xxxxxxxxx paste it in my
dumped exe and it must be loaded at the original location........
Spekkel |
Hi
The problem is that you just can't dump the opcodes you see while tracing in high memory packed code anywhere in a file. The addresses have to match and all variables have to be accessible. Rewriting the code is still your best bet. You should trace the routine you think needs replacing very carefully and determine what it's doing and how best to emulate that. It may only be passing a variable you can supply yourself in another way. If it's decrypting some code perhaps then you may need to rip out a keygen style replacement for it.
You could try creating your own section which has an RVA identical to the packed code and replace dumped bytes. Try a Softice backtrace on the section of code you're exploring, keeping it as small as possible, and check it out with SHOW. Then you can trace through and find each call, and if the opcodes haven't been changed since the backtrace recorded the instruction (i.e. code hasn't been overwritten) then sequentially do a raw dump of as many lines as you can that you know will follow the proper code flow. These you can paste into a chunk of code you can try inserting at your newly created high memory address. Your problems will be to supply the variables and to have legal access to whatever area of memory was used originally on your particular system at that particular time.
Not really an easy task for a large section of code. I'd be very interested to see if this would work though because Spekkel, you've given me an intriguing idea. The tool I've been writing, and now with Clandestiny's help is really beginning to grow, is made to work interactively with doing Softice backtraces. You can disassemble any backtrace you've done into a listview for examination or saving. Presently you can only look at it in Softice, and you can only do /screendumps of the backtrace history. The SI backtrace buffer records the exact sequence of commands executed as addresses, these addresses are disassembled with the target file loaded, into the list view. You can break into the address space of the program and set up new backtraces on program runtime code or break at program entry.
Now at some point in the code during the disassembly routine, I have access to the exact sequence of opcodes that were executed between the users backtrace start and ending points. We should be able to save these as they are going through into a binary file which could be pasted as hex code. With a little more coding of the Listview it might be possible to allow the user to pick and choose the opcodes from sections of the backtrace, sort of like a codebank.
I don't know how useful this feature might be, or even if the results would work, even if you wrote every byte manually. But you've given me this idea and I can't shake it, heh

If anyone can sucessfully recreate a reasonably large section of packing code that is needed by a dumped program, by following the sequence of commands recorded by the Softice backtrace, and have it execute in the proper address space by creating their own section, then I solemly pledge to try to create an easy way to assemble those instructions into a file which can be pasted into a section.
This would be a good project actually, I'd like to see a tut on it

We both are trying to make this a good reversers tool, so if there's something useful that could be implemented into it we'd like to try to provide it. Anybody see any flaws in the logic? The question is, could you successfully emulate a section of high memory packed code? Interesting.
Regards,
Kayaker