Log in

View Full Version : Loading Data in memory,


SpeKKeL
December 18th, 2001, 04:42
How to load a certain amount of data in memory ??

Is it possible to load some data on a certain place in memory and how to do this ??(add section ??)

when a unpacked target checks ( or calls back to) it's main code
and there isn't any this leads to crashing or disabling etc..
Instead of nopping and jumping the dumped target, i thought that
this could be an easier way ???

Spekkel

Kayaker
December 18th, 2001, 20:11
Hi Spekkel,

I would think you should be able to do a few things. Say there's a jump to a high memory address which is no longer valid in your unpacked file. If you know the code is important to run you can always redirect the jump or call into an empty writeable area of memory and emulate the code by writing in the opcodes that describes the code. If you need (and know) any variables you can enter those in an empty memory address as well if the originals are "missing". Basically an inline patch in your dumped target.

The simplest case is inserting a CC return where you know the code isn't really important to run, this is just a little more elegant than nopping. If it's just a particular needed variable to be retrieved that was placed in a memory address by now nonexistant unpacking code, then you should be able to supply that as well if you know it (or can create it through code).

Where you find the empty space is up to you. If you need more bytes than that provided at the end of a writable section you can always add your own section and the memory is entirely yours to play with. Often you can gain a few extra empty bytes at the end of the .text or .data section by increasing the Virtual size to be equal to the Raw size in the PE header. Depending on how you dumped it it may already be like this, which is why I prefer raw dumping over a PE optimized dump.

Hope this helps,
Kayaker

Lord_Soth
December 18th, 2001, 20:46
There should be plenty of room at the
end of most or at least SOME of the
sections. After all, it aligns on boundaries,
big boundaries :-)

And if you must add a section, then
you should be prepared to do the necessary
patching to make the code work from
there...

LS

SpeKKeL
December 19th, 2001, 04:14
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

CoDe_InSiDe
December 19th, 2001, 04:47
Hi SpeKKeL,

Then just make a new Section

Raw Address somewhere at the end of the File (Copy the Memory Code there) and the Raw Size of it (Just count it or something it doesn't have to be exactly the size of the Code, can also be more but not less ).
Virtual Address, the original address of the Code
Virtual Size, same as Raw Size but "round" it (You know like 00001000 / 00003000 etc...)
Make Characteristics 400000E0 (Should be enough )
Oh and the name of the Section, well you decide ...

Ok, this is just a quick description i hope it's enough hehe
If you don't know how to add a new Section then use a Tool, or better yet get some Tutorial and do it Manually

Cya...

CoDe_InSiDe

Bengaly
December 19th, 2001, 05:45
CoDe hehe...
haven't ya left yet ?
/me is counting the days ;p
hm...hm..h.m....cya later

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