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

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

Kali Linux 2024.4 Released, What’s New?

Kali Linux 2024.4, the final release of 2024, brings a wide range of updates and…

45 minutes ago

Lifetime-Amsi-EtwPatch : Disabling PowerShell’s AMSI And ETW Protections

This Go program applies a lifetime patch to PowerShell to disable ETW (Event Tracing for…

54 minutes ago

GPOHunter – Active Directory Group Policy Security Analyzer

GPOHunter is a comprehensive tool designed to analyze and identify security misconfigurations in Active Directory…

2 days ago

2024 MITRE ATT&CK Evaluation Results – Cynet Became a Leader With 100% Detection & Protection

Across small-to-medium enterprises (SMEs) and managed service providers (MSPs), the top priority for cybersecurity leaders…

5 days ago

SecHub : Streamlining Security Across Software Development Lifecycles

The free and open-source security platform SecHub, provides a central API to test software with…

1 week ago

Hawker : The Comprehensive OSINT Toolkit For Cybersecurity Professionals

Don't worry if there are any bugs in the tool, we will try to fix…

1 week ago