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.