Jump to content


Blade

Member Since 16 Apr 2003
Offline Last Active Jan 04 2018 12:17 PM

Posts I've Made

In Topic: I want to help you encrypt .big files

20 September 2017 - 09:41 PM

You can't encrypt big files, the game itself would have to be modified as it has no support for the contents being encrypted at all. All you can do is take advantage where community tools do more validation than the game does, such as if finalbig validate that the size of the archive is the same as what the header says it is. You could use a launcher to unencrypt at game launch, but then an alt+tab will defeat that protection.


In Topic: Engine/Game Remake

15 September 2017 - 09:58 AM

It depends on which aspect you want to understand. For the actual dll injection where you make the the original binary load your new dll, there are a couple of ways of doing it. You can patch the original with an extra dll import (I believe OpenRCT2 did this), but then you need to ship a patched original binary. You can make your dll pretend to be a dll already loaded by the original and then forward the function calls it makes to the actual original as well as patching in your own code when the dll loads (I believe GenTool does this). Finally you can have some kind of loader process that starts the target exe, pauses it immediately and then patches in a dll load command in memory before resuming the exe.

 

This final option is what Thyme uses, a small launcher program is also compiled along side the dll to do the startup and force the load of the dll. To get this information I basically did a lot of googling and consolidated information from different sources. Fortunately the work is done now, so in general any contributors to thyme won't need to know this stuff.

 

Regarding the actual reimplementation, mostly what you need to know are C++ to write the implementations and some disassembler and ASM knowledge to examine the original binary to find and study the original functions. If you were to purchase or otherwise acquire a commercial version of IDA it can also generate pseudo C code to make understanding a function easier.

 

Once you know the address in the binary that the original function lives at and you have your reimplemented version, there are functions in thyme that run when the dll loads that you can add to that take the original address and a function pointer and patch the original function to jump straight into your new function at run time so when the original code tries to call say the open file function, it will actually jump into your open file function.

 

There are also special functions that go the other way. Say there is a complex function you haven't figured out yet that gets called everywhere, you could use its address to create a function pointer to it to call it where its needed in your own code. Similarly you can access global variables that are shared between functions in the same way, by making a pointer or reference to them.

 

I would suggest reading some tutorials on writing code in x86 assembly to get an idea of how a program is structured after it has been compiled and probably grab at least the free version of IDA and load the ZH binary. When you load it, it will probably only reliably find winmain, I've done a fair amount of work at my end identifying functions in the game which makes it look a little less daunting and confusing. For BFME games, I recommend you load no-cd versions that have had safedisc stripped out, otherwise disassemblers have a hard time working out what is what due to how the protection worked. Its always the game.dat file that is the actual exe BTW, bfme.exe or whatever its called is just a loader. I suspect the unofficial patches that ship new game.dat files to not required the mini cd images are no-cd exes that have had the safedisc removed, so they will probably be fine.


In Topic: what i learned in game.dat

07 September 2017 - 11:23 AM

I realise this is a big necro to this thread, but I've currently got a project, Thyme (https://github.com/T...blyArmada/Thyme) on the go attempting to reimplementing the game.dat from Zero Hour by modifying it in memory to run new code and replacing the original function by function until the entire game.dat is reimplemented in C++.

 

Although not of immediate use for BFME and later, if anyone has started poking around in the game.dat files since the last post here and mapping what functions do what, I might be able to help speed that along with what I know of the ZH binary to work out what is where. Also, When Thyme is further along towards no longer needing the original game.dat, well mapped BFME binaries would potentially allow back porting of support for the newer games to Thyme as well. Sister projects to reimplement and inject missing generals functions or entirely new functions into BFME and later might also be possible.


In Topic: Engine/Game Remake

07 September 2017 - 08:25 AM

Hey chipgw!

Sounds like a very exciting and much needed undertaking! I wish you the best of luck!
I think there is one other project heading the same way:

https://github.com/feliwir
https://github.com/feliwir/openSage

Have you seen that?

By the way, I have some knowledge of how BFME animation files are structured - please let me know if I can be of any assistance.

 

You should join the #thyme irc channel on freenode, feliwir is often online there and was looking at the animation formats, particularly the newer formats used in BFME2 if you have any information on them. I think currently he's trying to understand and reimplement the apt format used for the UI in BFME and later SAGE games.


In Topic: Engine/Game Remake

06 September 2017 - 10:47 AM

He actually contacted me a couple weeks ago with a question about the .big file format. It sounded like his project was heading in a different direction (integrating with C&C's original code), but I guess that's just different means to the same end. Maybe I should look into it more...

 

 

 

There are different approaches to recreating a game engine and they tend to have slightly different outcomes.

 

Thyme is using a bottom up approach similar to that used successfully by OpenRCT2, using the original binary as a scaffold and basically replace the original classes and functions one at a time with your own until you have a working engine that doesn't depend on the original any more. In terms of how that works, its very similar to how Ares for RA2, TT Scripts for Renegade or GenTool for Zero Hour work, only with the explicit goal of reimplementing everything rather than just what is needed to hook in new features (TT scripts in particular appears to have reimplemented a very large percentage of Renegade making it a useful reference for the W3D parts of SAGE code).

 

The benefits of doing a reimplementation this way is that you get a working game on day 1 and the end result is very close to the original in terms of behaviour. The downside is that you are very constrained in terms of class layouts and function parameters, they must match the layout used in the original exactly. Its also difficult to make a cross platform version as you rely on functionality in the original binary until everything is reimplemented.

 

All the other projects that I've looked at including the ones mentioned so far are using a top down approach, implementing file parsers based on what is currently known about the formats and building an engine that kind of behaves like the original game around that from scratch. Examples of this kind of recreation would be warmux for worms or OpenRA as a reimplementation of the early C&C games.

 

The benefits of this is that its easier to rebrand the project if copyright holders come knocking, just dump any original assets you are using and roll your own and you are your own game since you won't have touched much (if any) of the original code. Its also much more like the experience you would need to write games and engines as a game dev is that is what you aspire towards so some aspiring developers might find that more attractive that essentially following someone elses blueprint. The downside is that you end up with something that really isn't related at all to the original games engine wise, the assets just form a skin on top of your own game. Its also takes much longer to get something playable which makes it harder to keep pushing on with.