Breaking SecuROM 7 – A Dissection(lostfilearchives.github.io)
lostfilearchives.github.io
Breaking SecuROM 7 – A Dissection
https://lostfilearchives.github.io/08/28/Dissection/
31 comments
The cracking scene seems to be split between two extremes nowadays, on one end most new games are just using the basic Steam or Epic DRM, which are trivially defeated with open source wrappers so making a pirate release is mostly just boring acquisition and packaging work that basically anyone can do. The other extreme is Denuvo protected games which are so tedious to crack that there's almost no overlap between people with the skills to do it and those with the time and patience to do it.
And seemingly the few that are willing are somewhat insane. I know it takes a special type but wowzers.
Shout-out to that one guy who has figured out Denuvo but only appears once a year to crack the latest Football Manager game, refuses to elaborate, and leaves until the next Football Manager game comes out. They know what they like, and it's Football Manager, exclusively.
If you're referring to EMPRESS, I still don't know if they are just being edgy or truly insane.
That… is exactly who I mean.
> But when I see what the kids are up to in the multiplayer cheating forums
The EFI-based cheats, or even the DMA PCI-e hardware streaming memory data out to a second computer are fascinating, to get around ring-0 anticheats like Vanguard
The EFI-based cheats, or even the DMA PCI-e hardware streaming memory data out to a second computer are fascinating, to get around ring-0 anticheats like Vanguard
Can you elaborate? I know there’s hypervisor-detection, but surely any kernel-debugger (kdb + USB debug cable) is enough to work-around anything in Ring 0? Maybe even Rowhammer too?
…which makes me wonder if anything’s running in SME mode instead thesedays.
…which makes me wonder if anything’s running in SME mode instead thesedays.
> kernel-debugger (kdb + USB debug cable) is enough to work-around anything in Ring 0?
At least for Vanguard specifically, nope you'll get pinged if you try that naively; mainly because Vanguard looks for funky USB devices (among other things)
Now the way to approach it is to spoof USB hardware IDs and data streams, so you can then use approaches like what you've described, and some even use that to inject HID/mouse movement back into the host PC.
Basically allows cheats with nothing more than a micro-controller and a second PC, but it is still more detectable/cat-and-mouse than PCIe DMA devices + second PCs (and video muxing/overlay devices to put the ESP/whatever over the existing "clean" host PC's output)
Also if you're running Windows 11, Vanguard requires TPM 2.0 + Secure Boot which makes some things a lot more painful
At least for Vanguard specifically, nope you'll get pinged if you try that naively; mainly because Vanguard looks for funky USB devices (among other things)
Now the way to approach it is to spoof USB hardware IDs and data streams, so you can then use approaches like what you've described, and some even use that to inject HID/mouse movement back into the host PC.
Basically allows cheats with nothing more than a micro-controller and a second PC, but it is still more detectable/cat-and-mouse than PCIe DMA devices + second PCs (and video muxing/overlay devices to put the ESP/whatever over the existing "clean" host PC's output)
Also if you're running Windows 11, Vanguard requires TPM 2.0 + Secure Boot which makes some things a lot more painful
I think the have a pci-e card on the computer playing the game. The card sends hardware level debugging information (memory dma) to another computer.
This second computer is connected to the first computer by usb, to spoof a HID (mouse, keyboard, controller etc). It reads the data from the pci card on the first computer and sends inputs via usb.
Done right, and it can’t be detected via software. Behaviour analysis still works for aim hacks.
Now days I think there are even devices that will tap the hdmi stream and use the video data to calculate inputs and the send the input via usb/hid/controller. This works on console I think!
This second computer is connected to the first computer by usb, to spoof a HID (mouse, keyboard, controller etc). It reads the data from the pci card on the first computer and sends inputs via usb.
Done right, and it can’t be detected via software. Behaviour analysis still works for aim hacks.
Now days I think there are even devices that will tap the hdmi stream and use the video data to calculate inputs and the send the input via usb/hid/controller. This works on console I think!
If you are going down a DRM search trip, both Widevine key dumping and DMCA compliant HDMI / HDCP downgrade hardware are quite interesting topics.
Are there any public breakdowns of techniques used by Denuvo? That's still proving to be a PITA for cracking groups to deal with.
Bulgarian cracker Voksi, also alleged to be the man behind Empress, made a video for V4 https://youtu.be/suABtb8_2Zk
> From what I can see the flag at [EAX+4] is somehow switched on when debugged.
I wonder if a look into the leaked Windows kernel source code files (I _think_ the most current dump is still old Win2k?) could help out to decipher what these two RESERVED flags are used for?
PEB_LDR_DATA still has them named as RESERVED1/2 [1].
[1] https://learn.microsoft.com/de-de/windows/win32/api/winternl...
I wonder if a look into the leaked Windows kernel source code files (I _think_ the most current dump is still old Win2k?) could help out to decipher what these two RESERVED flags are used for?
PEB_LDR_DATA still has them named as RESERVED1/2 [1].
[1] https://learn.microsoft.com/de-de/windows/win32/api/winternl...
It is a flag that says whether the loader data is initialized or not.
The layout of PEB_LDR_DATA “leaked” long time ago in public PDBs.
More context: It has nothing to do with debugging. However, if you attach to the process early enough, you might see the flag as 0 and eventually it would switch to 1. That is probably what threw him off.
The layout of PEB_LDR_DATA “leaked” long time ago in public PDBs.
More context: It has nothing to do with debugging. However, if you attach to the process early enough, you might see the flag as 0 and eventually it would switch to 1. That is probably what threw him off.
"you might see the flag as 0 and eventually it would switch to 1"
Sorry, noob question: Were there easy avaiable tools (in the debugger), to monitor a variable like this and have the debugger stop exactly when it was going to change, so you could see which thread and function did it and why?
Sorry, noob question: Were there easy avaiable tools (in the debugger), to monitor a variable like this and have the debugger stop exactly when it was going to change, so you could see which thread and function did it and why?
Yes: many debuggers support setting watchpoints[1] that break on writes to a particular memory location.
Depending on the platform and the debugger, these can be implemented using CPU architecture-specific debugging features, or in software, by single-step program execution and checking watched addresses for changes after each step.
[1] https://sourceware.org/gdb/current/onlinedocs/gdb.html/Set-W...
Depending on the platform and the debugger, these can be implemented using CPU architecture-specific debugging features, or in software, by single-step program execution and checking watched addresses for changes after each step.
[1] https://sourceware.org/gdb/current/onlinedocs/gdb.html/Set-W...
Yes, x86 kernel-mode debuggers support hardware breakpoints that cause the attached debugger (running on a separate machine, of course) to break not just when a specific address/instruction is executed, but also whenever some address is written to (and also possibly read-from too, I think?)
It is a nice hollow shell of a page. Some links are already dead. Mentions of forums lead to nowhere. Tools were discontinued on 2014.
Funny how things move, and some parts become history and myths.
web.archive.org is extremely useful for digging back into history.
And, fun fact, DDG has a bang so one can just command-l, command-c, type "!wayback ", command-v and it'll redirect to https://web.archive.org/web/*/http://forums.accessroot.com/i... but in this case the 4 captures are all captures of the forum's 404 page, and thus were not taken early enough to actually preserve the history
I didn't check any of the rest of the links, figuring they were in the same boat of "too obscure to have been preserved"
I didn't check any of the rest of the links, figuring they were in the same boat of "too obscure to have been preserved"
Ah yes, right up my alley. Sort of. I spent many months reverse engineering a SC8 executable for fun, yep purely for fun. 10 years ago now.
I have more experience with SecuROM 8. Did you guys know there is a hidden flag that is parsed on executable running that initializes a separate application which generates a file you can send to the authors of SecuROM that holds the version of SecuROM and quite a lot of other details?
Opaque predicates, VM, simple code integrity checks(int 3), xchg used as control flow obfuscation? It was all there. It took me a while to get the program running under a debugger. Once I did there were a bunch of threads running which would detect tampering or pausing of the threads and kill the process. After suspending those I could do whatever I want.
The DRM used a lot of control flow methods, especially hardware breakpoints and UD2 instruction.
At the time of Unicorn engine's popularity I made a custom plugin to emulate the zlib code embedded inside to search for hidden API calls, unfortunately due to the way QEMU emitted some instructions for the helpers some instructon hooks were called a few times more e.g those with a rep prefix severely skewing instruction counting.
Anyway, VM hunting was difficult. The VM had quite a few single-threaded VM contexts so it could run a lot of programs. From then on it was a matter of reverse engineering the opcodes. at the time I used Olly to trace and log the instruction handlers and opcodes and then using Notepad++ magic I could clean it up from the control flow in a single coherent picture.
Honestly I've forgotten most of it now.
But a few years ago I did write my own Control flow graph generator in Java just to find the 20 or 30 thousand code integrity checks and trace them statically and then was going to use it on the VM.
The most unusual thing is, I often communicated with one of the devs of SecuROM on IRC, of course I did not ask him anything nor did he reveal anything, that is of course illegal. I remember asking him about the little "Cut my life into pieces" tidbit he left just after VMEnter.
Needless to say it is thanks to SecuROM that I gained an interest in RE. Yes I was a novice and dived deep down into a commercial DRM. Thanks to it I learned a lot and is helping me even today, yep as I type this I am working on a SH2 architecture firmware.
But back in the day SecuROM inspired me to write this little ugly thing https://github.com/farmdve/TextVM
I have more experience with SecuROM 8. Did you guys know there is a hidden flag that is parsed on executable running that initializes a separate application which generates a file you can send to the authors of SecuROM that holds the version of SecuROM and quite a lot of other details?
Opaque predicates, VM, simple code integrity checks(int 3), xchg used as control flow obfuscation? It was all there. It took me a while to get the program running under a debugger. Once I did there were a bunch of threads running which would detect tampering or pausing of the threads and kill the process. After suspending those I could do whatever I want.
The DRM used a lot of control flow methods, especially hardware breakpoints and UD2 instruction.
At the time of Unicorn engine's popularity I made a custom plugin to emulate the zlib code embedded inside to search for hidden API calls, unfortunately due to the way QEMU emitted some instructions for the helpers some instructon hooks were called a few times more e.g those with a rep prefix severely skewing instruction counting.
Anyway, VM hunting was difficult. The VM had quite a few single-threaded VM contexts so it could run a lot of programs. From then on it was a matter of reverse engineering the opcodes. at the time I used Olly to trace and log the instruction handlers and opcodes and then using Notepad++ magic I could clean it up from the control flow in a single coherent picture.
Honestly I've forgotten most of it now.
But a few years ago I did write my own Control flow graph generator in Java just to find the 20 or 30 thousand code integrity checks and trace them statically and then was going to use it on the VM.
The most unusual thing is, I often communicated with one of the devs of SecuROM on IRC, of course I did not ask him anything nor did he reveal anything, that is of course illegal. I remember asking him about the little "Cut my life into pieces" tidbit he left just after VMEnter.
Needless to say it is thanks to SecuROM that I gained an interest in RE. Yes I was a novice and dived deep down into a commercial DRM. Thanks to it I learned a lot and is helping me even today, yep as I type this I am working on a SH2 architecture firmware.
But back in the day SecuROM inspired me to write this little ugly thing https://github.com/farmdve/TextVM
Thanks for sharing. I'm not a student of the RE art so just curious about what you just said -- by saying VM did you mean the whole SC8 is running some core code inside a VM (of course within the same executable)? I assume that the intermediate code is definitely not public so people like you have to RE all those stuffs too?
It's called an Obfuscation Virtual Machine running custom opcodes. These opcodes were decoded in a special way and a single x86 instruction like
mov imm, reg
would get translated in 20-30 instructions most of them junk, but they were not laid out contiguously, you would execute one junk instruction and then return to the dispatcher to get to the next one, if I remember correctly. This made the VM and tracing dog slow. Additionally it used a small 256 or 1024 byte scratch buffer for the virtual registers that held data. I've forgotten now how it was exactly.
The entire VM used only jmp instructions which was how you would spot it.
mov imm, reg
would get translated in 20-30 instructions most of them junk, but they were not laid out contiguously, you would execute one junk instruction and then return to the dispatcher to get to the next one, if I remember correctly. This made the VM and tracing dog slow. Additionally it used a small 256 or 1024 byte scratch buffer for the virtual registers that held data. I've forgotten now how it was exactly.
The entire VM used only jmp instructions which was how you would spot it.
Thanks. I got the idea. Looks like they really wanted to slow you guys down :D
I wonder if modern AI could solve that for you. "Oh look, that huge block essentially just set some variable to 127".
I wonder if modern AI could solve that for you. "Oh look, that huge block essentially just set some variable to 127".
There was a strange situation when SecuROM came onto the scene: The first patch for most games had no SecuROM at all and so it was just patching the usual CD checks.
> As you can see exe is 97Mb, biohazard exe without securom is Just 6Mb, that’s how protections hurt customers, not my fault then.
A 93.8% reduction... That's brutal.
A 93.8% reduction... That's brutal.
Also iirc after this tutorial deroko wrote another one one breaking the Securom VM obfuscation. It was great work, one of the first public tutorials at the time on breaking such obfuscation. I wonder if its also been archived.
Finally, it should be noted that Securom is a predecessor to Denuvo. I remember debugging early versions of Denuvo and being struck by how similar they are. I wonder how much of the code and techniques are in common between the two, especially now in 2024.
The old reversing scene has changed. I guess everyone grew up and got families and jobs. But when I see what the kids are up to in the multiplayer cheating forums, I see the spirit is still alive and well. Cheers and happy debugging.