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

Shadow-rs : Harnessing Rust’s Power For Kernel-Level Security Research

shadow-rs is a Windows kernel rootkit written in Rust, demonstrating advanced techniques for kernel manipulation…

2 weeks ago

ExecutePeFromPngViaLNK – Advanced Execution Of Embedded PE Files via PNG And LNK

Extract and execute a PE embedded within a PNG file using an LNK file. The…

3 weeks ago

Red Team Certification – A Comprehensive Guide To Advancing In Cybersecurity Operations

Embark on the journey of becoming a certified Red Team professional with our definitive guide.…

3 weeks ago

CVE-2024-5836 / CVE-2024-6778 : Chromium Sandbox Escape via Extension Exploits

This repository contains proof of concept exploits for CVE-2024-5836 and CVE-2024-6778, which are vulnerabilities within…

3 weeks ago

Rust BOFs – Unlocking New Potentials In Cobalt Strike

This took me like 4 days (+2 days for an update), but I got it…

3 weeks ago

MaLDAPtive – Pioneering LDAP SearchFilter Parsing And Security Framework

MaLDAPtive is a framework for LDAP SearchFilter parsing, obfuscation, deobfuscation and detection. Its foundation is…

3 weeks ago