- Status
- Offline
- Joined
- Mar 3, 2026
- Messages
- 179
- Reaction score
- 7
Found a solid vulnerability in the AMD amdssg64.sys driver that is worth looking into if you are messing around with kernel-mode operations. It exposes some unsafe IOCTLs, which essentially lets your user-mode processes handle file operations directly through the kernel (Ring 0).
Tech-wise, this is pretty clean, but keep in mind that the driver is picky. It won't play nice unless you have the correct device mapped. I managed to bypass this by patching the driver and spoofing the AMD SSG device node. I dropped the full reproduction steps and the patcher on the repo below.
Technical Details:
Has anyone else here tried weaponizing this for persistent file IO without triggering standard OS hooks? I am curious if this holds up against more modern kernel monitors or if it gets flagged as soon as the driver path is modified. Let me know if you run into any issues during the patching phase.
Tech-wise, this is pretty clean, but keep in mind that the driver is picky. It won't play nice unless you have the correct device mapped. I managed to bypass this by patching the driver and spoofing the AMD SSG device node. I dropped the full reproduction steps and the patcher on the repo below.
Technical Details:
- Mechanism: Unsafe IOCTL implementation within amdssg64.sys.
- Capability: Kernel-level file read/write operations from Ring 3.
- Requirements: You must patch the driver and spoof the hardware node for it to initialize correctly in a dev environment.
1. Ensure your environment is isolated for driver testing.
2. Patch the entry points identified in the provided src to bypass the device check.
3. Spoof the AMD SSG device node to trick the driver into loading.
4. Execute your IOCTL commands to initiate R/W.
2. Patch the entry points identified in the provided src to bypass the device check.
3. Spoof the AMD SSG device node to trick the driver into loading.
4. Execute your IOCTL commands to initiate R/W.
You cant view this link please login.
Has anyone else here tried weaponizing this for persistent file IO without triggering standard OS hooks? I am curious if this holds up against more modern kernel monitors or if it gets flagged as soon as the driver path is modified. Let me know if you run into any issues during the patching phase.