Exploitation Tools

EmuScan – Advanced Emulation Detection For Firmware And Devices

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.

Varshini

Varshini is a Cyber Security expert in Threat Analysis, Vulnerability Assessment, and Research. Passionate about staying ahead of emerging Threats and Technologies.

Recent Posts

SpyAI : Intelligent Malware With Advanced Capabilities

SpyAI is a sophisticated form of malware that leverages advanced technologies to capture and analyze…

3 days ago

Proxmark3 : The Ultimate Tool For RFID Security And Analysis

The Proxmark3 is a versatile, open-source tool designed for radio-frequency identification (RFID) security analysis, research,…

3 days ago

Awesome Solana Security : Enhancing Program Development

The "Awesome Solana Security" collection is a comprehensive resource designed to help developers build more…

3 days ago

IngressNightmare-POCs : Understanding The Vulnerability Exploitation Flow

The "IngressNightmare" vulnerabilities, disclosed in March 2025, represent a critical set of security issues affecting…

3 days ago

AdaptixC2 : Enhancing Penetration Testing With Advanced Framework Capabilities

AdaptixC2 is an advanced post-exploitation and adversarial emulation framework designed specifically for penetration testers. It…

3 days ago

Bincrypter : Enhancing Linux Binary Security through Runtime Encryption And Obfuscation

Bincrypter is a powerful Linux binary runtime crypter written in BASH. It is designed to…

3 days ago