[Discussion] SMM / Ring -2 memory access and what public references actually prove

[DMA_hacker]

Author note: this write-up may still be incomplete or imperfect, especially around firmware-specific details. If anyone here has deeper SMM / UEFI experience, corrections, extra references and technical discussion are welcome.

Abstract

SMM / Ring -2 is often discussed in a very sloppy way. Some people reduce it to "just DMA", while others treat the Ring -2 label as proof of invisibility. Both positions miss the real technical question: where does the memory operation actually happen, and what evidence supports that path?

This post uses Hermes as the main technical reference because it is one of the most useful public examples for explaining SMM-side memory access. Other references, such as SmmMem, ekknod/smm and Plouton, are used only as supporting context.

This is not a setup guide, not a firmware modification guide, and not a claim that any private implementation is safe.

1. What SMM changes

System Management Mode is a CPU execution mode entered through a System Management Interrupt. Once the CPU enters SMM, execution moves into firmware-controlled code stored in SMRAM. The normal OS does not schedule this code like a process, and a Windows kernel driver is not required for the SMM code itself to run.

That changes the trust and visibility model.

A normal usermode tool is judged by process behavior, handles, APIs, loaded modules, overlays and userland telemetry.

A kernel driver is judged by driver load state, kernel callbacks, kernel objects, signatures, integrity checks and kernel telemetry.

Classic PCIe DMA is judged by the external device, PCIe behavior, IOMMU / DMA-remapping policy and the DMA read/write path.

An SMM design shifts the relevant surface toward firmware: SMI entry, SMRAM-resident code, SMM handlers, firmware image integrity, board-specific behavior and whether the modified firmware can be compared with a clean vendor image.

This is why SMM should be treated as its own category. It is not automatically "just DMA", and it is not automatically invisible.

2. Minimal architecture model

At a high level, an SMM memory-access design can be described like this:

request source
  -> trigger or command channel
  -> SMI / SMM entry
  -> SMM handler
  -> memory operation from firmware context
  -> result returned through the chosen channel

The request source can be a usermode component, an external controller, a second PC or another transport path. The important distinction is that the transport is not necessarily the memory primitive.

If the memory primitive is performed by SMM-side code, then the design is categorically different from classic PCIe DMA. However, if the transport uses normal hardware, that transport may still have its own artifacts and normal device behavior. "Not classic DMA" is not the same as "no observable surface".

3. Main technical reference: Hermes

Hermes is the most valuable public reference here because it shows the core idea clearly: a UEFI/SMM module provides the privileged memory-access side, while a normal usermode client only submits requests.

The important part is the separation of roles:

usermode client
  -> request interface
  -> SMM-side module
  -> memory operation from firmware context

That model explains why SMM-based access should not be judged like a normal usermode cheat or kernel driver. The sensitive operation is not primarily happening inside the Windows process or a normal loaded driver. It is moved into firmware/SMM context.

Hermes is also useful because it does not only show the attractive part of the idea. It mentions detection surfaces such as SMI count, cache side channels and UEFI image analysis. That matters. A lot of low-quality discussion says "Ring -2 = invisible", but Hermes itself points in the opposite direction: SMM changes the observation model, but it does not remove all observation.

For me, the main lesson from Hermes is this:

- SMM memory access is technically feasible.
- A usermode component can be only the request/control side.
- The sensitive primitive can be moved into firmware context.
- The detection surface changes from normal OS artifacts toward firmware, timing, cache and image-integrity artifacts.
- Feasibility does not equal safety.

That makes Hermes a good primary reference. It gives enough structure to discuss the technique without needing to rely on vague marketing terms.

4. Supporting references

SmmMem on ************* is useful as a supporting communication-pattern reference. Its rough model is usermode side -> mailbox / doorbell -> SMI -> SMM handler -> memory operation. The value is not that every SMM project must copy this exact route. The value is that it shows a driverless-style request path into firmware-side logic is plausible.

ekknod/smm is useful as a historical Ryzen SMM proof-of-concept reference. It shows that public SMM memory-access work existed before recent commercial or semi-private discussions. I would not use it as proof that any current private implementation copied that repository. It is better treated as evidence that the technique family has public roots.

Plouton is useful because it connects SMM / Ring -2 research to game-cheat style use cases. It shows that at least some developers are not treating SMM only as academic firmware research. They are experimenting with SMM as a practical framework category. That does not prove any product is mature, but it does show the direction is being actively explored.

Taken together, the supporting references make Hermes look less like an isolated curiosity. There appear to be multiple independent developers or small teams trying to push SMM from a firmware research trick toward more usable tooling. That is technically interesting, but it is still not the same as proving production-grade stability.

5. Feasibility assessment

Based mainly on the Hermes model, the following claims are technically plausible:

- SMM can execute below the normal OS kernel.
- SMM-side code can perform memory operations if a firmware-side path exists.
- A Windows kernel driver is not strictly required if the trigger and command path are designed differently.
- A usermode component, second PC or external device can act as request/control/transport while SMM performs the memory primitive.
- If the read/write primitive is firmware-side, the architecture is not the same as classic external PCIe DMA.

The following claims still require current, independent evidence:

- blanket "undetected" status
- "all anti-cheats" support
- "no DMA at all" without explaining what the transport hardware does
- universal Intel and AMD support
- stable operation across arbitrary BIOS versions and boards
- safety claims based only on the words Ring -2, no driver or firmware

The technically correct position is not hype and not dismissal. SMM memory access is feasible as a category. What remains difficult is engineering reliability, board coverage, firmware verification, transport design and current detection surface.

6. Practical evaluation criteria

If someone wants to evaluate an SMM-based implementation, the useful questions are:

- Where is the actual memory operation performed?
- How is SMM triggered?
- Which firmware component or SMM handler is involved?
- Which boards and BIOS versions are supported?
- Can the firmware be compared against a clean vendor image?
- What transport is used, and what artifacts can that transport leave?
- Are there current independent reports, or only author-controlled claims?
- What are the known failure cases?

These questions are better than asking only "is it DMA?" or "is it Ring -2?".

Conclusion

Hermes is the best main reference because it explains the actual SMM access model: usermode can request, SMM can execute, and the sensitive memory primitive can move into firmware context.

The supporting references, especially SmmMem, ekknod/smm and Plouton, show that this is part of a broader public technique family rather than a single isolated idea. Some developers and small teams are clearly exploring SMM beyond pure firmware research.

My view: SMM / Ring -2 should be treated as a serious firmware-level memory-access category. It is not ordinary DMA, but it is also not automatic proof of safety. The strongest discussion should focus on the actual memory primitive, trigger path, firmware component, board coverage and current independent evidence.

References

Main reference - pRain1337/Hermes:


Supporting reference - SmmMem thread:
smmmem-driverless-windows-memory-access-smm

Supporting reference - ekknod/smm:


Supporting reference - pRain1337/plouton: