- how to disassemble nano SwinSID b firmware -

Disassemble nano SwinSID firmware binary
Following lines explain the procedure to disassemble and debug the nano SwinSID firmware binary. In order to follow the steps described here, you will need Microchip Studio 7 and an ATmega debugger/programmer with the appropriate connection cables. A Microchip Studio 7 solution that allows editing and debugging the disassembled code of the "v24/5/2012" firmware version is available at the end of this page.

The procedure described here can be used to disassemble the different known nano SwinSID firmware versions.
Get and debug the assembly code
Microchip Studio 6 allowed to directly disassemble and debug .hex files, but this option was removed on Microchip Studio 7 which only allows to disassemble and debug .elf files. However, Microchip Studio 7 allows you to convert the .hex file to .elf and then create a project from it to disassemble and debug it. To generate the .elf from the .hex in Microchip Studio 7 go to "Tools> Device Programming" and there in "Tool" select "Simulator" and click on "Apply". Then in the "Production file" options, in "Save to ELF production file > Flash" indicate the .hex file to convert to .elf and then press "Save". After this, the .elf version of the original .hex file should be generated.

Use "Tools > Device Programming" options to convert .hex to .elf.

In the "Production file" section, in "Save to ELF production file > Flash" specify the .hex file to convert and then "Save".
Next step to get the assembly code of the generated .elf file and debug it, is to create a "Microchip Studio project for debugging". To create that project go to "File > Open > Open Object File For Debugging". In the "Select the Object File to Debug" text box specify the previously generated .elf file, and in the "Specify Project Name and path" options set the desired name and location for the new project. In the "Device Selection" list, select "ATmega88PA" and then finish.

Go to "File > Open > Open Object File For Debugging" to create a project to disassemble and debug the .elf file.

In the "Device Selection" list, select "ATmega88PA" and then finish.
Connect the computer to the nanoSwinDID unit through the debugger/programmer and then go to "Debug > Start debugging and break" to start debugging. If you haven't previously configured the debug tool, Microchip Studio will show a form in order you configure it. On that form specify the device you are going to use to debug (i.e. Atmel-ICE) and in "Interface" select "Debug wire".

If not configured, Microchip Studio will ask to configure the programming tool. Select your programmer and the debugWIRE interface.
To debug the microcontroller through the debugWIRE interface, the DWEN fuse must be enabled first. If it is not enabled when going to debug, the tool will ask us if we want it to be enabled. As debugWIRE interface uses reset line to debug the microcontroller, the reset pin of the nano swinSID must be disconnected from the board reset line. To disable debugWIRE mode to restore the microcontroller to normal conditions, start the application as if we were debugging through debugWIRE and with this running go to "Debug > Disable debugWIRE and close", then remove the power from the microcontroller and power it back on. After this, it should be possible to program the application using the conventional SPI interface again.
Next, save the project, and go back to the "Debug > Start debugging and break" option to start debugging. Once you start debugging, Microchip Studio will show the assembly code and will allow you to debug it step by step.

Microchip Studio will show the assembly code and will allow you to debug it step by step.
Reverse engineer and modify the assembly code
Despite the created project allows debugging step by step the disassembled code, it does not allow modifying it. To modify and debug the assembly code, a new clean Microchip Studio assembler project for the ATmega88PA has to be created and then paste on it the previously generated assembly code. ATmega88PA has a 8Kbyte flash, and since all AVR instructions are 16 or 32 bits wide, the flash is organized as 4K x 16bits ( 4Kword = 8Kbytes ), for that reason the flash content to copy to the new project goes from address 0x000 to address 0xFFF.
But that previously generated assembly code can not be directly pasted on the new project. It must be modified and adapted to the right assembly sintax first, other way it won't compile. Modifying and adapting that code consists of removing all useless information like source addresses, source line numbers, or useless comments ( I used Notepad++ for that purpose ) added by Microchip Studio.

In the "Device Selection" list, select "ATmega88PA" and then finish.
Another way to get the assembly code of the original .hex file is to use the avr-objdump disassembly tool of the ATmega toolchain ( other AVR/ATmega disassemblers can be used too ). To use "avr-objdump", in Microchip Studio go to "Tools > Command prompt" to open a command prompt window, from there navigate to the folder where the .hex file is, then type: "avr-objdump -D -z --disassemble-zeroes -m avr4 your_file.hex > your_file_dis.asm" ( avr-objdump -H to get all avr-objdump options ).
Once the syntax of the assembly code has been modified and adapted, it must be pasted into the main.asm file of the created "Microchip Studio assembly project." To start debugging, follow the same steps than with the previous "Microchip Studio project for debugging" project: specify the debugging tool, select the debugWIRE interface and then go to "Debug > Start debugging and break".

Paste the modified and adapted assembly code into the clean ATmega88PA assembler project.
At this point, the most difficult part of the disassembly process begins, and consists of trying to understand exactly what the different blocks of generated assembly code do. The disassembler interprets the binary codes in memory as series of bits that correspond to processor instructions ( with their "opcode", operators, memory accesses etc.) and translates them to their equivalent in assembly, but it is possible that these binary codes actually correspond to data blocks rather than instructions (i.e. the binary codes at the end of the SwinSID88_20120524.hex binary correspond to waveforms data not to instructions). Unless debug information is present in the binary, another difficulty is that the disassembler does not provide any kind of symbols information: it translates accesses to variables as accesses to memory addresses, and calls to subroutines to jump or branches to memory addresses. A hard reverse engineering work must be done.
Here you can download:
- Disassembled .asm file: the .asm file resulting from disassembling the binary of "v24/5/2012" firmware version ( this .asm file is already included in the provided Microchip Studio solution ).
- Microchip Studio solution: a Microchip Studio solution that allows compiling, debugging and modifying the .asm file resulting from disassembling the "v24/5/2012" firmware version.

These files are the result of applying the reverse engineering process described here and, despite I've tested them, it is possible that they contain errors. All files are provided "as is", without warranties or conditions of any kind, either express or implied, including, without limitation, any warranties or conditions of title, merchantability, fitness for a particular purpose. You are solely responsible for determining the appropriateness of using or redistributing the work and assume any risks associated with it.

... this page was last updated by Tolaemon on 12-2022 ...