This test is based on ekknod’s [drvscan], with added emulation detection for common devices. Thanks to ekknod for his contribution.Thanks to my good friend HChai for providing the software interface and ideas.

Important Functions

  • Detecting DMA disguised devices
  • Activate firmware (to be added in the future)

Common Problem

Q: The driver cannot be started

A: 1. Run Powershell as an administrator

  1. bcdedit /set testsigning on
  2. reboot
  3. After rebooting, the test mode is displayed in the lower right corner of the screen. Run start.bat again.

Q: How to read the detecting results?

A: The detecting results only list problematic devices. If no PCIe devices are listed, it means your firmware has passed the detection.

Q: What is dumb emulation?

A: “Dumb emulation” refers to when your BAR (Base Address Register) responds to requests from RW Everything or Arbor scan results.

This type of response allows the driver to load correctly. However, this type of response bypasses some necessary driver loading processes and does not fully respond to the entire driver loading procedure.

Q: Why my firmawre can not breath?

A: After I shared the method to make your firmware “active,” many people asked me why their firmware still couldn’t pass EKK’s breathing detection after using the method.

Before answering this question, I need to add some theoretical knowledge about interrupts.

An interrupt signal is a special asynchronous signal that, when captured by the CPU, prompts the CPU to query the interrupt service routine (ISR) associated with that signal.

In PCIe devices, this ISR is typically bound within the driver when the driver confirms that the device is ready to interact with the CPU. In Linux, this function is usually referred to as device_open.

Therefore, if you want your firmware to pass the breathing detection, you need to ensure that your BAR (Base Address Register) response can convince the driver that the device is ready to interact with the CPU via DMA.

This means your device must be correctly emulating the behavior expected by the driver, allowing the driver to proceed as if the device is fully operational.

Q: How to fix the issue?

A: Try debugging the driver or seek help from a professional developer.

Q: If my firmware passes the detection, does it mean that this is a FULL emulation firmware?

A: My detection only covered common devices. To determine if a firmware is FULL emulation, it’s necessary to simulate the driver loading process.

If your firmware passes the test, feel free to inform me, and I’ll include the corresponding firmware detections in the future.

LEAVE A REPLY

Please enter your comment!
Please enter your name here