Hullo all,

Here's something which I have been trying but repeatdly getting unsuccessful attempts at. Maybe someone could post a nice suggestion...

There is an application (say a.exe) which loads modules as required (say b.mod and c.mod) much the same manner as IDA does.

Now, using softice (or memory mappers), I can dump and view the loaded modules (not the main exe). However, I cannot get to disassemble the dump in IDA due to the following reasons:

1. I cannot seem to get the entry point of the DUMPED module (again, the module, not the exe)

2. How to load hex dumps into IDA ? (Sure, I know but somehow hex dumps of these modules, DO NOT disassemble!)

The reason is, if I open any one of the modules AS THEY EXIST ON THE DISK, NOT MEMORY, in a hex editor, I get the usual familiar signatures like PE/MZ/.text/.data and so on! But disassembly from dumped memory OR disk, does not occur. And yes, its DEFINITELY not packed/encrypted.

So what COULD possibly be the answer?

A little assistance would go a long way on this.

BTW, are there any topics of interest on how to dump LOADED modules (AND NOT THE EXE THAT LOADS THEM) and disassembling them?

Have Phun.

Yeah i take it that you are talking about dumping dll file???

Well that have been a few thread recently, try evaluator's trick to convert it to exe bofre dumping :>.... finding OEP is similiar to finding OEP in normal executables, i think because IDA dissemble following th execution flow so if you have invalid OEP it will not disassemble properly, try W32dasm cos it will disassemble the prog anyway...

Hope that helps...

Not really.

The modules (sorry, the word is ~misleading~), are nothing but HEX dumps. Not dlls, not dlls-renamed-into-modules, not some executable stuff.

To put it clearly, they are not DLLs, its just too easy to dump dlls, and they show up in Procdump anyway. These are MEMORY MAPPED files (yup! the hex dumps are memory mapped after the main exe is loaded).

Still, thanks for the proposed hint. I will try the necessary.

Have Phun

Hello aimless !

Maybe I don't understand your problem, but I'll try to help you.

If the *.MOD files are just pure code...
If they are not encrypted...
If they are used as memory mapped files...
If the memory page is set to executable...
If the program jumps to code in this memory...

Then why don't you create a dummy .EXE file with a .code segment as large as a .MOD file, take the original (non-dumped files) and insert it into the dummy .EXE? Then you can disassemble the file with no problems.

Since memory mapped files are always mapped to different memory regions, there can't be any direct calls to imported functions or direct references to the code in memory, unless it uses some kind of relocation, which I would say is impausible in this case.

I hope this helps, else may you explain why you want to use the dumped modules instead of the original ones?

DakienDX wrote:


This isn't necessarily true. If the memory mapping is done with the Win32 function MapViewOfFileEx(), then the caller has the option of specifying a base mapping address. If the author of the application has control over all the modules as well as the main app, then it's a relatively safe bet that a desired virtual address will always be available.

It seems to me that this is the only practical way to do this. Because these 'modules' aren't in a standard Win32 .exe format, the system-level loader functions won't work. This means that either the creator of these modules implemented a relocation scheme or he's assuming that the required address will be available.

A third possibility might be that absolutely all data access and code branching in the module is done with relative calls, but this seems like it's more trouble than its worth.

I am in agreement with you that there is likely an access layer between the module and the main app. Assuming the location of module functions would be a very bad thing. If I had to take a guess at it, I'd say that module offset 0x00000000 was some sort of GetInterface() function.

Good luck!
-notbob

Hello notbob !

Yes, you're right, MapViewOfFileEx has the option to specify a mapping address, but only a desired one.
If it's occupied by some other program (maybe a mouse driver DLL mapped into all processes), the function will fail and make it impossible to load the module.

Since modules make the program expandable, the author will probably not define a unique load address for each module he might create in future.

Relocations will also be impausible, since aimless said the modules are hex dumps. Therefore I think they have no header with information about relocations or exported functions.

Maybe there is a value at a fixed offset which is set to the module's base address when being loaded from the main program, so the module can use this value instead of doing everything with relative offsets.

Maybe the module relocates itself when it's entry function is called with the base address as a paramter.

Who knows? But this possibilities will all make it more complicated than it needs to be.