MeFisto94

Some findings about big/map file packing in TDU1:

Contrary to TDU2, the map files are no XMB files but instead MAP v4 (v3 is also possible), much like the Tdu1.map outlined by djey here: https://raw.githubusercontent.com/djey47/tduf/master/lib-unlimited/src/main/resources/files/structures/MAP4-map.json

The additional knowledge is that one of the sizes is the compressed size and the other one the uncompressed size (sorry, can't remember the order). Also, I assumed GAP1 to be the offset into the big file (that's how it works in tdu2), but one could look at GAP1 and GAP2 and compare them against the sizes to know more.

My roadblock is now when taking the first chunk out of the BIG file, it has a ".ZC" header, and I also see that in the sourcecode (`%s.zc`), it's compressing files. That's also why the compressed size is < uncompressedSize. One would have to reverse how to decompress those zc files, maybe it's a byproduct of @opentdu

Additional Note: Since those files are for Console, you need to use bigEndian as opposed to littleEndian that you'd use on PC. At least for the map file

1 minute ago, opentdu said:

RenderDoc outputs).

Is there finally a build of renderdoc that supports DX9? Last time I checked there wasn't and that was intentional

3 hours ago, opentdu said:

and ended up switching to Vulkan

So you want to rewrite shaders anyway? Because obviously the best bet would've been starting with DX9 and copying the renderer verbatim to begin with. Even DX11 is already a tad more challenging in subtle ways (e.g. texture adressing changed the pivot, you do have constant groups as optimization).

I know because initially I worked on a d3d9.dll to make TDU2 run using DX11. And a byproduct of that is a disassembler/decompiler for d3d9 assembly. Another interesting use would've been to patch shaders in modding, but as probably all my projects, it's unfinished

One may consider in the decompilation step (that still doesn't support loops etc) to also just output glsl instead of hlsl, though differences there are probably miniscule anyway.

Or was your idea to use SPIR-V with the DX Bytecode? I guess it can't right? So definetely rewriting shaders

I now also created a public channel on our TDUniverse Discord (https://discord.tduniverse.org), link to the channel https://discord.com/channels/930226011071709194/1385708087708614797 to discuss reverse engineering, as suggested.

@opentdu @fvever So it took me a while but I finally made the basic wiki at https://wiki.tduniverse.org (https://github.com/TDUniverse/EdenTduWiki and npm run build to compile it locally).

I thought git is perfectly suited for such a wiki, compared to someone just hosting it, because that way the knowledge can't get lost that easily and we have better collaboration than on a github wiki alone. The file format is kind of markdown with extra features.

Currently all articles are stubs, I'll see what I can contribute over the next few days.

On 6/18/2025 at 3:23 AM, opentdu said:

As long as your phone supports Vulkan, yes.

There you'd probably have more success with WebGL2/openGL ES 3.0 though probably, for old phones and because Vulkan may otherwise tempt you to write a modern rendering backend  

It's interesting anyway because due to both games having a "shared" xbox and pc renderer, you can see the xbox command list architecture, e.g. in tdu2 there's just a list where they append I think around 150 integers and sometimes some pointers and then number XY is means "bind index buffer", so you can probably abstract quite a bit, at least for those old APIs.

Hey @opentdu and @fvever!

It seems we're 3 persons trying to achieve something similar or at least having the same requirements!
That means if we're collaborating/open sourcing our findings, everyone could profit.

To summarize:

@fvever is working on getting TDU2 to run on PSP, right?

@opentdu Your motivation is outlined in this post, + it could help building Andraste Mods, I am just a bit confused by the mix of ground truth decompilation and a vulkan rendering instead of the DX9 first.

Then there's "us" (Me and the TDUniverse Team): We have a bare bones TDU1.5, which kind-of shares openTDU's goals, but not the way. The idea is to reimplement the game but without relying on decompilation and instead develop things from scratch in a modern way (and language, Rust). By that, I take the freedom to also implement things differently (maybe non p2p networking?). The name comes from the fact that it tries to bridge the gap between TDU1 and 2, too, reading both asset formats and databases but pulling the physics from TDU1 etc.

Besides that we've been working in tooling since a while, we have the non-public "Modding Studio" that converts a few file formats (into gltf, e.g., for a blender pipeline) and database editing capabilities (adding cars). It doesn't support world editing, though and especially not the havok collision shapes, e.g.

My suggestion would be that we at least work on a wiki documenting the file formats together, I guess we could already achieve 80% completion with our combined knowledge.

TDUniverse also has "TDUFileFormats", a C# reference implementation for those files, but I guess everyone of us is working in a different language anyway.

What do you think in general? WE can also provide a discord channel at TDUniverse and I guess Turboduck would do the same.

Hey 32qYVQdH!

You've come to the right place. I guess Turboduck is the only remaining big TDU community and is the home of a lot top tier modders.

On 6/19/2024 at 9:31 PM, 32qYVQdH said:

and then Pix says it's running out of memory (it's not, but I guess this is a 32bit program also, maybe it hit 4GB)

I think I had the same problem and you indeed need the https://ntcore.com/4gb-patch/. You can read up on the backgrounds but the TLDR is that otherwise the game can only allocate 1.5 GiB of virtual address space. And PiX has an overhead, while TDU certainly had been trimmed to exactly ride the 1.5GiB border. What you can also do is inspect the capture using the 64bit PiX application and/or trying to 4GB patch the 32bit one, I think that was also a problem.

FWIW TDU contains the shaders as blobs in the application, whereas TDU2 has dedicated .sob files. Furthermore static analysis will help you understand tdu1's rendering whereas tdu2 is using some xbox derived command list abstraction where it's building a linked list of "commands" that are then implemented by some backend that polls the list.

On 6/19/2024 at 9:31 PM, 32qYVQdH said:

also the place where the exception happens isn't code and the last value in the stack is the address for IsDebuggerPresent,

Probably not the case here, but remember that asserts kind of compile to:

if (IsDebuggerPresent()) {
  __asm int 3; // maybe there's a WinAPI function for that too
}

Actually, that's probably a give away for you of where anti debug resides anyway, so you can get rid of it.

On 6/19/2024 at 9:31 PM, 32qYVQdH said:

Does anyone knows an easy way to bypass any of that ?

Cracks. Since the game is abandonware, there's probably no legit (i.e. requiring activation) version floating around anymore anyway, and depending on the crack (maybe there's multiple "vendors") they may have removed the DRM protection more or less.

On 6/19/2024 at 9:31 PM, 32qYVQdH said:

from lazy anti-debug only calling IsDebuggerPresent once, I don't want to waste hours unnecessarily and I'm lazy

Could just hook it to "return false", but yeah there's a lot more Anti Debug techniques.

Besides that, do a lot of static analysis and maybe try to fiddle with some less mainstream functions. Generally, DRM will only try to monitor protection worthy functions, as everything else will become too expensive.

On 12/3/2022 at 12:03 PM, BEight said:

Hey Mefisto! Hope you are well.

I'm trying to get your program to work for TDU1 and i'm getting errors.

Here's what the terminal looks like:

Its something to do with the easyhook.dll. I'm not sure.

I used both the Project paradise version of TDU and the orginal: Same errors.

 

 

This has been solved by BEight after trying a different folder / placing Andraste next to it.

I've updated the Launcher to be more verbose about such errors, it may also be that specific special characters in paths still cause issues, but so far we haven't had others with that kind of error.

If someone else has that error: Check your game path. Is it very long? Does it have spaces? Other special characters? If so, try it from a very simple location like "C:\tdu" and report it back to us.

Also to address the malware concerns: Andraste is a modding framework, so it invades other processes to change their behavior. This may very well trip antivirus heuristics, and since we're neither signed by a costly certificate (microsoft approved so to say), nor is the exe widespread, Anti Virus may yield a warning.

If you have a technical background, feel free to inspect the DLLs (they are regular .net dlls that are not obfuscated), or even read along on https://github.com/AndrasteFramework.

Note: not all parts are public on github yet.