Printable View
I have no problems with push, mov and those sort of things when come to calling them from game/server.exe when I am inside of .dll function, but when it comes to do call <some pt function> its end like this:
CALL 0042F190
E8 F7 EC FF FF
become (@_o)/ (apparently I don't know why)
call near ptr 0F065F190h
E8 1E 91 42 F0
so my question is, how to call 0042F190 (function a dll)?
1) Add a named export for 0042F190 to the Export address table (EAT) of the game.exe ('ExportName')
2) GetProcAddress(hMain, 'ExportName')
3) TEST EAX,EAX
4) JZ _IncorrectGameExe
5) CALL EAX
A dll shouldn't CALL an arbitrary address, since the load-time linking of the main executable may (but not under NT kernel) dynamically re-base the executable at load time, and re-compiling the executable after source modification will (almost certainly) change the address of the function anyway.
What you are trying to do, is not meant to be done. You can do it if you write your DLL in assembler, and may or may not receive warnings. It may even work, for a specific executable, but OllyDbgs' code analyser would not recognise the code correctly because it is not "strictly speaking" legal, and definitely not safe.
But this is "static" address of the function and its not like i will get source code of PT server and compile it ;)Quote:
Originally Posted by bobsobol
I a bit don't understand CALL, its not contain "0042F190" but some strange HEX in HEX dump "E8 F7 EC FF FF", its this what you are trying to say? Thats why I can't call it without exporting it first?
So it would be much better to move those functions to dll?Quote:
Originally Posted by bobsobol
Illegal code will be only in dll but I don't want to use register for CALL EAX. I cant do call ExportName?
An executable 32-bit PE is a Dynamically Loaded Library (with a pre-defined entry point of main() or WinMain() rather than DllMain()). There is (in the strictest terms) nothing static about it. The "base address" for the code section (usually "400000h") is only a "preferred" memory location, and the Win32 specification allows for that to be "re-based" at load time. The fact that all the NT Kernels have sufficiently advanced virtual address spacing (32-bit flat memory model) for process' to allow a main Executable to always get what it sees as it's preferred base address is besides the point. The specification does not require the kernel to be so precise, and in Win32s and early Win95, the Kernel certainly was not, and usually re-based executables as the Kernel it's self was running in a single "32-bit flat" model under DOS.Quote:
Originally Posted by Vormav
Also besides the point, as reverse software engineering a two way PE to PE static address reliance is not a "legal" thing to do under the Win32 environment either. "Possible" probably, "legal" no.Quote:
Originally Posted by Vormav
--- EDIT ---
This is the way you would use routines in a 32-bit protected mode DOS module (.mod), and that's fine if the address space is guaranteed to be used only by one process for the entire lifetime of that process, that the process can read and write to any address in memory, overwrite and destroy the "in memory" view of the Kernel if it wants to, (not so "protected") and the only programs in memory are the BIOS, Kernel and maybe a few TSRs (Terminate and Stay Resident programs) for the Mouse and CD-ROM drivers.
The NT Kernels (even NT3.0) come close to replicating this by giving each process (and all it's threads) access to a single virtual address space. However, the location and size of global dynamic Kernel Modules (.sys files for the most part) and the Windows Object NameSpace will still vary from PC to PC, and change dynamically as your system receives updates to the Kernel, core system libraries and OEM drivers.
Besides which, we should not assume that Microsoft will always follow the same model for future Kernels.:wink:
---/EDIT ---Possibly. Looks to me like twos compliment. IE the mnemonic is assembled to binary as E8 (Relative CALL, probably) -1307h. Which is outside the range of the DLL (which can be loaded anywhere in the virtual address space, regardless of Kernel fork and edition) and will therefore probably be wrong.Quote:
Originally Posted by Vormav
--- EDIT ---Quote:
Originally Posted by Vormav
In short... probably. But you may well have the same issues the other way around. The PT server (and client) routines use a lot of "global variables" rather than passing pointers to data structures on the stack, and locating those globals from your DLL is just as fraught as CALLing a routine. Assume a static position (I did with the protocol.dll) but at your own peril. :wink:
Note also, that if you can force your CALL to be "absolute" rather than "relative", you may get away with it, just as a specific "JMP LONG" will work. (under NT style Kernels) I'm guessing you are using Olly as your "assembler", and it always picks the shortest, then fastest form of each mnemonic. So it will "JMP SHORT" when it can get away with it, and (I guess) CALL "relative" when it can get away with it.
---/EDIT ------ EDIT ---Quote:
Originally Posted by Vormav
You can if you statically link, but remember that it should be CALL [ExportName] where "[ExportName]" is the location of the pointer in your DLLs Import Address Table... not the one in the main executables Export Address Table. (which is still "out of scope")
If you work via GetProcAddress() you have to CALL the address returned in EAX, but of course you can store it in another register or memory address first if you like.
---/EDIT ---
Strictly speaking, all PE files are DLLs, the "shell" (explorer.exe, Shell32.dll, CMD.EXE) may treat .exe, .dll, .ocx, .scr, .ac etc in slightly different ways, but the KE does not. You can even trick ShellExecute() into loading a .dll file as a Main executable... especially if it was compiled (more specifically, linked) as a .exe and renamed. You can also link a .exe to another .exe the same as you would to a .dll, and import functions from it.
Don't consider them to be two different entities, they are actually variants of the same 'kind' of package. Conventions adopted by the linker at build time may be different, and a different flag is set in the header (to indicate what type of entry point they hold, and therefore how the stack frame the KE passes them should be formatted. main(argc, argv) for Console .exe, WinMain(hInstance, hPrevInstance, lpCmdLine, nCmdShow) for GUI .exe or DllMain(hInst, fdwReason, lpvResurved) for .dll) and whether or not they should be allocated default stdout, stderr and stdin streams to, or from a console. But other than that there is no real difference.
And there is nothing to stop "mutual dependence" between two .dlls, provided there is a valid export which is imported each way. Likewise game.exe exports various Zip compression functions which can be used by some of the security .dlls it is often packaged with.
This is the method you should use. Sadly, tools like CFF Explorer Suite and StudPE only allow automated extending the IAT, not the EAT. So you have to resort to manual means. :(: If anyone knows a tool, or plugin to another tool (CFF Explorer Suite supports plugins and scripting) that can automate it, please let us know. I would love to add all my OllyDbg labels for subroutines and functions to the EAT.
References:-
Some useful info, and a lot of dead links
Sound theory from Iczelion
--- EDIT ---
Incidentally, you can, and should export pointers to data structures or variable storage in your PE if you intend to read or modify them in a different module linked at load-time (via IAT & EAT) or run-time (via LoadLibrary()). (another Portable Executable, or PE) Just as you should create a definition in a .h file if you intend to use functions or data build into a .lib file from another C source file... otherwise the compile time linker won't know where to link the PE pointers (fix-ups) when building the compile time linking.
---/EDIT ---
Thank you, I think I gathered enough info for current project.
Actually I got tired of using other ppl servers and started building my own based on JPT server4096 and newest Test KPT client.
I am making PT more "modular" (everything is based on dlls that I hate so much, security will be pain in a~~ss) so I will be able to edit/move to other server/client any data that is changing in new versions on the fly without fixing offsets.
I need to read your links too, extending export table would be very useful in my case.
I have one more question in mind, why is so important to add new code to .text section and not to newly created .text2? Is it somehow more secure, faster, stronger, better? PT .exe is protected by checksum that you enable in hotuk.ini anyway?
PS. do you know if its possible to "find all and replace" with olly, like find all CALL 0042F190 and replace with CALL 00666666? Because they don't have normal address I can't use hex editor for that job :/ maybe some plug-in or other app?
Server executable really doesn't need all the checksums and nonsense, unless you regularly allow your players to log in to the servers remote desktop. XD
This is why I think it's easier to convince people (with systems like my DLL Build Environment) to use DLLs in their server than their client.
There is no reason not to add a .text2, if you set the sections protection correctly, and provided you are happy to accept the loss of virtual address space taken up by the new section. A good reason not to do this is that if you are moving routines out into a DLL file, then you are freeing space in .text anyway and your DLL will take up more room in the limited 2Gig virtual address space of the process too. ^_^
If you are looking at advantages to DLLs over adding sections; new sections can only really be "assembled" into in Olly, where you can develop DLLs in any language. You can use an assembler like GoAsm, FASM, NASM, TASM or MASM, and modifications to your source code will automatically re-align labels and data structures around your changes for you, and you can develop them further into C or C++ programs where you can import standard routines for hashing algorithms, encryption, compression etc.
Of course every .lib you include in your high level DLL source (or Assembler source) will add to the memory overhead, and if many DLLs are going to access the same routines, you may well want to link the .lib library routines into a single, common DLL that other DLLs address independently. :wink:
1. Create a thread in a seperate dll
2. Call a function inside the main executable from the thread you created
Why do you guys always make it harder than it is. xD???Code://global
typedef int (*g_tFunction) ( int, int ); // parameters here
g_tFunction MyFunction = NULL;
//call once to point it to the right location
MyFunction = (g_tFunction)&bla;
//call the function
MyFunction( 2, 3 );
@Filterheadz but harder not necessarily mean bad :)
I think I will try your function but I like (a lot :)) idea of adding PT function to export table and than importing that function to dll and calling it from there :)
...if only adding PT function to export table would not look so damn hard :)
PS. anyone would like to write CFF Explorer extension: "export adder"? >=P
I "like" that Filter, but only as a "hack". It's a great example of how to implement GM commands without a GM account (even if hotuk.ini is disabled) via DLL injection... but that isn't something we should be advertising. :wink:
How would you implement Step 1 without injection I wonder?
LoadLibrary(), GetProcAddress() then CreateThread() on the return from GetProcAddress()?
How quickly can we TerminateThread()? The more threads, the more screen lag. :wink:
It was not so hard to add PT function to export after all.
But I see problem here. If I export it with a name I get error when I start game.exe/my.dll in ollydbg:
"Bad or unknown format of 32-bit executable file"
...of course files working but not that exported/imported part.
However if I export and import files using not names but ordinal things are working... or should work if I could call that function by its ordinal so my question is:
I have game.exe that export its function by ordinal number 0000000C
and dll that call other function in PT that need to call function that I exported in game.exe (I know its confusing =P)
How to 'CALL 0000000C' ordinal in dll from game.exe?
I would love to see a guide on how you actually did that.Quote:
Originally Posted by Vormav
I suspect that you have manipulated the export table in some manner which is only just workable. It's not uncommon to find compressed executables, after decompression, will still work but are very problematic in Olly, CFF, PE Explorer, StudPE and such tools... because the KE is quite loose with the PE standards.Quote:
Originally Posted by Vormav
It can, and will work with PE files which aren't completely correct... and many exe encryptors take advantage of this. :wink:
However, the KE changes slightly with each service pack to Windows... so what works for you now, may not work for others (on a different kernel version or build) and may cease to work for you as you receive updates.
If you have managed it at all, a guide to your method may allow others (I'm keen to try) to improve upon that method to a point where no tool can distinguish it from a direct compile & link build.
I've tried dumping the sections from game.exe and the server executables, and creating .def files and .asm Assembler "source"(basically offsets, section definitions and db statements for the most part)from them to re-link them, with the aim of being able to modify imports, exports, section sizes, routine and data locations and rebuild the executable, much as you would if you actually had the true source code... or at least the assembler from a gcc -S style compile without assemble and link.
I think it's a good way to go, because we can build upon that. Each time getting closer and closer to a complete decompilation. But I've never got my methods completely bug-free, and the builds need to be tweaked in Olly to get them to keep running for more than a few seconds. Mostly because I'm not 100% on the actual format of the IAT and EAT, since different linkers create them very differently, and yet the KE and CFF and such just read them the same. It seems to be a very flexible data structure.Names and Ordinals of exported functions and data structures have been present in 16 and 32 bit Microsoft OS since the LE / LX executables formats for OS/2 and Windows 2. In OS/2 and Windows 2 to 3.x linking via Ordinal is preferred. But in Windows NT 3.5 and Win32s for Windows 3.1+ Microsoft depreciated the method because people (including Microsoft themselves) wanted to drop old functions from new versions of DLLs and keep adding new exported functions. Managing the Ordinals with .def files in an IDE, and still maintaining compatibility was very difficult. But even that shift (famously) didn't prevent the classic "DLL Hell" situation on the Win32 platform. (The next attempt was "side-by-side configuration" which comes with VC.net 2002 v7, but that's another story.)Quote:
Originally Posted by Vormav
If you look at game.exe with a PE file analyser, you should notice that many functions from many of the DLLs it uses are imported via their Ordinal, not their Name. (DSound.dll, OLEAUT32.dll, WSock32.dll)Spoiler:
In any case... CFF explorer will let you add imports by ordinal or name.
From high level languages, it's all down to the .def file passed to the linker, and whatever they use as to import DLL functions. Some compilers build a .def from the headers in your C source / Assembler or what-ever, where others expect you to create and manage your own .def files and .h, .bin or .lib files created when you build your DLL. (game.exe in your case XD) (FASM and GoASM use their own linker and don't need .def files, though GoLink can use a text file similar to a Microsoft .def, but doesn't need .h, .bin for importing, as it will go straight to the IAT of any .dll (or .exe etc) that you "include" / "import" functions from, and that's why I name them .def in my DLL-BE GCC link doesn't expect .def files, Visual Development Suite re-creates .def files from the IDE, but expects you to create and maintain them if you build from the command line with nmake or such, and MASM will require you to create .def files before linking. I've never been good with using Delphi or BCB without the IDE, but TASM and Turbo C++ could, IMS, use .def files or not, it was up to you.)
see MSDN documentation on .def Module Definition files, and an interesting MSDN article on different ways to use exported functions (specifically how to use "MAKEINTRESOURCEA macro to convert that ordinal into something that GetProcAddress can understand")
--- EDIT ---
Having said GCC doesn't use .def files, I've found an example which uses them. XD So clearly it's optional there too.
I'm not always right you know. :wink:
---\EDIT ---
Ok, here is tutorial:
- first we have to find our export table (you can find in many ways, for example by searching for "game.exe" string, if this is game.exe)
- here is how CFF Explorer see export function table:
http://forum.ragezone.com/attachment...1&d=1294004494
- when we find it we will see something like this:
(i will color some parts so we can understand it better)
Red - export directory for game.exe - edit in CFF Explorer for "clearer view"Code:00 00 00 00 31 1E 08 4D 00 00 00 00 E6 CF 1F 00 ....1..M....µ¤..
01 00 00 00 0B 00 00 00 0B 00 00 00 78 CF 1F 00 ............x¤..
A4 CF 1F 00 D0 CF 1F 00 10 14 01 00 B0 63 01 00 ń¤..đ¤......¦c..
90 18 1B 00 80 19 1B 00 10 1E 1B 00 50 1D 1B 00 É...Ç.......P...
00 1C 1B 00 D0 18 1B 00 00 1A 1B 00 00 83 1A 00 ....đ........â..
E0 33 01 00 06 D0 1F 00 16 D0 1F 00 20 D0 1F 00 Ó3...đ...đ.. đ..
35 D0 1F 00 45 D0 1F 00 4F D0 1F 00 57 D0 1F 00 5đ..Eđ..Ođ..Wđ..
EF CF 1F 00 FB CF 1F 00 65 D0 1F 00 5F D0 1F 00 ´¤..ą¤..eđ.._đ..
02 00 03 00 04 00 05 00 06 00 07 00 08 00 00 00 ................
01 00 0A 00 09 00 67 61 6D 65 2E 65 78 65 00 5F ......game.exe._
43 6C 6F 73 65 44 33 64 40 30 00 5F 49 6E 69 74 CloseD3d@0._Init
44 33 44 40 34 00 53 65 74 45 78 74 43 68 61 6E D3D@4.SetExtChan
67 65 5A 69 70 00 55 6E 5A 69 70 44 61 74 61 00 geZip.UnZipData.
55 6E 5A 69 70 44 61 74 61 54 6F 44 69 72 65 63 UnZipDataToDirec
74 6F 72 79 00 55 6E 5A 69 70 44 61 74 61 54 6F tory.UnZipDataTo
46 69 6C 65 00 55 6E 5A 69 70 46 69 6C 65 00 5A File.UnZipFile.Z
69 70 44 61 74 61 00 5A 69 70 46 69 6C 65 00 66 ipData.ZipFile.f
63 45 58 50 00 5F 73 6D 50 6C 61 79 44 33 44 40 cEXP._smPlayD3D@
32 34 00 24.
This part contain:
And we going to edit that in CFF laterCode:TimeDateStamp:
MajorVersion
MinorVersion
Name
Base
NumberOfFunctions
NumberOfNames
AddressOfFunctions
AddressOfNames
AddressOfNameOrdinals
Blue - export address table for game.exe - we will also edit that in CFF Explorer (contain addresses of exported functions)
Green - export names table for game.exe - another part of code that have hands, legs and head only in CFF Explorer (contain addresses of function names)
Magenta - export ordinals table for game.exe -
we can only edit it in hex editor (its already messed up because ordinals are not in order)
- 04 00 05 00 06 00 07 00 08 00 00 00 01 00 0A 00 09 00
example of order:
- 00 00 01 00 02 00 03 00 etc... 0, 1, 2, 3...
it work this way and CFF Explorer will show functions in ordinal order (fixed 0, 1, 2, 3...) and not messed one so we have to remember that
Orange - export names table for game.exe - names for functions, edit with hex editor (sometimes CFF Explorer get a bug and will change your function name to 3 letters or/and add "trash hex" till the end of section).
- OK, now when we know what we have we can start moving this.
- because game.exe have around 1000h space under export table we will use that, remember we are moving on existing space with HEX editor and not adding anything so we will not damage exe
- for first time we going to add only one function to export (for two we double values and for three we triple them)
(its good to do this in ollydbg, binary copy and past)
- MOVE Green, Magenta and Orange by 4h and change new space to "E0 33 01 00" last 4h of Blue part
- MOVE Magenta and Orange by 4h and change new space to "5F D0 1F 00" last 4h of Green part
- MOVE Orange by 2h and hex edit new space "67 61" to new ordinal number "0B 00" because this is 12 function in export (13 would be 0C 00)
- Edit end of Orange part, after "5F 73 6D 50 6C 61 79 44 33 44 40 32 34 00" "_smPlayD3D@24 " write your function name
- in HEX editor you should see something like this now:
Cyan - parts that where created and edited by moving dataCode:00 00 00 00 31 1E 08 4D 00 00 00 00 E6 CF 1F 00 ....1..M....µ¤..
01 00 00 00 0B 00 00 00 0B 00 00 00 78 CF 1F 00 ............x¤..
A4 CF 1F 00 D0 CF 1F 00 10 14 01 00 B0 63 01 00 ń¤..đ¤......¦c..
90 18 1B 00 80 19 1B 00 10 1E 1B 00 50 1D 1B 00 É...Ç.......P...
00 1C 1B 00 D0 18 1B 00 00 1A 1B 00 00 83 1A 00 ....đ........â..
E0 33 01 00 E0 33 01 00 06 D0 1F 00 16 D0 1F 00 Ó3..Ó3...đ...đ..
20 D0 1F 00 35 D0 1F 00 45 D0 1F 00 4F D0 1F 00 đ..5đ..Eđ..Ođ..
57 D0 1F 00 EF CF 1F 00 FB CF 1F 00 65 D0 1F 00 Wđ..´¤..ą¤..eđ..
5F D0 1F 00 5F D0 1F 00 02 00 03 00 04 00 05 00 _đ.._đ..........
06 00 07 00 08 00 00 00 01 00 0A 00 09 00 0B 00 ................
67 61 6D 65 2E 65 78 65 00 5F 43 6C 6F 73 65 44 game.exe._CloseD
33 64 40 30 00 5F 49 6E 69 74 44 33 44 40 34 00 3d@0._InitD3D@4.
53 65 74 45 78 74 43 68 61 6E 67 65 5A 69 70 00 SetExtChangeZip.
55 6E 5A 69 70 44 61 74 61 00 55 6E 5A 69 70 44 UnZipData.UnZipD
61 74 61 54 6F 44 69 72 65 63 74 6F 72 79 00 55 ataToDirectory.U
6E 5A 69 70 44 61 74 61 54 6F 46 69 6C 65 00 55 nZipDataToFile.U
6E 5A 69 70 46 69 6C 65 00 5A 69 70 44 61 74 61 nZipFile.ZipData
00 5A 69 70 46 69 6C 65 00 66 63 45 58 50 00 5F .ZipFile.fcEXP._
73 6D 50 6C 61 79 44 33 44 40 32 34 00 46 69 65 smPlayD3D@24.Fie
6C 64 53 75 62 46 75 6E 63 31 00 ldSubFunc1.
- open game.exe with CFF Explorer and we should see something like this:
http://forum.ragezone.com/attachment...1&d=1294009257
- do what you see in red, do hex math and get new offset of different table part
- IMPORTANT(!!): 1st do table offsets:
Name (in my example 1FCFE6+A=1FCFF0)
NumberOfFunctions (in my example B+1=C)
NumberOfNames (in my example B+1=C)
AddressOfNames (in my example 1FCFA4+4=1FCFA8)
AddressOfNameOrdinals (in my example 1FCFD0+8=1FCFD8)
- Save and open CFF Explorer again
now do rest:
1st exported function 1FCFEF + A = 1FCFF9
till the last one.
- save and open game.exe with CFF Explorer again
this time you will see new function on end:
(000133E0 is not FcEXP address)Code:0000000C 000133E0 000B 001FD069 fcEXP
and this is base for new function export
first of all lets get address of fcEXP
- in my game.exe its 005A8300 (001A8300 in export table)
and I would like to have for example function at 00431B30
to get address that will work on export table we do hex math:
005A8300 - 00431B30 = 1767D0
001A8300 - 1767D0 = 31B30
31B30 is the new export address of function at 00431B30
we using CFF Explorer and we put that number (to Function RVA) where "000133E0" was before.
- we also need name of our new function so we:
001FD069 + 14 = 001FD07D and we have new function name (why +14? because this new name of function start after 14h from fcEXP name)
And thats all congratulations you exported your function manually for the first time :)
if you get some errors or you are unable to call function by name than change:
NumberOfNames back to 0000000B and call it by ordinal
@bobsobol well I know how to call ordinal (I got it after I posted this =P) but its working in "debugger only" so maybe there is other way?
I also need to fix this export table, put functions in order because they might get lost and thats why i have error with exporting by name.
PS. if some parts are unclear than I will explain them better, just ask.
Wow... that should really be a Tutorial thread. It's awesome.
I think I would like to try to use your method to add .idata and .edata sections to the exe (more like GCC than VC link.exe) before the .rsrc section but after everything else. Give them a bit of room so I can add and remove imports and exports as I like.
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 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)
Thanks again for this, it's really really useful, and explains a lot of why the format of these tables can look so different in hex and still work fine. :thumbup1:
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
If you can CALL or JMP FAR and if you can guarantee that the kernel isn't going to re-base the executable during load-time. (NT3 - Win7 will not, Win32s - ME may)Quote:
Originally Posted by UserNameHere2
Personal rant, somewhat OT:-
Yes. As Filter shows, it's easy to hack an entry point into the main game... but is that the best thing for us to do? Is that really the best we can do to help each other out? And if the answer there is "yes" then I don't see any reason not to simply add sections the GlobalFantasy way and put our code and data in that.Spoiler:
You have to rewrite it every time you change your base client, can't use high level source, (or even build from low-level source files) your exe gets bigger and bigger, and more and more full of redundant code that's been replaced with updated routines which nobody but you ever really understood how it works. You can "share" your exe here, but maintaining requests from other developers soon becomes very very tiresome. (And good developers leave, tired of noob questions.:(:)
The more documentation, the better... otherwise you are just working for your self, and there is no "community" here. (as has been argued, and not without cause)
Q: What is the offset of the teleport cores code, as a specific address which is common to every game.exe from the early betas to the latest release, in every language variation of the official PT client? (Only a single 32-bit address will be accepted as proof that doing this, rather than describing how to find the code and make a named export in the exe is preferable. :wink:)
The only alternative is to write the DLL Filters way, define the "entry point" as a constant in the released source code and provide detailed instructions on how to locate the address in individual developers clients which that constant should be set to before building the DLL. ^_^ (and even that is not as clean)
For exactly same reason why your nick on this forum is "UserNameHere2" and not user number "768769".Quote:
Originally Posted by UserNameHere2
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 hope you can find bug in this.Quote:
Originally Posted by bobsobol
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.
Funny, I don't have same problem, what HEX Editor shows CFF shows exactly the same.Quote:
Originally Posted by bobsobol
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--
I doubt you will even know what the actual name (if there is one) in their source was. It may well be in Korean. >.<Quote:
Originally Posted by Vormav
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.I was only quoting from your screenshots. They are different. :scared:Quote:
Originally Posted by Vormav
Why not CALL DWord Ptr DS:[1002D059]?Quote:
Originally Posted by Vormav
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.Quote:
Originally Posted by Vormav
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.
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 :DQuote:
Originally Posted by bobsobol
Quote:
Originally Posted by bobsobol
0x001FCF74 is offset and you can't edit that (its not in export table).Quote:
Originally Posted by bobsobol
0x001FCFD0 is actual AddressOfNameOrdinals value.
0x001FCF74 means that AddressOfNameOrdinals is pointing where it is:
Code:005FCF74 dd rva word_5FCFD0 ; AddressOfNameOrdinals
0x001FCF74 0x001FCFD0
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.Quote:
Originally Posted by bobsobol
I wandering if you found some more problems with export by name that I can check, because export by ordinal is 100% working.