Here's my situation:

I hate firewalls, load balancers, routers etc... want to root em all!

Anyway, I can't buy em all, and a lot of people think that it's dumb to buy them anyway. Why? So the common wisdom goes, they all run some kind of linux, so just analyse linux for some flaws.

People even say that testing against snort is as good as testing against a Cisco IDS device that might run snort or something like it....

So here's what I want to do:

I want to at least recreate the hardware conditions of a network device, and match that up to firmware and a pre-flashed device?

Objective Question

How would I go about about ensuring that the hardware environment I create with a virtual machine accurately mimics the real deal so that I might reverse engineer the system (using dynamic analysis to find binary flaw)?

Extra questions in case you decide to give me advice

Am I making this a more complicated problem than it needs to be?

Is this something that can be objectively proven?

Ultimately is it preferable to RE the physical device?

  • 1
    You'll need to re the physical device before you can emulate it correctly. Feb 19 '15 at 9:01
  • I believe you, although a more extensive answer might better satisfy my critics :)
    – baordog
    Feb 19 '15 at 13:17

First, note that most industrial-strength networking devices don't use Linux. If they did, mosts parts of the software would have to be provided in source code to comply with GPL requirements. So while your $100 Linksys router might use Linux, your $3000 Cisco router won't, and it won't be running snort either.

(Cisco's IDS and Snort might have several ideas in common, and maybe the IDS devs even copied a dozen of lines of code from Snort, but testing against snort to find vectors of attack against IDS is quite silly).

Most routers use some kind of MIPS, or ARM, processor. However, the IP of them is sublicensed to different hardware fabs, and the processor in your router might have some enhancements to the "official" versions. Maybe they added some silicon to enhance DMA transfers to route network packets faster. Maybe they added a hardware TCP checksum generator. Your MIPS QEMU / ARM QEMU processor won't know about those, so your emulation just won't work.

Now, even if you knew your router is running linux, and even if you knew about a linux bug, you couldn't be sure if this particular bug is exploitable on your particular hardware. Shellshock requires bash; it won't hurt busybox shell, and even if your router uses bash (unlikely), it might be a stripped-down version. You have to run the linux kernel from the official firmware, and the tools from your official firmware, on an emulated processor that fits your actual hardware, to check if your bug is exploitable.

But, chances are the official kernel won't even boot. The kernel will, at some point, try to read some configuration values from non-volatile storage. This might be a specialized chip on an I2C bus. Your emulation will have to emulate that I2C bus at the correct hardware addresses. But you don't know how to do this unless you've reversed the hardware.

The kernel will initialize each of the router ports. Which, again, means it will access specific hardware in a specific way. If it doesn't find the router ports, it will probably turn on a red 'hardware error' LED and enter an endless loop. So if you don't emulate the router ports, your kernel won't boot, and unless you emulate the LED, you won't even know why. Again, you need hardware information.

Last, knowing details about the hardware might help you exploit something. Assume each of the router ports has a corresponding /dev/portXX device, that accepts ioctls to set bitrate, duplex, and similar parameters. Assume all those /dev/portXX devices had the same major id, and minor ids from 0 to 31.

Maybe the port driver uses the minor id to calculate a hardware address, and doesn't sanity-check the minor id first. Creating a device node with a minor id between 32 and 255 might allow you to write to hardware registers after the ethernet ports, that have different meanings. Maybe the ports use addresses 0x8000000 to 0x8000001f, and 0x80000040 is the address of the configuration cmos. Creating /dev/port64 with a minor ID of 64 might allow you to use the port ioctl to read/write the cmos. However, you will never find that vulerability unless you have definite, deep knowledge about the hardware.

  • I think the gist of your comment is that is extremely advantageous to just have the hardware in your possession, which was my intuition in the first place. Of course, in that case the question becomes: How do I come into possession of enterprise grade networking gear? Great answer.
    – baordog
    Feb 19 '15 at 15:12
  • Fantastic answer, Guntram; it's always a pleasure reading what you write. @baordog, regarding coming "into possession of enterprise grade networking gear", do what everyone does who wants to play with pricey software/hardware -- ask your employer to buy it for you. Feb 19 '15 at 15:26
  • I'll try! In the meantime, I guess I can look on E-bay.
    – baordog
    Feb 19 '15 at 15:32

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.