Author Topic: What do we mean by Forced Exports?  (Read 378 times)

Offline Vagabond

  • Sr. Member
  • ****
  • Posts: 284
What do we mean by Forced Exports?
« on: March 29, 2016, 08:06:43 AM »
Would someone mind a quick explanation or pointing me to some basic information on what we mean by forced export in the Outpost 2 SDK? A quick forum search didn't seem to turn anything up, although it might be explained in the offline media wiki.

My vague understanding would be that it is something like using .net reflection to learn the content of DLL files, but this could be completely off base...

Offline Hooman

  • Administrator
  • Hero Member
  • *****
  • Posts: 3709
Re: What do we mean by Forced Exports?
« Reply #1 on: March 31, 2016, 04:32:56 AM »
The name is terrible, I know. The project should be renamed and overhauled.

The ForcedExports project is a complement to the Outpost2DLL and Outpost2App projects. The Outpost2DLL project contains the level programming related exports from Outpost2.exe. There is also an Outpost2App project for the other exports, that would be useful for shell extensions or other modifications. Those two projects (Outpost2DLL and Outpost2App) should contain all the exports that Outpost2.exe provides (mostly class member functions, free standing functions, a bit of extra class info, and some data). There are however many other functions internal to Outpost2.exe that are not exported. The ForcedExports project was meant to give access to those internal functions. Come to think of it, Outpost2Internal would have been a much more sensible name for the project.

Basically the project is a set of header files describing the classes and internal memory structures of the game, which aren't normally exported, along with a lot of know memory addresses, typed according to the internal structures they point to. It provides access to the internal game classes and data much as if they'd been exported like the other functions. This is meant as a lightweight project, in that it only describes what already exists in Outpost2.exe, and doesn't add on, extend, or wrap any of it.

One of the flaws with the project is it isn't designed to handle Outpost2.exe being relocated. Hence why I think it needs to be overhauled. It should be updated to handle relocations, which will require the pointers to be accessed through an extra layer of indirection, along with a method to relocate pointers into Outpost2.exe.

This relocation flaw is noticed if you try to load a level DLL in OllyDbg. To load a DLL, OllyDbg will first try to load a dummy exe to create the program address space, and then load the DLL into it. As the level DLLs contain references to Outpost2.exe, they will cause Outpost2.exe to be brought in to memory, but the dummy exe already sits at its preferred base address, causing Outpost2.exe to be relocated.

Another separate flaw, is some of the patches to Outpost2.exe didn't take the relocation table into account, and so it's broken anyway. Trying to relocate Outpost2.exe can already cause problems.
« Last Edit: March 31, 2016, 04:41:14 AM by Hooman »