I'm trying to get the router firmware (binary) running on QEMU (if that is possible). All networking is set up fine because I've tested it using the debian_wheezy_mips_standard.qcow2

sudo qemu-system-mips -M malta -kernel vmlinux-3.2.0-4-4kc-malta -hda MYROUTERBINARY.bin 
-append "root=/dev/sda1 console=ttyS0"-nographic

when I run this QEMU goes into a blank screen. I thought that it might not have a user interface due to it being a router but I can't get any response when running a nmap against the IP address space it should be in.

Should I import the filesystem using:

sudo qemu-system-mips -M malta -kernel vmlinux-3.2.0-4-4kc-malta -hda
debian_wheezy_mips_standard.qcow2 -append "root=/dev/sda1 console=ttyS0" -nographic

Let's say for instance I have netcat running on the router. I want to be able to access the port, so need the router firmware/filesystem needs to be running

Can anyone help please?

  • 3
  • In this case he's using a kernel built for QEMU though, so it's more like reverseengineering.stackexchange.com/questions/4480/…. This is something that ought to work. @user15945, maybe try adding earlyprintk to the kernel command line? Apr 29 '16 at 17:14
  • "Let's say for instance I have netcat running on the router. I want to be able to access the port, so need the router firmware/filesystem needs to be running" If all you need to be able to telnet to the router, just do it from any computer. Otherwise your question does not make sense. Apr 30 '16 at 4:33
  • 1
    @VitalyOsipov How does't his question make sense when he wants to telnet to the emulated router but can't get said emulated router to start up? Apr 30 '16 at 6:02
  • 1
    For this to work, your QEMU needs to emulate the hardware of the router's ethernet interface, and "connect" that interface to the host's network(!). I somehow doubt it's doing that. I guess the kernel won't even start when it doesn't find the router's physical hardware. Apr 30 '16 at 6:11

Most MIPS/ARM based routers have a ROM bootloader that runs when the device is powered on. This bootloader is typically accessible via a serial port, but some platforms (like AR7) do weird things like have an FTP server going (you can flash firmware through it).

This bootloader will load a kernel image and initrd from a partition of a NAND device, then run it.

The bin file is probably designed to be written to a flash partition directly, then unpacked/loaded into RAM by the bootloader. There are more partitions than just the one holding the kernel, you will have one possibly holding the initrd or rootfs, and one acting as the "NVRAM" or holding settings. One may even hold the bootloader itself.

Once Linux is running, firmware upgrades happen by writing to a /dev/mmcbllkpX device.

You can probably solve the bootloader issue by finding out which flash partitions on the device are the kernel and initrd, and use QEMU's -kernel and -initrd options to load them.

But the firmware will still likely be expecting ALL of the original flash as part of its expected devices. This is where you are going to run into serious problems.

I don't know how to get QEMU to emulate a NAND device or if it's even possible (it's NOT the same as a disk device). Most routers have a single NAND device "partitioned" and the Linux kernel recreates them as /dev/mmcblkp0, /dev/mmcblkp1, etc. To attempt recreate the original environment of the device, you really need the full NAND dumped and partitioned as it is on the chip.

There is also the problem that if the router is not Linux-based, that it may only work with the specific hardware devices in the router.


You may need to first unpack the bin file (using something like binwalk). I don't think that you can just reference the .bin as an hda. Typically, once you unpack the .bin file, you will be given the filesystem of the device. you have have several different partitions as some router manufactures will create a main fs shared across several models, and then create smaller modules to be loaded into model specific devices. If you look at the init of the root fs you should be able to see how other partitions in the .bin are getting moved around, and mimic it.

Personally, I have never attempted to emulate the full device, I find more value in being able to unpack the .bin , and scp it over to the wheezy_mips hda and and attempt to run parts of the router by themselves. Also I think you are going to run into networking problems. emulating the wheezy_mips hda is easy, remember that your .bin is meant to load in an environment that has several network interfaces,

-Good luck.


sudo qemu-system-mips -M malta -kernel vmlinux-3.2.0-4-4kc-malta -hda MYROUTERBINARY.bin -append "root=/dev/sda1 console=ttyS0"-nographic

Do the equipment you will use the bin file has partitions? I will add as a final statement --no-acpi. It should do it. When you run qemu systems that part is very important. Or the symptom you are explaining will happend.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.