Anna Antonenko, who specializes in embedded systems development and in her spare time is developing the BOSS (BEAM-based Operating System with Security), published the results of reverse engineering the Yamaha PSR-E433 synthesizer. During the work, an obfuscated shell interface was discovered in the synthesizer, allowing the execution of custom code at the firmware level. Access to the shell interface is achieved by sending MIDI packets with SysEx messages, which can be transmitted when the synthesizer is connected via USB port. The findings from the reverse engineering regarding the chip and firmware, as well as code examples and debug dumps, are available on GitHub.
Interest in reverse engineering arose a few years ago when Anna decided to clean the insides of the synthesizer from dust and also satisfy her curiosity about the device's internals. The board contained a chip, YAMAHA SWL01U, about which detailed information could not be found on the internet. A couple of months ago, Anna came across a manual for a similar synthesizer model that included the pinout of this chip. Anna disassembled the device again and began experiments, utilizing the available board connections for the JTAG debug interface and UART port.
Using the OpenOCD debugger, connecting to JTAG, and conducting experiments, it was discovered that the board uses a chip with an ARM7TDMI processor core. By studying the memory layout in the debugger, it was possible to dump the contents of the firmware stored in ROM and Flash memory. After that, the firmware images were analyzed in the reverse engineering suite Ghidra.
During the review of the extracted string data from the firmware, a set of strings was noticed ("help", "info", "ver", "logout", etc.) that resemble commands for a command shell. Studying the pointers to these strings led to the discovery of code that invokes functions to process commands, resembling a login interface and command shell. It was also found that a command "login" is provided to activate the shell, into which the password "#0000" must be entered. void shell_run_command(char* command_input) { if (shell_login_state == 0) { if (shell_compare_command(command_input, "login") == 0) { shell_ask_passwd(); // prints "passwd? " shell_login_state = 1; } } else if (shell_login_state == 1) { if (shell_compare_command(command_input, "#0000") == 0) { shell_login_ok(); // prints "login OK" shell_login_state = 2; } else { shell_print("Passwd Error\r"); shell_login_state = 0; } } else { // actually run the command } }
Further examination of the firmware showed that commands are processed in packets, which always start with the same 8 bytes of data and end with the code 0xf7. Since external interaction with the synthesizer is carried out only via MIDI, and the MIDI specification includes a special service message type called SysEx, it was assumed that it could be used for command transmission. This hypothesis was supported by the fact that SysEx messages and packets parsed by the shell began with the code 0xf0, followed by the manufacturer ID 0x43 (Yamaha).
To test the hypothesis, a Python script was written that translated input data into MIDI protocol packets. The method worked: login passwd? #0000 login OK > help logout help ? info ver stack perf-on perf-off perf-disp d dp d xxxxx d/s xxxxx m ADDRESS DATA m/b ADDRESS DATA m/w ADDRESS DATA m/l ADDRESS DATA > info DevelopName PSR-E433 DevelopNumber #3341 Main DevelopNumber #3341 Make data & time MAY 16 2012 19:00:57 J/E Select English >
In the prompt displayed when sending the command 'help', among other things, there were commands for modifying memory content. With these commands, it was possible to load arbitrary code into memory and transfer control to it by modifying the pointer in the stack used for returning after command processing. As an experiment, a simple application written in assembler, which displayed the string 'HeloWrld' on an 8-character LCD display, was placed in an unused area of memory. The program was formatted as a standard MIDI file, which was sufficient to send to the device.
After that, work began on studying the features of graphic output to the LCD display, culminating in the preparation of code that displayed arbitrary pixel content in the character area, synchronized with the playback of the video Bad Apple on an external device (a video demonstration).
Source: opennet.ru
