Outpost Universe Forums
Projects & Development => Outpost 2 Programming & Development => Topic started by: BlackBox on August 29, 2003, 08:16:10 AM
-
I still cannot figure out the mystery of the DLLs!!!!!
Look at the image below:
-
Gasp! You don't have XP! Maybe we could raise up money, go to Dynamix, and pay to open the safe, to give us their mission editor.
-
They destroyed everything in the vault, according to Dan.
-
WAAAAAAAAAAH! (CRYING!) (SOBING!) WAAAAAAAH! We will, just have to, wait, for someone to, make a, mission editor. WAAAAAAAAAAAAAAAAH!
-
(senses a large load of work coming)
How come I am the only one that knows how to do this?
-
It was a Sierra conspiracy. (Yes, an admin just cryed [Starts crying again])
-
No, it can't be.
Now it's owned by some huge company called Vivendi.
-
Then it is a Vivendi conspiracy. Blow up Vivendi Headquarters!
-
I have some assembly skills, but not enough to help you. And I don't have any idea of how op2 works. Furthermore I don't have time...
I'd really like to help you, but...
-
if you blow the place up, than any scrap of op2 information would be destroyd
-
Any other programmers out there that could lend op2hacker a hand?
-
These are the requirements if you want to help me (if you don't know the stuff that I'm about to tell you, and can't/don't want to learn, sorry but there will be no way to help)
1) You must know how to reverse engineer software. (This includes ASM / processor level knowledge (like registers, stack, etc), using disassembler / debugger / hex editors, and knowledge of the Win32 platform / API.)
If you don't know how to reverse engineer, but would like to learn, PM me and I'll put together a guide. (It is preferred that you have some experience programming in Windows with a common language, like C++)
2) If you have knowledge of OP2, like file formats, OP2's internals, etc. (A good example of someone that doesn't have a lot of Windows programming knowledge, but could help because of his in depth knowledge, is someone like Kevin Ar18.)
3) Someone that is REALLY willing to learn technical stuff (like #1 above). If you are them, you should have a LOT of patience, and be able to understand complicated stuff (like technical aspects of a computer). If you (still) apply, PM me and I'll give you information.
Well, there's my "requirements". Of course I'm sure you can help out in other ways OP2-wise if you don't want to / can't meet the description(s) above.
-
#3 applies to me :D
-
I'll help. I just don't know how to utilize the DLLs into C Code...
-
:lol: Hey OP2HACKER! I think I found out the format for the map trigger files. I'll update you soon.
-
i had the same problem, exact same dll and so on, my problem was the winprf32 virus, at least, that what i think it was called....
50 us dollars for norton
-
It's not a virus, it has to do with the coding in the program and DLL.
The structure of the dll's for missions are "different", it's like they've been linked with some custom lib that sierra/dynamix made, instead of the usual MSVC lib.
I have yet to find anything more that will let custom dll's work in op2, as of what I have so far.
-
hey, i would like to help, i have no clue how to program though lol.
-
op2hacker. I think I know the DLL's format. I'll tell you more when I figure out more.
(I made OP2 Sandbox mode.)
BTW, does anyone have mapedit.
-
hmm... what do you have as far as information about them?
Well, there isn't really a format.... other than it's a Win32 PE file..... but any information about the sections in the files is good. (They must have linked it with some proprietary run time, vs linking with the MSVC++ libs)
Because for some reason a "home made" DLL causes an access violation when Op2 tries to process it.
-
Well, I'm working out how the Units are stored, the triggers, and some other things. It seems that some of it is an executable (DLL), but alot is a data file.
-
Yeah, I am aware of that..... it is a DLL (therefore it's an executable)
All of the stuff that initializes triggers, etc is in the InitProc function (all it is is calls to classes, and functions that return classes)
What really has to be worked out, is the DllMain function.... That's the confusing part.
-
I don't know how to compile my own dlls... (I have VC++ 6) Well, I don't know how to tell which functions I need to compile it... Can you help?
-
OK... Here is the MSVC++ 6 project I started working on.
http://312productions.xfir.net/etc/sdk_alpha.zip (http://312productions.xfir.net/etc/sdk_alpha.zip) (43 KB)
Just extract it and open the workspace....
Note: it doesn't work in Op2 yet!
-
In case anyone is interested, I modified a DLL (CES1.dll) to basically cut out the DllMain function (first command changed to a ret) and the level still ran. Although, the computer's base was gone so I guess I cut out something semi important.
As for why dll's I compiled with Hacker's import library crash on me, I can only assume that's something to do with GetSaveRegions and InitProc which are the only other functions that run before the crash.
Is knowing this any use to anyone?
-
No, those functions aren't even called yet... In fact, the CRT startup code has yet to call DllMain before the exception occurs.
It's in the CRT startup somewhere, I think dynamix made their own version of the CRT.....
-
Ok, I just checked the dll I compiled again.
I put a call to MessageBox in DllMain and GetSaveRegions and they both showed up before the crash. Although, InitProc didn't run before it crashed.
Or am I still way off base?
-
I managed to compile a dll and, using a hack method explained below, get *some* code to run without crashing the game. Unfortunately, the only thing I can really do without crashing the game is display a message box to show me that my code ran. As soon as I try to call any of the functions from outpost2.exe it crashes.
I'm really starting to think it's something not in the code section that causes the crash. I gutted one of the regular DLLs and it still works. I started off by removing the DLL entry point completely (i.e. setting the entry point pointer to null) and overwriting the first few bytes of all the important functions (those functions op2hacker had in his .def file) with simple RETs (and setting EAX with appropriate return values where needed). The DLL still runs perfectly. Mind you, it makes for a very boring game since all you can do is stare at the map and scroll around.
I even gutted the Export table and reduced it to only the important functions. (Say, anyone know a better way to do this than using a hex editor? :( ) It was at this point, that I decided to modify the Export Table entry for InitProc and forward it to an InitProc in a DLL that I compiled. The code ran and the game didn't crash. I got a message box to display fine but any calls to the outpost2.exe functions still cause a crash. Perhaps I'm overlooking something with this export forwarding idea.
Anyways, I plan to NOP the entire code section (except for dummy function area) of the DLL just to make sure I'm not missing something hidden. I also plan to do the same sort of thing to the data section except for the needed exported data. My guess, is that it will still run fine and I won't actually know any more. <_<
-
Good work Hooman.
I sorta figured it had to do with the startup code...... so it doesn't call DllMain or the CRT startup at all?
Another thing you should take into consideration is that the OP2 Dll's have an extra section (an idata section) where the IAT and INT are stored, instead of VC++'s normal way of merging this stuff into the rdata. (And there is no linker option to force it to create an idata.... other than maybe editing the obj's manually..)
Hmm, now I'm talking to Cynex on IRC and he thinks the problem may lie in that since I made a lib, you have to keep in mind that it doesnt directly call into the functions, it uses a jumptable that Win32 patches before the module's loaded.