PDA

View Full Version : MapConv not loading labels or comments for a DLL?


5aLIVE
May 24th, 2005, 09:45
Hi, I have also posted this question on EXETools forum so as to reach a wider audience.

I'm experiencing a rather strange problem when using the MapConv v1.4 plugin for OllyDbg.

I have produced a MAP file using IDA which includes Autogenerated names and Demangled names. From IDAs Options\Demangled names... menu and selecting Setup shortnames, I checked the option "Inhibit everything except the main name".

I have sucessfully applied this MAP to an attached EXE process and confirmed that either Labels or Comments are present by right clicking in the CPU window and selecting either search for/user-defined label or search for/user-defined comment

When I try to do the same for a DLL, no labels or comments can be seen.
Any ideas what can be wrong? In Olly, I selected from the menu Optiions\Debugging options and selecting the Events tab I checked the Break on new module (DLL) option.

Once the attached process loads, I would expect Olly to break when the DLLs are loaded, this doesn't appear to happen though.
Next, I press Alt+E to view the executable modules of the attached process.
I highlight the desired DLL and right click and select Follow entry.
I then apply the .MAP file only to find no comments or labels present.
NOTE: I can succesfully convert this .MAP file to a .NMS and view all the labels and comments in softICE. I would prefer to work on this app using Olly thats all.

I hope someone can help me solve this interesting problem. Thanks for all your help.
Thankyou,
5aLIVE

blabberer
May 24th, 2005, 10:46
well your dll may be relocated and maps address doesnt match with
present image
i think you can force ida to load the dll in different image base
though i can be wrong as i dont use ida much
if you succeeded it in loading at a different address try making one more map and use it

or may be you can try godup plugin and try to apply the signatures that ida applied while analysing your dll
it should handle relocations properly if i am not wrong

or find what is the original imagebase of the dll and find out what existing dll is loaded in that address (view memory )
if possible try unloading that dll (probably some antivir realtime scan dll
must be sitting in 10000000 address (avgs for sure sits there at least in my system

or better if you are adventourous try editing the image base physically in the dll and experiment with ida mappping it again

5aLIVE
May 24th, 2005, 10:50
>Thankyou very much for the quick reply. This must be the problem, the debugged DLL has different addresses for a particular function compared with the IDA listings.

e.g., IDA shows : .text:10001028 sub_10001028, while the same subroutine can be found at mem loc 02041028h.

Subrtracting : 10001028h - 02041028s gives 0DFC0000h.
Is this the new image base value I use to obtain the correct mapping?


i think you can force ida to load the dll in different image base
though i can be wrong as i dont use ida much
>I'll look into this, I'm far from an IDA expert myself.
if you succeeded it in loading at a different address try making one more map and use it
>That sounds like the ideal solution to me.

or may be you can try godup plugin and try to apply the signatures that ida applied while analysing your dll
it should handle relocations properly if i am not wrong
>I've seen the GODUP plugin mentioned, but have not tried this one yet.
>I'll give it a go if I am unsuccesful in adjusting the image base in IDA.

or find what is the original imagebase of the dll and find out what existing dll is loaded in that address (view memory )
>Original image base of the DLL is 1000 0000h, a module called AGM.
I'll investigate further.

if possible try unloading that dll (probably some antivir realtime scan dll
must be sitting in 10000000 address (avgs for sure sits there at least in my system

or better if you are adventourous try editing the image base physically in the dll and experiment with ida mappping it again
>Hmmm, nice idea, but a last resort as I have no experience of tinkering with PE file section at present.

Many thanks for such great advice.

blabberer
May 24th, 2005, 11:09
i dont know how this can happen TBD ?? how does the same post appear in two different names ??


anyway if you are not adventurous but still need to change imagebase
you can find editbin in masm32\bin or google for it
it can rebase the dll to any imagebase you specify like

Quote:

c:\masm32\bin\EDITBIN /REBASE:BASE= " your address viz 0x12000000 " your.dll
pause

blabberer
May 24th, 2005, 11:32
oops %Alive you commented i thought i saw my same post in different names

anyay TBD I Still have a question why doesnt the board keeps me logged in ??? till i quit atleast ??
i wanted to edit the post but i cant find edit functionality
i am forced to make dud replies which i could have edited inside my original posts
can you have a look and confirm

5aLIVE
May 24th, 2005, 11:41
My mistake, I pressed the login/post button, not realising that I was still logged in. Sorry about that.
5aLIVE

5aLIVE
May 24th, 2005, 13:28
I successfully rebased the DLL file to match the imagebase of the relocated DLL. Now, the addresses in both IDA and Olly are the same

The target address space of 1000 0000h is occupied by another DLL used by the application under scrutiny and therefore cannot be unloaded.

Having rebased the DLL, I genuinely thought that this would solve the mapping problem. Yet I still cannot view labels or comments from the newly produced MAP file. What else could possibly be the problem?
This is starting to get to me.

Many Thanks,
5aLIVE.

5aLIVE
May 25th, 2005, 06:50
UPDATE:

Up until now I've been using Olly 1.09d, I thought I try using Olly 1.10 since it supprots the loading of DLLs.
Using this tool still didn't give the expected results.


I changed the image base of the DLL using LordPE to make dissassembled addresses match those of the relocated DLL.

As soon as I try and apply a label or comment MAP, I gey the application error 'The instruction at "0x2c6172b" referenced memory at "0x0000000c". The memory could not be "read".

This suggests to me that there is a problem with the new image base of the DLL(loading the original DLL with the original map, doesn't produce this error, neither does it produce labels or comments ).

Another "clue" that tells me the rebased DLL structure is in error is that previous string references shown in IDA like:

.text:10002E6F 68+ push offset aMyString ; "MyString"
.data:1000924C 41+aMyString db 'MyString',0 ; DATA XREF: .text:10002E6F

Now become:
.text:02042E6F 68+ push 1000924Ch
.data:0204924C 41+aMyString db 'MyString'

So the new code section appears to be addressing the old data section.
As I've said before, tinkering with PE section is new to me. Do I need to change the start and end adresses of the .data section to fix this?

I hope someone can help me reach a solution.
Many Thanks.
5aLIVE

blabberer
May 25th, 2005, 07:54
well that is why i said you need to be adventourous and also that is the reason i gave you editbins commandline

just changing imagebase with some hexeditor will make it load at a differnent address but you also need to change all those absolute referances for making the image work

absolute referances have the old imagebase hardcoded inside them

00401002 |. 68 00304000 PUSH msgbox.00403000 ; |Title = "Iczelion's tutorial no.2"

you would need to change 40 to 1000

it is kinda trivial if you know what you are doing else it is a daunting task

get editbin to do it for you it does the job properly

you should be able to find editbin in almost all program langs \bin folder

i got it here in masm32\bin ive seen it in vs\bin also n vb\bin
folders
also it is part of ms sdk microsoft coff binary editor is the full name

or search in programmers heaven or symtel you should be able to land a copy of that old rugged warhorse

5aLIVE
May 25th, 2005, 15:04
"just changing imagebase with some hexeditor will make it load at a differnent address but you also need to change all those absolute referances for making the image work"

>Hmm, that sounds like more trouble than it's worth. My time would probablt be better spent stepping through the code trying to learn how some of the functions work.

I just fail to understand why the applied comments or labels can't be seen. After all, the labels and comments are expressed as absolute addresses in a MAP file, so they should be unaffected by the process of relocation.

The fact that SoftICE can break sucessfully on a given label or comment on the relocated code from a MAP file translated to a NMS file confirms this.

I'll probably just add user-defined comments manually for the sub-routines of interest. The only other thing I haven't mentioned is the DLL doesn't have the traditional .DLL extension, though I wouldn't expect this to be a problem would you?

Thanks,
5aLIVE

5aLIVE
May 26th, 2005, 02:18
I meant say that labels and comments are expressed as relative addresses in a MAP file, not absolute.

Regs,
5aLIVE

5aLIVE
May 26th, 2005, 07:56
PROBLEM SOLVED: (user error)

It wasn't until I reread the readme.txt in MapConv which states that dynamic resolution of the address of code section should now work for dlls and other processes that don't have codebase = 00401000h.

I then looked in the plugins source code to see what I could learn and saw the line:
pmodule = Findmodule((ulong)GetCurrentEIP());

I was then I realised that the EIP was outside the code section of the DLL. Applying the map inside the module code did exactly what I was hoping for all along. Doh!

It should now be obvious to you that I am somewhat new to this whole experience and still learning how to use this fine debugger.

Thankyou @oh me anon for taking the time to reply with such excellent help!

5aLIVE

blabberer
May 26th, 2005, 13:41
i was all the time thinking you were applying it to the module and not to some unknown place well it reminds me never to ignore the obvious
btw all this time i was thinking masm had the original editbin from ms
but nope it just gets the Argv argc and appends -edit before it
and passes it to link and linker is doing the job of relocating i had a nice time looking at the relocating code
it ends up at LdrRelocateProcessBlock in ntdll which does the job

xxxxx
May 27th, 2005, 08:33
Hey, you don't need such mumbo - jumbo
Just take GODUP - select dll in cpu window from Olly debugger and use mapload from it

- godup contains imporved version of map loader so he can load it for any of dll-s

godfather+
(GODUP autor)