Reverse Engineering Methodology

This page documents the techniques used to reverse-engineer the Winegard Carryout G2 firmware console. The same approach applies to any embedded device with a serial debug console — the tools and patterns are general-purpose.

The seven phases

The firmware mapping happened in stages, each building on what the previous phase revealed.

Phase 1: Serial connection and prompt discovery

The first step is finding the right electrical interface and baud rate. For the G2, Davidson’s winegard-sky-scan project documented RS-422 at 115200 baud, so we didn’t have to brute-force it. For an unknown device, you would:

1. Identify the connector type and pin count (RJ-12 6P6C in this case)
2. Use a multimeter to find ground, then probe for differential pairs
3. Try common baud rates: 9600, 19200, 38400, 57600, 115200
4. Look for readable ASCII in the output at each rate

Once connected at the right baud rate, send a bare carriage return (\r). If the device has a command shell, it will echo a prompt. The G2 responds with TRK>.

Polarity matters

RS-422 has separate TX and RX differential pairs. If you get garbled data at the correct baud rate, the RX pair polarity is inverted — swap the + and - wires. If you get no response at all, the TX pair polarity is wrong (the dish can’t decode your commands, so it silently ignores them).

Phase 2: Help command and initial inventory

Nearly every embedded console responds to ? or help. The G2 supports both:

TRK> ?

This prints the root menu command list. Each line follows the pattern Enter <command> - Description, which gives us both the command name and a hint about whether it enters a submenu.

From this single command, we got the list of 12 top-level commands (submenus) plus a few root-level commands like reboot, stow, and q.

Phase 3: Automated probing with console-probe

The ? command only shows what the firmware documents. Many commands exist that aren’t listed in help. The console-probe tool automates the process of finding them.

The discovery sequence:

1. Detect the prompt — send a bare \r, read back the response, extract the prompt pattern
2. Detect the error string — send a garbage command (__xyzzy_probe__), capture the error message. This becomes the filter: any response that contains the error string is “not a valid command”
3. Parse help output — extract command names and submenu hints from the ? response
4. Generate candidates — build a list of potential commands: single characters, two-letter combos, common embedded debug commands, and words from external wordlists
5. Probe each candidate — send it, check if the response differs from the error string. If it does, record it as a hit

console-probe --port /dev/ttyUSB2 --baud 115200 --discover-only --json /tmp/discovery.json

The probe tool handles recovery from several hazards during probing:

• Accidental submenu entry — if a command enters a submenu (detected by a prompt change), the tool navigates back to the previous menu level
• Shell termination — if a command kills the shell (the q command at root), the tool waits for the firmware to restart
• Streaming commands — some commands produce continuous output; the timeout-based read strategy handles these by stopping after no new data arrives

Phase 4: Interactive submenu exploration

Automated probing misses commands that require parameters. For example, a 0 180.0 is a valid motor command, but probing just a gives a position readout (which is useful too), and probing a 0 may return a partial error.

For each submenu, we entered it manually and typed ?:

TRK> mot
MOT> ?

This revealed the full set of 25 MOT commands, including parameter-requiring ones like a <id> <deg>, g <az> <el>, pid [motor] [Kp] [Kv] [Ki], and azscanwxp [motor] [span] [resolution] [num_xponders].

The DVB submenu has paginated help — ? shows the first page and man shows the second. The probe tool tries man automatically as an extra help command, but we discovered this through interactive use first.

Some submenus have commands that only the interactive ? reveals:

Submenu	Commands found by probe	Commands found by ? only
MOT	7 (a, e, l, life, p, r, v)	18 more (g, h, pid, azscan, azscanwxp, …)
DVB	5 (config, dis, lnbv, nid, snr)	33 more (rssi, agc, table, send, …)
STEP	4 (e, ma, mv, r)	3 more (p, pid, v)

The total went from ~40 probed hits to over 100 documented commands.

Phase 5: NVS dump and configuration space

The NVS (Non-Volatile Storage) submenu provides d to dump all stored values:

TRK> nvs
NVS> d

This returns every NVS index with its name, current value, saved value, and default value. The dump revealed 133+ configuration entries covering motor limits, PID gains, search behavior, sleep timers, elevation bounds, and satellite configurations.

Key discoveries from the NVS dump:

• Index 20 (Disable Tracker Proc?) — the switch that permanently disables TV satellite search
• Indices 80-88 — motor velocity and acceleration limits, steps per revolution
• Indices 101-103 — elevation min/max/home angles
• Indices 128-133 — PID tuning parameters for the motor control loop

NVS values can be modified with e <idx> <value> and committed with s. This is how the tracker is disabled for amateur radio use.

NVS is not EEPROM

The G2 has both an NVS submenu and an EEPROM (EE>) submenu. They are different storage systems. NVS is the firmware’s primary configuration store with named parameters. The EEPROM is a lower-level K60 FlexNVM interface that mostly reads as uninitialized (0 or 0x10101). The firmware uses NVS for almost everything.

Phase 6: GPIO probing and hardware mapping

The GPIO submenu provides direct access to the K60’s pin states:

TRK> gpio
GPIO> regs

The regs command dumps all GPIO pin states across ports A through E — 92 pins total. Cross-referencing these with the K60 datasheet’s pin multiplexing table identifies which pins are configured for which peripheral (SPI, UART, GPIO, etc.).

The process:

1. Run gpio regs to get the state of every pin
2. Run gpio dir <pin> on interesting pins to determine INPUT vs OUTPUT
3. Match pin clusters against K60 peripheral assignments from the datasheet
4. Correlate with boot log messages (e.g., “SPI1 init @ 4 MHz” tells us which SPI controller connects to the motor drivers)

This revealed the complete SPI1 (motor drivers) and SPI2 (DVB tuner) pin assignments, the UART4 console pins, and several unidentified outputs that are likely LNB control, status LEDs, and BCM4515 reset.

Phase 7: Boot log analysis

Power-cycling the dish with a serial terminal attached captures the full boot sequence. The G2’s boot log is detailed:

Bootloader v1.01
SPI1 init @ 4 MHz (mode 0x03)
Motor init: System=12Inch, master=40000 steps, slave=24960 steps, ratio=1.602564
SPI2 init @ 6.857 MHz (mode 0x03)
EXTENDED_DVB_DEBUG ENABLED
BCM4515 ID 0x4515 Rev B0, FW v113.37, strap 0x25018
Auto-search config: blind scan, 18000-24000 ksps, rolloff 0.35
Enabled LNB STB
Ant ID - 12-IN G2

Each line confirms a hardware detail: SPI bus speeds, motor step counts, DVB tuner identification, search parameters. The boot log is the single most information-dense source for understanding the hardware configuration.

What console-probe automates vs. what needed manual work

Task	Automated	Manual
Prompt detection	Yes	—
Error string detection	Yes	—
Help text parsing	Yes	—
Submenu entry/exit	Yes	—
Brute-force command probing	Yes	—
Paginated help (man)	Partially (tries it)	Discovered manually
Parameter-requiring commands	No	Full manual exploration
NVS dump interpretation	No	Manual analysis
GPIO/hardware correlation	No	Cross-reference with datasheet
Boot log capture	No	Power-cycle with terminal open
Safety hazard discovery	No	Learned the hard way (ADC scan deadlock)

The automated tool gets you maybe 40% of the command surface. The remaining 60% requires connecting what the firmware tells you with datasheets, boot logs, and careful experimentation.

Lessons learned

Prompt-terminated reads are essential. Fixed-timeout reads miss fast responses and waste time on slow ones. Reading until the > prompt character makes every interaction fast and reliable. But you have to handle the edge case where > appears inside parameter syntax (e.g., help [<command>]).

Not every valid command is safe. The ADC scan command without arguments on an unhomed axis targets position 2147483647 and deadlocks the shell forever. The root q command kills the firmware shell entirely. A probe tool needs to be cautious about commands that might brick the session.

Submenu help reveals more than root help. The root ? command gives a one-line summary per submenu, but entering each submenu and typing ? there reveals the full command set. Some submenus have multi-page help (DVB uses man for the second page).

NVS is the Rosetta Stone. The NVS dump gives you named configuration parameters with their defaults and current values. It tells you what the firmware considers configurable, which is a window into what the designers intended the device to do.

Boot logs reveal hardware. The firmware’s own initialization messages are the most reliable documentation of what silicon is on the board — chip IDs, bus speeds, memory sizes, step counts. This is faster and more accurate than trying to identify components visually on a PCB.