Welcome to the new Woodmann RCE Messageboards Regroupment
Please be patient while the rest of the site is restored.

To all Members of the old RCE Forums:
In order to log in, it will be necessary to reset your forum login password ("I forgot my password") using the original email address you registered with. You will be sent an email with a link to reset your password for that member account.

The old vBulletin forum was converted to phpBB format, requiring the passwords to be reset. If this is a problem for some because of a forgotten email address, please feel free to re-register with a new username. We are happy to welcome old and new members back to the forums! Thanks.

All new accounts are manually activated before you can post. Any questions can be PM'ed to Kayaker.

Changing the address a dll references

Support forums for OllyDbg 32-bit Assembler-Level Debugger.
Developed by Oleh Yuschuk (http://www.ollydbg.de)
Locked
Steve110
Junior Member
Posts: 3
Joined: Tue Jun 19, 2012 3:42 am

Changing the address a dll references

Post by Steve110 »

Let's say I have 3 dlls called A, B and C
C was created long before A and B existed

A has this address and code 00431415 |. FF15 40BC4300 CALL DWORD PTR DS:[43BC40] ; C.#10043
but the real location for this in the A.dll is: 00000815 FF15 40BC0010 CALL DWORD PTR DS:[1000BC40]

C has this address and code at C.#10043
C.#10043 6FA88E60 A1 54D4A96F MOV EAX,DWORD PTR DS:[6FA9D454]
but the real location for this in the C.dll is: 00008E60 A1 54D4A96F MOV EAX,DWORD PTR DS:[6FA9D454]

Now let's say that C's command has moved from 8E60 to 8E65, how can I make A's command refer to it properly?

I searched through the memory map and looked through A's 'rdata' section which contains 'imports' thinking it has the addresses that link everything but when searching for '43BC40' or '40BC43' or '8E60' or '608E' I find no matches.

When I actually go to the address 43BC40 in the memory map which is in A's '.data' section I find this: 0043BC3E DA6F 60 FISUBR DWORD PTR DS:[EDI+60]
where the 43BC40 is the address for '60'

If I instead go to the address 40BC43 in the memory map which is in B's '.data' section I find this: 0040BC43 0000 ADD BYTE PTR DS:[EAX],AL

Im confused, what do I need to do to make A properly refer to C?
blabberer
Senior Member
Posts: 1535
Joined: Wed Dec 08, 2004 11:12 am

Post by blabberer »

please describe your problem a bit more clearer

call dword ptr ds:[XXXXX] is correct dis assembly

the other dis assembly you show doesn't look correct you are probably disassembling data instead of code

for example your nick steve can be disassembled to

00401036 /73 74 JNB SHORT msgbox.004010AC
00401038 |65:76 65 JBE SHORT msgbox.004010A0 ; Superfluous prefix

whereas it should be marked as data an ascii zero terminated string

00401036 . 73 74 65 76 65 31 31 30 00 ASCII "steve110",0

note both the above forms have same op-codes 73 74 65 76 65 which can represent either dis-assembly or data according to interpretation

so the dis-assembly you posted viz 0040BC43 0000 ADD BYTE PTR DS:[EAX],AL etc are probably bogus dis assembly or you are disassembling data


this command call dword ptr ds:[XXXXX]

will call the dword pointed by XXXXXX in the process address space

0043501A |. FF15 34A34400 |CALL DWORD PTR [44A334]

this will call the dword pointed by 44a334

0044A334 <&KERNEL32.GetModuleHandleW> DD E4 80 7C ��|

ie 44a334 points to 7c80e4dd

which means it will call GetModuleHandleW api in kernel32.dll

7C80E4DD kernel32.GetModuleHandleW $ 8BFF MOV EDI,EDI


also it seems you may be jumping into the middle of dis-assembly because you pasted 0043BC3E DA6F 60 whereas you were supposed to paste opcodes for 43bc40

and it should be 60 which means it is an opcode for pushad which pushes all the registers into stack for restoring later

which possibly indicates you are dealing with some sort of packer / obfuscator / crypter / protector / "XXX" tor's

7C80E513 60 PUSHAD

a clearer query may yield a specific answer
Steve110
Junior Member
Posts: 3
Joined: Tue Jun 19, 2012 3:42 am

Post by Steve110 »

That helps alot thank you.

Basically I am trying to update something that used to work with an older version of a program and doesn't work with a newer version of it because locations have changed, so my plan was to fix the broken locations by updating the old addresses with the new ones.

I tried viewing "43bc40" as different types and when I selected 'address' I saw this

0043BC40 6FA88E60 C.#10043 which seems to be the virtual address for "C.#10043 6FA88E60 A1 54D4A96F MOV EAX,DWORD PTR DS:[6FA9D454]"

1) So A.dll has: 00000815 FF15 40BC0010 CALL DWORD PTR DS:[1000BC40]
2) which becomes FF15 40BC4300 CALL DWORD PTR DS:[43BC40] ; C.#10043
3) and 2) points to 0043BC40 6FA88E60 C.#10043 in A.dll's '.data' section
4) which points to C.#10043 6FA88E60 A1 54D4A96F MOV EAX,DWORD PTR DS:[6FA9D454]
5) which has the real location in C.dll: 00008E60 A1 54D4A96F MOV EAX,DWORD PTR DS:[6FA9D454]

If I search through 'A.dll' with a hex editor I can't find "60 8E A8 6F" which is the virtual location which 3) holds for 4) and the only "60 8E" I can find is a part of this line of code, is this what I am looking for? : 00436790 |. 8D91 608E0000 LEA EDX,DWORD PTR DS:[ECX+8E60]

Is this "8E60" the base address for the C.dll "00008E60" address or just coincidence?
blabberer
Senior Member
Posts: 1535
Joined: Wed Dec 08, 2004 11:12 am

Post by blabberer »

well you are not clearer even now
and i would suggest you to spend a few sessions disassembling and understanding X86 assembly a bit before delving into modifying
your dlls

lenas tutorial for ollydbg is suggested a lot for starters

though i would prefer to suggest iczelion's assembly tutorials

a few questions to ponder

1) So A.dll has: 00000815 FF15 40BC0010 CALL DWORD PTR DS:[1000BC40]
2) which becomes FF15 40BC4300 CALL DWORD PTR DS:[43BC40] ; C.#10043 (how did you come to this conclusion) 1000bc40 can point to a single dword only

so 1000bc40 can point to <example> bc4015ff </example>

if you are using ollydbg right click on the line and do follow in dump and examine the first 4 bytes / dword
Steve110
Junior Member
Posts: 3
Joined: Tue Jun 19, 2012 3:42 am

Post by Steve110 »

[quote]1) So A.dll has: 00000815 FF15 40BC0010 CALL DWORD PTR DS:[1000BC40]
2) which becomes FF15 40BC4300 CALL DWORD PTR DS:[43BC40] ; C.#10043 (how did you come to this conclusion) 1000bc40 can point to a single dword only
[/QUOTE]

When I rightclick FF15 40BC4300 CALL DWORD PTR DS:[43BC40] ; C.#10043 and click 'view executable' it opens a new window giving me '00000815 FF15 40BC0010 CALL DWORD PTR DS:[1000BC40]' which really exists in the file A.dll which is why I came to that conclusion.

1 and 5 seem to be real locations in files whereas 2, 3 and 4 are not in real locations.

A.dll is somehow connected to C.dll and code in C.dll has moved around so I need to know what to edit in A.dll to make it point to the new code.
Locked