MeFisto94

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.