Reverse engineering a controller: where to start.

There comes a point where mapping is no longer enough. You move a control, look for its function in the software list, and it is not there. You consult the manufacturer’s documentation and cannot find it. Or worse: the documentation exists, a two-hundred-page PDF, but omits the exact message you need.

That is where this territory begins. And it begins with good news: almost everything you need is already in front of you, because your equipment constantly sends those messages.

When it is necessary, and when it is not

Before getting to work, remember that most cases do not require it. For an ordinary controller, observing incoming messages and consulting manufacturer documentation is sufficient.

It becomes genuinely necessary when:

• Documentation does not exist. This is not unusual.
• Documentation exists but is incomplete. The classic example is specific: many manuals do not document the message requesting all knob and fader positions when the application starts. Without it, your mapping works, but the software does not know your controls’ positions until you move each one.
• The equipment does not speak MIDI. It uses HID or a proprietary protocol, so there are no messages to find in a list: there are bytes to interpret.

A warning that saves weeks: do not start from scratch. First investigate whether your model—or any model in its family—has already been analysed. Devices from the same manufacturer share many things, and fine details (such as interpreting LED values) often repeat. Repeating published analysis is the most expensive mistake in this field.

Ways to discover the protocol, from least to most effort

The table orders the four approaches. That order is not decorative: the first two resolve most cases, yet many people jump to the fourth without doing them.

The starting point: watch what arrives

This is the first thing to do, and requires no external tool.

Start the software with controller debugging enabled and watch the console output or log file, which contains all received MIDI messages. As you manipulate the controller, messages are printed.

A real example of that output when moving a fader:

MIDI ch 1: opcode: B0, ctrl: 2, val: 3D
MIDI ch 1: opcode: B0, ctrl: 2, val: 3A
MIDI ch 1: opcode: B0, ctrl: 2, val: 3B

Read it this way: 0xB0 is a Control Change message on channel 1; the second byte, 0x02, is the number of the control moved; the third is its value or position, which you can ignore for mapping.

Watch for a detail almost everyone discovers late: that value does matter when controlling LEDs, because the number tells you which colour or brightness level you are sending.

The method is simpler than it seems

Once the first two bytes are identified, convert them into an XML control block: the first becomes the status and the second the control number. That is the entire mapping of a new control.

In other words: move a control, see what comes out, record two bytes. Repeat. The tedious part is not difficulty but the number of controls.

Moving from observation to understanding: status bytes

To avoid working blind, understand how a status byte is built. It is easier than it sounds.

The first byte of every MIDI message is the status byte, read in two halves:

• The first hexadecimal digit is the opcode: the message type.
• The second is the channel number.

Thus, 0x90 means opcode 9 (note on) and channel 0 (the first). With that rule and a small table, you can read any capture:

Status byte	Message
0x8n	Note off
0x9n	Note on
0xAn	Polyphonic after-touch
0xBn	Control change
0xCn	Program change

Here, n is the channel. With this table, a capture of hundreds of lines stops being a puzzle and becomes a list of “this button”, “this fader”, “this pad”.

Two points to keep in mind from the beginning:

• Everything is shown in hexadecimal. Not by preference: it is the format used to think about MIDI, and manuals documenting messages use it too.
• Equipment complying with the USB MIDI standard—known as class compliant—does not need a driver. If your equipment requires a proprietary driver, that is already a clue it may use something other than standard MIDI.

When the manufacturer hides the protocol

Here we reach the territory beyond MIDI. If the equipment sends no MIDI, or the manufacturer hides it, watching your software’s logs is useless: there is nothing to see because the message never reaches that layer.

The route then is to record USB traffic: listen to the conversation at a lower level, where everything appears, whether it speaks MIDI or not.

One elegant detail explains why this works: MIDI travels within the USB audio standard. You can therefore analyse it with the same tools as USB audio traffic, filtering for MIDI. HID traffic, by contrast, is different and has its own filter.

The complete technique—setup, filters, reading an extra byte, and capturing without drowning in data—has its own guide because there is much to cover. Here the idea is enough: when the protocol is hidden, record the cable.

One recommendation is worth giving now because it saves the most time: capture only a few seconds while performing one specific action. Thirty seconds of capture while starting an application can easily leave 70 to 100 MB of data. Working with that is suffering, not analysis.

Two real cases, and why they are the best material

The reference documentation presents two Denon hardware examples illustrating the two possible outcomes of this work.

The successful case

On the MC4000, capture analysis located the SysEx message the software used to request every knob’s state at startup. Sending it to the controller returned the current positions of all controls, and the message could be used in the mapping’s startup routine.

Result: the software knows where the controls are without the user moving them.

The case requiring more work

On the MC7000, the manufacturer hid the specifications. There were no obvious SysEx messages to find.

The solution was cleverer: knowing that Denon had collaborated with the other software, the search targeted that other company’s MIDI manufacturer identifier in the capture, rather than Denon’s. Usable SysEx messages appeared.

What these two cases teach

• MIDI manufacturer identifiers are a search tool. If a message is not under your manufacturer’s name, it may be under its partner’s.
• SysEx always starts with f0 and ends with f7. That is the signature to search for.
• Sometimes the information exists, but not where expected. Changing the search hypothesis is part of the method.
• Often you cannot extract everything. With Engine DJ hardware, some manufacturer documentation was readable, yet questions remained: how to interpret values, what to send to control an LED ring, or whether LEDs are on/off or dimmable. This is resolved through trial and error, not reading.

That last point matters and is rarely stated: in this field, sometimes there is no answer to read, only one to test.

Tools by operating system

You do not need a laboratory. You need a MIDI monitor and, for HID, a traffic capture:

• Windows: a traditional MIDI monitor can intercept messages from other applications.
• macOS: dedicated MIDI monitors are available for observing signals.
• Linux: the audio utilities package includes tools to list devices, dump their traffic, and send specific messages from the command line. That last detail turns analysis into testing: you do not just listen; you test hypotheses.

To see what other software does with the equipment, the documented method is running it in a virtual machine and recording USB from the host system. For Windows in a virtual machine, the documentation warns against installing some manufacturers’ proprietary drivers because they interfere with virtual-machine audio, and says the audio will stutter—which is perfectly acceptable when observing messages rather than DJing.

Rules for responsible work

This section is not a formality. It distinguishes this work from something else, and should be clear before starting.

What this field is:

• Working on your own equipment.
• Seeking interoperability: making your hardware work where you want, not where you are forced.
• Documenting observations so the next person does not start from zero.
• Always distinguishing protocol investigation from bypassing a protection. They are different, even if they sometimes look similar from outside.

What this field is not:

• Redistributing proprietary firmware. Analyse it; do not distribute it.
• Sharing other people’s keys or credentials.
• Publishing instructions to evade protections.

This guide follows its own rule: it explains architecture, method, and risks, and does not publish procedures for enabling closed interfaces. This is not an omission: it is this section’s editorial boundary, keeping the material useful and defensible.

On the legal framework: this guide provides no legal advice, and rules differ by country and case. What can be stated is that the technical community’s practice—own equipment, interoperability purpose, public documentation, no other people’s firmware—has produced all the open knowledge you use daily without realising it.

Common mistakes

• Starting with Wireshark. Most cases are resolved by observing your own software.
• Not checking whether your model has already been analysed. It is the most expensive repeated work.
• Capturing whole minutes of traffic. You will drown in data for an action lasting two seconds.
• Searching only under your equipment manufacturer. Sometimes the message is under its partner’s.
• Ignoring the third byte’s value. For mapping it does not matter; for LEDs, it is everything.
• Assuming the manufacturer documents everything. Many do not, and the technical documentation openly admits it.
• Confusing investigation with evasion. This boundary must be clear and determines whether your work is publishable.

Next step

You now have the method, approaches, tools, and rules. What remains is the most technical part and the one appearing most often in forums: how to set up a real USB traffic capture, which filters separate MIDI from HID, why an extra byte appears, and how to make clean, reproducible captures. That is exactly the next guide.