Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

shimano32.sys/shimano64.sys #163

Open
Wack0 opened this issue Dec 6, 2023 · 0 comments
Open

shimano32.sys/shimano64.sys #163

Wack0 opened this issue Dec 6, 2023 · 0 comments

Comments

@Wack0
Copy link

Wack0 commented Dec 6, 2023

samples:
https://www.virustotal.com/gui/file/e8b1a0ddc7a4404eb3c46217e07b5ed91723f44464a6ef589634aeb4fb8f5666
https://www.virustotal.com/gui/file/e3a1f0d967335c8a080a5b1e7e3a06a61f6cea39739cda3ebab11d2908713d80

Seems to be related to capcom.sys (device name is obfuscated, and is Htsysm4EFB)

Opus info says the responsible vendor is "株式会社DNPハイパーテック" so is probably related to HyperTech DNP CrackProof DRM/PE protector/anti-cheat/anti-tamper solution.

Malicious functionality is a few IOCTLs that give 32-bit read, 32-bit OR, 32-bit bitmask unset (&= ~Value) on an arbitrary (checked to be less than 0x1000) offset of current process EPROCESS object from usermode.

The functionality is gated on also providing 32-bit crypted value (custom algo), of which plaintext is the sum of current process PID and a value initialised to KUSER_SHARED_DATA::SystemTime (another IOCTL passes this value to usermode with no additional checks).

Escalating to protected process is an obvious use case. Probably other privesc is also possible if the driver is already running (not sure if attacker could craft a token object in usermode address space for example).

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

1 participant