mirror of
https://github.com/SabreTools/BinaryObjectScanner.git
synced 2026-02-04 05:35:49 +00:00
[Protection Enhancement] TAGES driver version when baked into dvm.dll #190
Reference in New Issue
Block a user
Delete Branch "%!s()"
Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?
Originally created by @Morlit55 on GitHub (Dec 29, 2024).
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 commented on GitHub (Dec 30, 2024):
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?
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 commented on GitHub (Dec 30, 2024):
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 commented on GitHub (Dec 30, 2024):
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 as0xCAFEDEAD.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
0xCAFEDEADonline 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 commented on GitHub (Dec 30, 2024):
For my own use later, here's what appears to be the "header" section of that data:
@mnadareski commented on GitHub (Dec 30, 2024):
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.