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.

Tamil S

Tamil has a great interest in the fields of Cyber Security, OSINT, and CTF projects. Currently, he is deeply involved in researching and publishing various security tools with Kali Linux Tutorials, which is quite fascinating.

Recent Posts

MSI Analyzer – Analyzing Windows Installer Files For Vulnerabilities

This Python script for Linux can analyze Microsoft Windows *.msi Installer files and point out…

17 hours ago

BEAR-C2 : Simulated Command And Control Framework For APT Attack Research

Bear C2 is a compilation of C2 scripts, payloads, and stagers used in simulated attacks…

17 hours ago

Bearer – A Quick Guide To Scanning And Securing Your Application

Discover your application security risks and vulnerabilities in only a few minutes. In this guide…

17 hours ago

Waymore – A Comprehensive URL Retrieval And Archival Tool For Advanced Reconnaissance

The idea behind waymore is to find even more links from the Wayback Machine than…

18 hours ago

Pycript – A Versatile Burp Suite Extension For Encryption And Decryption

The Pycript extension for Burp Suite is a valuable tool for penetration testing and security…

18 hours ago

DependencyTrack 4.10.0 – Release Overview And Security Hashes

For official releases, refer to Dependency Track Docs >> Changelogs for information about improvements and…

3 days ago