NetGear Series 1.1 — Emulating Netgear R6700V3 circled binary (CVE-2022–27644, CVE-2022–27646) Part 1

4 min readJan 25, 2023

Introduction

In this series, we will be documenting our journey on analysing a binary on Netgear routers R6700v3. The team has chosen to work on the circled binary for the following reasons:

Firmware can be downloaded from Netgear official website and older version of the firmware are available as well
Multiple recent exploits on the R6700V3 router in pwn2own competitions [1,2,3]
A home router is chosen instead of SME/SMB devices for simplicity sake to keep our motivation high

In this series, we will document our journey to emulate the circled binary since this was not covered in the articles providing the analysis [2,3], probably because they own the physical device.

Methods of analysing the circled binary

Netgear firmware can be easily extracted to obtain the SquashFS [4], a read-only file system of the router, using the binwalk tool or the firmware mod kit [5]. From the output of the file command of circled binary, the router is running on ARM little endian architecture.

bin/circled: ELF 32-bit LSB executable, ARM, EABI5 version 1 (SYSV), dynamically linked, interpreter /lib/ld-uClibc.so.0, stripped

Analysing the binary can be in the form of static analysis or dynamic analysis to understand the binary’s capabilities and behaviour. Usually, both forms of analysis are performed to speed up the process in understanding the binary. Static analysis can be performed using a disassembler/decompiler using either Ghidra or IDA Pro. Performing dynamic analysis is however more challenging as most of our consumer laptops are operating in the x86/x64 architecture (well unless you own a M1/M2 MacBook then it’s a different story). The table below highlights some of the possible ways to analyse the runtime behaviour of the binary, with the corresponding pros and cons.

Since our team doesn’t have the physical router, we opted for the emulation method to perform dynamic analysis.

Different emulation strategies

From the article in [6], there are two broad categories of emulation — full system emulation and individual program emulation.

Full system emulation

There are multiple frameworks that allow us to perform full system emulation and most of them use QEMU to emulate the ARM instructions. QEMU will first load up a compiled ARM linux kernel before starting to boot up the firmware in the emulated ARM environment. In the ideal scenario, this will simulate the exact bootup behaviour, spawning all the necessary services that the router need for its functionality. From there, the researcher is able to perform analysis as though it is the physical device itself.

However, the reality is usually far from ideal as there are certain obstacles that one has to overcome when emulating the full system. Although the firmware is loaded up in a “native” ARM environment, there are still missing components that the firmware need for successful emulation such as the NAND which is usually referred to as NVRAM. The frameworks that are being developed in the community aim to populate these missing components in order to emulate different devices.

Individual binary emulation

If one does not want to deal with all the missing components, one can actually just emulate a single binary of interest. This means that we have less components to juggle with. QEMU provides a User-Mode emulation method which allows researcher to emulate just a single binary on their x86/x64 system. However, this comes with a shortfall as router binaries tend to fork and QEMU User-Mode emulation method does not allow one to debug the child process [5]. To overcome this, we have to “hack” the binary to fork such that the parent process becomes the child process in order to analyse the child process.

Another alternative to analyse individual binaries is to use QEMU to boot up an ARM linux distribution such as Debian or Ubuntu. With the ARM OS running, we can chroot into the firmware filesystem and execute the binary. This will allow one to debug processes spawned since we are not relying on QEMU User-Mode to emulate the binary. To make the emulation more portable, we can containerise the emulated linux OS with QEMU (yes, this is necessary if your team members use different versions of Linux for their analysis).

Ending notes

With the different types of emulation being laid out, we will continue our journey to emulate circled in the next post.