Re: How to call PT function from .dll?
Quote:
Originally Posted by
UserNameHere2
Why are you guys bothering with giving the function you want to use in the DLL a name and put it inside the export table of the .exe?
If you know the offset you can call it just straight away, you don't need GetProcAddress for that
For exactly same reason why your nick on this forum is "UserNameHere2" and not user number "768769".
Quote:
Originally Posted by
bobsobol
Wow... that should really be a Tutorial thread. It's awesome.
When it will be more "stable" and "documented", right now probably only you and I see bright sides of exporting functions :)
Quote:
Originally Posted by
bobsobol
I think I can see the problem with the export names, but I'll have to play with the technique a bit to be sure.
I hope you can find bug in this.
I just segregated my functions in export table (all in HEX editor only to be sure if its not some CFF Explorer bug), right now everything is in order but still I get exactly same bug. Only when I don't add name to exported function and export from exe as ordinal I can use that function. Maybe I should find "real name" of the function? Its not "sub_431B30" or something like that? int __stdcall game_12(LPCSTR lpString2, int)? I am not sure how in "source" they called it.
Quote:
Originally Posted by
bobsobol
I also notice many of the offsets in Hex are some small amount (header or some such) off from the values shown in CFF Explorer. (fe. AddressOfNameOrdinals = D0 CF 1F 00 = 0x001FCFD0 where CFF shows 0x001FCF74)
Funny, I don't have same problem, what HEX Editor shows CFF shows exactly the same.
Right now I am able to call function from game.exe by its ordinal number (yay!) but I see small problem. Here is what I do.
I import my new function from game.exe by its ordinal number game.#12
to new section .idata in .dll and to call it I do this:
CALL 10006000
in 10006000 I have:
JMP DWORD PTR DS:[1002D059]
and in Ollydbg its look like perfect model, call see jmp and jmp can jump to new function in debugger.
However when I run PT and get to this part, addresses of dll are different.
The exported address is in:
FieldFunc.dll:0024D059
and not 1002D059
When I change :
JMP DWORD PTR DS:[1002D059]
to
JMP DWORD PTR DS:[24D059]
Everything is working and new function I exported by ordinal is called.
So my question is:
Is it save to use JMP DWORD PTR DS:[24D059]?
Will this change on different OS or when I change something in DLL?
Or I should do something like this:
JMP DWORD PTR DS:[current_address+27059]?
If so... how to do it in the simplest ever know to man way?
--EDIT--
nvm that question I figure it out, I can do:
mov eax, [esp]
and I will get my address in EAX.
I am still not sure if JMP DWORD PTR DS:[24D059]
is 100% safe, I am moving inside of .dll after all, so correct me if I am wrong but unless I move my .idata table address will not change?
--EDIT--
Re: How to call PT function from .dll?
Quote:
Originally Posted by
Vormav
I hope you can find bug in this.
I just segregated my functions in export table (all in HEX editor only to be sure if its not some CFF Explorer bug), right now everything is in order but still I get exactly same bug. Only when I don't add name to exported function and export from exe as ordinal I can use that function. Maybe I should find "real name" of the function? Its not "sub_431B30" or something like that? int __stdcall game_12(LPCSTR lpString2, int)? I am not sure how in "source" they called it.
I doubt you will even know what the actual name (if there is one) in their source was. It may well be in Korean. >.<
Most of the functions or subroutines are simple cdecl, but some are fastcall, and others are clearly C++ methods... If you really wanted to "go the whole hog" you could try to mimic VCs Name Mangling, which can then be used by tools like PE Explorer to tell you what format the parameters are. These aren't in any way necessary though.
I would avoid largely numeric names though. I use numbers, like the functions XTBS1, XTBS1.1, XTBS2 etc... but it's not a very clean way to name functions. If you are patching the function, or calling it from your DLL you must have some idea what the function does. I try to think what I would call the function if I was writing the program.
Quote:
Originally Posted by
Vormav
Funny, I don't have same problem, what HEX Editor shows CFF shows exactly the same.
I was only quoting from your screenshots. They are different. :scared:
Quote:
Originally Posted by
Vormav
Right now I am able to call function from game.exe by its ordinal number (yay!) but I see small problem. Here is what I do.
I import my new function from game.exe by its ordinal number game.#12
to new section .idata in .dll and to call it I do this:
CALL 10006000
in 10006000 I have:
JMP DWORD PTR DS:[1002D059]
Why not CALL DWord Ptr DS:[1002D059]?
Quote:
Originally Posted by
Vormav
and in Ollydbg its look like perfect model, call see jmp and jmp can jump to new function in debugger.
However when I run PT and get to this part, addresses of dll are different.
The exported address is in:
FieldFunc.dll:0024D059
and not 1002D059
When I change :
JMP DWORD PTR DS:[1002D059]
to
JMP DWORD PTR DS:[24D059]
Everything is working and new function I exported by ordinal is called.
So my question is:
Is it save to use JMP DWORD PTR DS:[24D059]?
Will this change on different OS or when I change something in DLL?
Or I should do something like this:
JMP DWORD PTR DS:[current_address+27059]?
If so... how to do it in the simplest ever know to man way?
--EDIT--
nvm that question I figure it out, I can do:
mov eax, [esp]
and I will get my address in EAX.
I am still not sure if JMP DWORD PTR DS:[24D059]
is 100% safe, I am moving inside of .dll after all, so correct me if I am wrong but unless I move my .idata table address will not change?
--EDIT--
If you look at how imported functions are normally called, the disassembly should show CALL DWORD PTR DS:[<&game.exe!FunctionName>] but you can't assemble it like that, you have to assemble CALL DWORD PTR [24D059] and let the disassembler figure out that that relates to an import offset, and fill in the details. There are a couple of records in the IAT which match the right address, and I often get the wrong one first time. When I do (get it wrong) I experience problems similar to those you are describing.
I know I've got it wrong when the disassembler cannot read the function name and displays something like CALL DWORD PTR DS:[24D059]instead of something like CALL DWORD PTR DS:[<&game.exe!FunctionName>], but with only having Ordinals, and no name, I'm not sure what it would show. I've never seen it in 32-bit PE linked files. I would expect to find something like CALL DWORD PTR DS:[<&game.exe!#3] for function number 3.
To try to minimise my "mistakes" I usually copy a function call in the module I'm editing which shows "normally" in the disassembler. (ie [<&MODULE.EXT!FunctionName>] notation) Press 'space' and look at the "assembler" form (not the "disassembler" form) and use the "dump" pane to locate the correct table of addresses in module. (View the dump as Integer -> Addresses, and the names or ordinals should be listed as labels next to the virtual address in the dump)
Hope that helps.
Re: How to call PT function from .dll?
Quote:
Originally Posted by
bobsobol
Why not CALL DWord Ptr DS:[1002D059]?
For two reasons, 1st CALL 1002D059 taking less space than CALL [1002D059] so I will destroy code below and 2nd I am editing function that have over 300 CALLs if I will ever need to extend space and add code I can fix few JMPs and not 300 CALLs :D
Quote:
Originally Posted by
bobsobol
I also notice many of the offsets in Hex are some small amount (header or some such) off from the values shown in CFF Explorer. (fe. AddressOfNameOrdinals = D0 CF 1F 00 = 0x001FCFD0 where CFF shows 0x001FCF74)
Quote:
Originally Posted by
bobsobol
I was only quoting from your screenshots. They are different.
0x001FCF74 is offset and you can't edit that (its not in export table).
0x001FCFD0 is actual AddressOfNameOrdinals value.
0x001FCF74 means that AddressOfNameOrdinals is pointing where it is:
Code:
005FCF74 dd rva word_5FCFD0 ; AddressOfNameOrdinals
0x001FCF74 0x001FCFD0
Quote:
Originally Posted by
bobsobol
Hope that helps.
It did, I have no problems with finding real offset but I wanted to be sure if address can change on its own when code will run on different OS or under WINE.
I wandering if you found some more problems with export by name that I can check, because export by ordinal is 100% working.
