Bringing a Packeteer PacketShaper 1550 Back to Life in QEMU

Project Overview

The objective was not to recreate PacketShaper behavior with a modern substitute. The objective was to boot the actual recovered software stack: the original Packeteer boot loader, the original CompactFlash filesystem, the original hard disk image, and the original PacketWise runtime.

The machine proved to be unusually sensitive to period-specific hardware behavior. Stock QEMU could execute the x86 code, but several small hardware assumptions prevented the firmware from recognizing the emulated machine as viable. Progress therefore became a process of identifying one failed expectation at a time and reproducing the behavior PacketWise expected from the real appliance.

Recovered Appliance Identity

Network interfaces

Storage

The recovered unit uses two distinct block devices. Both are preserved as raw forensic source images and are never modified directly. QEMU operates against QCOW2 overlays.

Firmware and Boot Architecture

The CompactFlash contains Packeteer firmware archives in ZOO format. The primary archive contains a raw x86 pSOS image named ram.abs and a second-stage loader named psosboot.sys. The CompactFlash partition itself is not a conventional standalone DOS boot environment: its FAT boot sector can execute under SeaBIOS, but subsequently reports No sys. The original Packeteer ROM evidently performed a specialized handoff.

Primary runtime image

Second-stage loader

An early breakthrough was discovering that the loader is based at 0x7e00, not 0x7800. With the correct base, its IDT, GDT, interrupt vectors, and internal function tables all became coherent.

Selector compatibility

PacketWise expects a nonstandard selector arrangement relative to the first shim attempt: selector 0x08 is data and selector 0x10 is code. Correcting the protected-mode handoff to CS=0x10 and DS/ES/FS/GS/SS=0x08 was required for reliable execution.

Field Notes: From Disk Images to a Living Appliance

The part I wanted to preserve in this write-up is that this did not begin as an abstract emulator exercise. It began with the physical appliance and its media. The CompactFlash and hard disk were treated as historical artifacts first and software inputs second.

The 20 GB Seagate ST320014A was re-imaged into a raw disk image and then retired from active experimentation. The same preservation rule was applied to the CompactFlash: make the best raw image possible, hash it, and stop writing to it. Every destructive or exploratory test after that happened against a fresh QCOW2 overlay.

physical media
     ↓
forensic/raw image
     ↓
SHA-256 / preservation master
     ↓
QCOW2 backing file
     ↓
disposable experiment overlay

That discipline turned out to matter. PacketWise has real primary/backup firmware behavior, and one of the experiments caused the appliance to promote its backup image into the primary slot. Because the raw CF image was never modified, it was possible to return to the exact recovered state and prove what the appliance had done instead of guessing.

There was also a satisfying reversal in the project. At first the disk images looked like the difficult part: old FAT partitions, ZOO archives, a strange boot path, and an HDD that the appliance still refuses to consider operational. By the end, the images were the most stable pieces of the system. The difficult part was teaching modern emulation to behave like a very particular early-2000s Packeteer motherboard.

Inside the Custom QEMU / Boot Firmware Build

The final machine is not running on an untouched stock QEMU binary. A small set of targeted compatibility changes reproduces hardware behavior that PacketWise checks directly. The important distinction is that these are narrow emulation fixes: they preserve the recovered Packeteer software instead of rewriting it to fit modern virtual hardware.

ATA RECALIBRATE compatibility

PacketShaper sends ATA RECALIBRATE command 0x1f. QEMU 7.2 handled the conventional 0x10 opcode but not the rest of the legacy 0x1x family. The IDE core was changed so any command whose high nibble is 0x10 is normalized to WIN_RECAL before command dispatch.

/* hw/ide/core.c */
if ((val & 0xf0) == 0x10) {
    val = WIN_RECAL;
}

That one compatibility rule changed PacketWise's view of the emulated ATA devices from “nothing useful is there” to successful IDENTIFY/initialization behavior.

PIIX3 IDE bus mastering

The loader also expected PCI bus mastering to be enabled before it attempted IDE DMA. Rather than falsify the device state in QEMU, stage one performs the PCI configuration write the real boot environment evidently provided:

mov dx,0xcf8
mov eax,0x80003904
out dx,eax
mov dx,0xcfc
in  al,dx
or  al,0x04
out dx,al

AMD PCnet BCR19

PacketWise interrogates BCR19 (BCR_EECAS) on both PCnet adapters and treats the sign bit as meaningful. Stock QEMU initialized that register to 0x0002; the PacketShaper compatibility build initializes it to 0x8002.

/* hw/net/pcnet.c */
s->bcr[BCR_EECAS] = 0x8002; /* Packeteer M30 compatibility */

This was not cosmetic. Before the change, PacketWise logged that the M30 MAC addresses were not configured and left the live device structures empty or incorrect. Afterward, the genuine recovered BASIC.CFG interface identities populated normally and both adapters initialized.

Packeteer board emulation

A custom QEMU device supplies the Packeteer-specific board identity and legacy control I/O expected by the firmware. The recovered unit is presented as an M30-class board with board ID 0x10, including the legacy board-ID/control ports used during startup.

-device packeteer-m10,board-id=0x10,verbose=true

An important negative result belongs here too: an early theory proposed a synthetic 0xF000FFxx MMIO block. Disassembly and runtime tracing did not support that model, so it was deliberately not carried into the final build. The goal throughout was to add only behavior that could be justified by the recovered code or controlled experiments.

The boot floppy became custom firmware

The final psosboot_boot-runtimepatch.img is effectively a tiny compatibility firmware layer. It performs the real-mode loading and protected-mode handoff, enables PIIX3 bus mastering, enters the genuine Packeteer psosboot.sys, and finally intercepts the three validated ram.abs launch paths long enough to apply the watchdog compatibility byte in RAM.

Hardware Compatibility Breakthroughs

The Watchdog Failure

Once storage initialization, PCI topology, MAC handling, and configuration loading were working, PacketWise consistently reached approximately 4.27 seconds of runtime and died:

[0000004.2658] W: LockDump: Lock count = 0
[0000004.2658] W: LockDump: last unlock @ 37307 from file idleutl.c, line 244
[0000004.2658] F: native_shaper_watchdog: shaper watchdog count exceeded
[0000004.2668] W: native_shaper_watchdog: current task mode = 0x200
...

Reverse engineering identified the primary firmware's counter and fatal branch:

1dc67f  incl  0x6036dc
1dc685  cmpl  $0x190,0x6036dc
1dc68f  jle   0x1dc6aa
1dc691  mov   0x6036d8,%edx
1dc697  test  %edx,%edx
1dc699  je    0x1dc6a4
1dc69b  call  0x1d9ec0    ; native_shaper_watchdog
1dc6a0  jmp   0x1dc6aa
1dc6a4  mov   %edx,0x6036dc

A manual GDB experiment changed the conditional jump at 0x001dc699 from JE (0x74) to JMP (0xeb). PacketWise immediately completed startup and reached its native serial console. That proved the remaining firmware was fundamentally functional.

Why Patching IMAGE.ZOO Was the Wrong Layer

The first attempt at making the watchdog bypass persistent modified ram.abs inside IMAGE.ZOO. Although the ZOO archive itself tested cleanly, Packeteer's loader rejected the modified image. Subsequent experiments revealed a genuine primary/backup firmware rollback mechanism.

When both archives were modified, psosboot.sys refused to boot either and continuously printed:

LOAD PSOS
PSOS OK - GO

No bootable image!!!
No bootable image!!!
No bootable image!!!

This established that Packeteer performs an integrity or bootability check above ordinary ZOO archive CRC validation. The correct solution was therefore to leave both recovered archives exactly intact.

The Final Runtime Shim

Disassembly of psosboot.sys revealed three successful firmware handoff sites. In each path, the validated/decompressed ram.abs base is stored at -4(%ebp) and the loader transfers control to base + 4:

mov    -0x4(%ebp),%eax
lea    0x4(%eax),%eax
mov    %eax,%edx
call   *%edx

The three handoff sites are:

The floppy image contains 495 zero-filled bytes immediately after the end of psosboot.sys but still inside the sectors already loaded by stage one. That unused area became a code cave for a small compatibility shim.

Immediately before launching the firmware, the shim identifies the loaded firmware generation by its entry bytes, changes the appropriate watchdog branch in RAM from 0x74 to 0xeb, then transfers control to the original ram.abs + 4 entry point. Unknown firmware generations are left untouched.

genuine IMAGE.ZOO / BACKUP.ZOO
              │
              ▼
      Packeteer validation
              │
              ▼
      ram.abs decompressed
              │
              ▼
  psosboot runtime compatibility shim
       │                   │
       │ primary           │ backup
       ▼                   ▼
  +0x5c699             +0x595b5
    74 → EB               74 → EB
       │                   │
       └─────────┬─────────┘
                 ▼
             base + 4
                 │
                 ▼
           PacketWise runtime

Working QEMU Configuration

The known-good environment is based on a locally built QEMU 7.2.0 with the Packeteer compatibility changes described above.

~/qemu-7.2.0/build/qemu-system-i386 \
  -machine pc,accel=tcg,acpi=off \
  -cpu pentium3 \
  -m 256 \
  -boot a \
  -drive if=floppy,format=raw,file=psosboot_boot-runtimepatch.img,readonly=on \
  -drive if=none,id=cf,format=qcow2,file=packeteer_cf-runtimepatch.qcow2 \
  -device ide-hd,drive=cf,bus=ide.0,unit=0,model="Generic- Compact Flash",cyls=490,heads=8,secs=32 \
  -drive if=none,id=hdd,format=qcow2,file=packeteer_ide-runtimepatch.qcow2 \
  -device ide-hd,drive=hdd,bus=ide.0,unit=1,model=ST320014A,cyls=16383,heads=16,secs=63 \
  -nic none \
  -netdev user,id=inside \
  -device pcnet,netdev=inside,mac=00:60:fb:51:18:f2,addr=3 \
  -netdev user,id=outside \
  -device pcnet,netdev=outside,mac=00:60:fb:51:18:f3,addr=4 \
  -device packeteer-m10,board-id=0x10,verbose=true \
  -serial stdio \
  -display none \
  -no-reboot \
  -no-shutdown \
  -monitor tcp:127.0.0.1:4444,server,nowait

First Fully Automatic Cold Boot

With fresh QCOW2 overlays backed by the untouched recovered disks and the runtime-patched boot floppy, the system passed the previous watchdog boundary and presented the genuine PacketShaper console:

LOAD PSOS
PSOS OK - GO

Loading....................................................................

PacketShaper (console)

loading configuration....

Password:

Local login, touch access granted.
PacketShaper v6.2.1g1 2004-05-24
Copyright (c) 1996-2004 Packeteer, Inc. All rights reserved.

PacketShaper not yet configured.  Do you wish to be
guided through initial setup of the PacketShaper? (yes): no

Skipping guided initial setup.

IP address not configured.
Gateway not configured.
Packet shaping: off.

PacketShaper#

This is the important dividing line in the project: firmware boot is no longer dependent on debugger intervention. The recovered appliance can now enter PacketWise under its own boot flow.

Known Remaining Issues

Hard disk operational warning

The hard drive does not appear to be operational.
This may affect normal operation.

The HDD is visible to the emulated IDE subsystem and earlier ATA incompatibilities have been corrected, but PacketWise still does not consider the drive operational. This is now a distinct storage compatibility problem rather than a boot blocker.

Flash filesystem warning

Illegal filename: /B \000I\000n\000f.\000o\000

Path name too long(2).

Problems were detected on the flash drive file system.
This may affect normal operation.
You can correct these at any time using the command:
sys clean flash

The malformed filename resembles a FAT/VFAT long-filename artifact. Because preservation is more important than convenience, sys clean flash should not be run against the only working copy. Filesystem repair experiments belong on disposable overlays.

RTC / date

This unit's date and time (Wed Dec 31 16:00:34 1969) appears wrong.

RTC behavior has not yet been normalized. This warning does not prevent PacketWise from entering the CLI.

Preservation and Reproducibility

The working build should be treated as a preservation package rather than a single disk image. The appliance depends on interactions between firmware, loader behavior, PCI topology, NIC register behavior, IDE semantics, and the Packeteer board interface.

Final archival copies should include SHA-256 manifests for every component and a short README describing which items are original recovered media, which are derivative overlays, and which contain emulation-specific modifications.

Conclusion

PacketShaper was not defeated by one large incompatibility. It was blocked by a collection of small assumptions that made perfect sense on a tightly controlled early-2000s appliance: unusual selector layout, old ATA command behavior, PCI bus-master state, PCnet board register semantics, proprietary board identity, and a software watchdog whose heartbeat depended on original-system behavior.

Reproducing those assumptions one at a time eventually allowed the original 2004 software to do exactly what it was designed to do. The final compatibility shim is deliberately narrow: Packeteer's firmware remains authentic, Packeteer's loader performs its own validation, and the emulator intervenes only at the final instant before the validated runtime begins execution.

The most satisfying moment was not a synthetic test or a debugger breakpoint. It was removing GDB, creating fresh overlays from the untouched media, launching the machine from a normal shell, and watching LOAD PSOS become a real PacketShaper login prompt on its own. After re-imaging disks, extracting twenty-year-old archives, rebuilding QEMU, tracing ATA and PCI behavior, and chasing the watchdog through two separate firmware generations, the thing finally behaved like an appliance again.