[Protection Enhancement] TAGES driver version when baked into dvm.dll

[Morlit55]

BoS currently doesn't check for the driver when its embedded within a game executable or DLL. One can often find the driver version though by looking inside dvm.dll with a HEX editor. Example below from http://redump.org/disc/112733/.

[mnadareski]

Odd, I checked the code around this and if the file description is "TagesSetup" it should be pulling the version number starting with the file version that you have highlighted there.

When you scan the file, which happens?

• Tages driver setup is detected but no version is included
• Tages driver setup is detected bu wrong version is included
• Tages driver setup is not detected at all

Alternatively, I'm not understanding the concern and this is actually an embedded DLL resource either in the resources or overlay that's not being read at all. If this one is the case, then that's more of an issue with extraction than it is parsing.

[Morlit55]

Option three. It fails to find any driver at all. The only way for BoS to find it in these games is if you scan the temp file generated when you try and launch the game without the driver installed and which contains it.

(btw, no idea where its getting Denuvo from all of a sudden. Wasn't there when i scanned before. )

protection-2024-12-30_083554.2449.txt

protection-2024-12-30_083757.7834.txt

Both files can be found at the drive below.

https://drive.google.com/drive/folders/1GkIfi4gqpG2xN8i7qvFmqklLF9xhdUFZ?usp=drive_link

[mnadareski]

Taking a look at the DLL using InfoTool, I'm not seeing any of the classic signs of embedded data (such as an obvious resource data entry). The overlay data is likely where it lives, but it starts with a byte pattern that I'm not familiar with: AD DE FE CA, possibly supposed to be read as a UInt32 as 0xCAFEDEAD.

The overlay data itself takes up 33,844,252 bytes, which is a pretty significant chunk of the file size and explains the lack of resource data. Most references to 0xCAFEDEAD online are that it's used as a generic error value in things like Radeon GPUs, so it's hard to find information about what this block is or how it could be parsed.

[mnadareski]

For my own use later, here's what appears to be the "header" section of that data:

Hex View  00 01 02 03 04 05 06 07  08 09 0A 0B 0C 0D 0E 0F
 
00031750              AD DE FE CA  0C C0 02 10 00 00 00 00      ............
00031760  20 BE 02 10 00 00 00 00  B0 BE 02 10 00 00 00 00   ...............
00031770  00 C0 02 10 00 00 00 00  F0 BF 02 10 00 00 00 00  ................
00031780  E4 BF 02 10 00 00 00 00  D4 BF 02 10 00 00 00 00  ................
00031790  C8 BF 02 10 00 00 00 00  C0 BF 02 10 00 00 00 00  ................
000317A0  B0 BF 02 10 00 00 00 00  A4 BF 02 10 00 00 00 00  ................
000317B0  94 BF 02 10 00 00 00 00  84 BF 02 10 00 00 00 00  ................
000317C0  78 BF 02 10 00 00 00 00  6C BF 02 10 00 00 00 00  x.......l.......
000317D0  60 BF 02 10 00 00 00 00  54 BF 02 10 00 00 00 00  `.......T.......
000317E0  48 BF 02 10 00 00 00 00  38 BF 02 10 00 00 00 00  H.......8.......

[mnadareski]

For anyone following this issue: This can and will not be fixed in any reasonable time. The original issue of things not being detected is almost moot because it was found that the data is there and is extracted properly on run... just within a container format that has no public documentation.