Hey there,
I still own and use one of the old NS-Atmosphere injectors with the inbuilt RCM-jig. It still holds up very well for booting on AutoRCM. Unfortunately, with the company gone, the dynamically linked programing app is a weak point. I thought I'd be fun to investigate, if the commands issued by the app could be extracted and put into something more simple.
Assumptions made:
- There is a re-programmable flash chip in the injector
- Both the program-code and the injector may live on that chip
- The controller runs a serial usb-gadget to communicate when in flash-mode
- the app uses it to handshake with the injector, erase the payload part of the memory, write the bin to it, then reads it back to compare
I now had to options:
1) Analyzing the app
I chose the Linux executable to look at. While it surprisingly does come with debug-symbols, comments and any custom function names are of course gone. I tried navigating from the main function through the gtk-structures to hopefully find some leftover abstractions for running the flashing-process. I don't have much experience with disassembly though, so I quickly got lost.
2) Analyzing the communications
The only snag here was, that the app filters for '/dev/ttyACM*' and '/dev/ttyS*', not sure why the second would ever be used. After creating a pipe between the injector on ACM0 and the app on a virtual ACM1, sniffing the messages wasn't difficult.
I made two recordings, the first one had me only select the interface in the app, to have it report being connected to the injector. For the second one I attempted to flash Hekate 6.2.1 to it, I got as far as the writing step, but the delay from the recording seemed to timeout the app every time I tried.
The handshake starts relatively simple. 'N#' appears to just be a noop or ping command, with the acknowledgement coming back.
'V#' then seems to request version info. The controller on the other side identifies itself as SparkFun electronics model XYZ firmware version 1.1 made in 2015.
The programmer then seems to set a couple addresses and potentially writes a small bit of data. Not sure what this is for though.
I've attached both logs (with < being the app, and > being the injector). Is there anything obvious I've missed so far?
Thanks
I still own and use one of the old NS-Atmosphere injectors with the inbuilt RCM-jig. It still holds up very well for booting on AutoRCM. Unfortunately, with the company gone, the dynamically linked programing app is a weak point. I thought I'd be fun to investigate, if the commands issued by the app could be extracted and put into something more simple.
Assumptions made:
- There is a re-programmable flash chip in the injector
- Both the program-code and the injector may live on that chip
- The controller runs a serial usb-gadget to communicate when in flash-mode
- the app uses it to handshake with the injector, erase the payload part of the memory, write the bin to it, then reads it back to compare
I now had to options:
1) Analyzing the app
I chose the Linux executable to look at. While it surprisingly does come with debug-symbols, comments and any custom function names are of course gone. I tried navigating from the main function through the gtk-structures to hopefully find some leftover abstractions for running the flashing-process. I don't have much experience with disassembly though, so I quickly got lost.
2) Analyzing the communications
The only snag here was, that the app filters for '/dev/ttyACM*' and '/dev/ttyS*', not sure why the second would ever be used. After creating a pipe between the injector on ACM0 and the app on a virtual ACM1, sniffing the messages wasn't difficult.
I made two recordings, the first one had me only select the interface in the app, to have it report being connected to the injector. For the second one I attempted to flash Hekate 6.2.1 to it, I got as far as the writing step, but the delay from the recording seemed to timeout the app every time I tried.
The handshake starts relatively simple. 'N#' appears to just be a noop or ping command, with the acknowledgement coming back.
'V#' then seems to request version info. The controller on the other side identifies itself as SparkFun electronics model XYZ firmware version 1.1 made in 2015.
The programmer then seems to set a couple addresses and potentially writes a small bit of data. Not sure what this is for though.
I've attached both logs (with < being the app, and > being the injector). Is there anything obvious I've missed so far?
Thanks







