Source Code For Tutorials, Colony And Campaing Dll

[Brazilian Fan]

i was translating the DLLs using Hex WorkShop 4.42, but when i need more space (inserting more characters) OP2 don't read the modified DLLs. So i was thinking in remaking the DLLs but no one have the source code for them. It wouldn't be difficult to rewrite them all, but it would take a lot of time that i don't have. I don't really know the problem.

HELP ME PLEASE!

I don't want to stay months rewriting the DLLs when I could be helping in others parts of the community (mapper, coding) and writting my story (Outpost 3: NeoGenesis Theory).

[Mcshay]

I belive op2hacker has a program that can fix that problem (op2 not using the dlls).

If we were to completely rewrite the dlls, it would take ages. A basic multiplayer map can be made in 4-5 hours, but the campaign missions would take much longer. Especialy the ones with AIs. Plus there would be slight differences in the way the dlls worked. They wouldn't be exact copies.

[Hooman]

When the compiler output the DLLs, the data tends to get packed in fairly close. If you try to overwrite past the end of a string, you'll probably overwrite some other important data and make the DLL unusable.

The easiest solution is to write the new string somewhere else, say extend the data section or something or find some unused space and write the new string there. But then you still have to update the references to the old string to point to the new string. Sometimes that easy though. At least when they use a table of pointers to strings to access the string data. Then you just need to update that one table entry.

You might run into more complications in practice though. Like if youe xtend the data sectionso it collides with the heap. I'm not sure if the heap is at a fixed location or is calculated based on the size of the data section in the exe. In any case it usually comes right after the static data, which is the part of the data section stored in the exe, so extending it might have a problem here. The other big issue is if the references to the old string are hard to find. It might not be obvious how the string is accessed and it can be accessed differently from different points.
 

[Brazilian Fan]

Ok, i understood the result but not the process. How can I insert a string reference in a c++ compiled DLL (what tipe of programs and what to do)? I have some experience in Java but c++ is a mistery for me (even they're very close, java and c++). With some compares i can understand how insert references in a DLL.




 :op2:  

[Hooman]

It's been a very long time since I've done any of this, and I don't think I have the time to get into it again. Hacker would probably be a better source of information now.

I think I used something like PE Explorer to increase the size of the data section. Maybe I'm wrong about the name, but it was easily found with Google and was free to use. There is a way to increase the size of the data section with it. I used it once on Outpost2.exe to insert a code patch at the end of the code section (I think). I don't think it cleared the memory to 0, but it did extend the file and moved the data from the next sections back a bit, so you'll probably notice data is duplicated in the area you've extended it. Maybe just clear the extended area to 0s and test to see if it still works first. If it does, start putting the new strings in there.

Once the new strings have been written in, you'll need to find the references to the old strings and update the addresses. This can be a little more tricky with just a hex editor though since the strings will be accessed through virtual addresses rather than file offsets. There is a way to convert between the two, but it might be easier to find the virtual addresses with a debugger. (W32Dasm, OllyDbg, IDA, etc.)

Anyways, find references to the old virtual address of the string and overwrite them with the new virtual address. (You might have to do the edit with the hex editor, but the debugger will help you find the right location). Just be careful if there are lots of references though since that number (the possible virtual address) might have other meaning not related to the string at all, so if you changed them it might cause crashes. In practice though, it's pretty rare that a random value just happens to represent a valid memory address, especially one that points to the start of a string. You might have to look in both the data and code sections for the references to the string. (Try the data section first, just in case you find a table of string pointers. That's usually a fairly sure bet and easy to understand).



Summary:
1) Find lcoation of the old string (VA - virtual address)
2) Find location of the new string (VA)
3) Find references to the old strings VA (Try data section first, then constants in the code section)
4) Replace the old VA with the new VA (probably with a hex editor). You may need to do a search of the bytes in the area you're overwriting to find it since the file offset won't match the VA exactly (but lower order bits are often the same). But hey any decent debugger will give you the code bytes alongside instruction mnemonics if you're doing a code edit.

 

[BlackBox]

The operating system decides where to put the heap in RAM. (It's pretty much impossible to collide with the heap, as the heap that the memory allocation functions in the C runtime is created after the DLL is loaded, during the startup code). The 'process heap' that the OS sets up isn't used at all (the CRT creates its own heap).

When HeapCreate is called, a handle is returned that can be used with HeapAlloc. (it does not allow you to specify the address to use, thus the OS would need to determine that). I would imagine the OS is smart enough to not collide heap allocations with sections mapped into memory.

There's no magic bullet program that can relocate the string for you to allow you to make it longer, you have to add a section yourself, and then update the string references by using a disassembler and hex editor.

As for the string references, they're pretty straightforward in most of the DLL's, being used for Victory Condition text mainly. Even a simple disassembler should be able to find most if not all references.

But yes, you can't just resize the file to fit more of the string. It will throw all the offsets of PE sections as well as any absolute virtual addresses in the sections themselves (the file format is very rigid and you cannot just arbitrarily resize it without serious problems).

edit: Oh, if you can't find an unused area in the DLL itself, there are some tools out there that can add sections (probably easier than resizing a section). Not easy to find tools however.