Hacking Hardware Project Reverse engineering the NS-Atmosphere injector

  • Thread starter Thread starter Nicro
  • Start date Start date
  • Views Views 1,181
  • Replies Replies 1

Nicro

Member
Newcomer
Joined
Jun 5, 2017
Messages
23
Reaction score
7
Trophies
0
Age
29
Location
The Void
XP
172
Country
Germany
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
 

Attachments

I had a similar injector with my unpatched v1, it's not the same white ns-atmosphere injector you have, but a black rcmloader clone. Works very well and battery lasts a very long time (only charged it once before I installed an internal payload injector and sold my v1). Internally they should be the same thing (SAMD21 mcu with a 16MB spi flash chip for payload storage, plus a rechargeable battery).

imo the simpler option is to flash mattytrog's fusee suite to it, which chain loads hekate on sd card. The payload being injected is very small and fits on SAMD21's internal flash memory. It's made for internal payload injector chips like Trinket M0, RCMX86 so the console can enter rcm mode automatically (by pulling down vol and joycon pins).

Theoretically it should work on all SAMD21 based mcus, just need to flash the bootloader with swd interface.
 

Site & Scene News

Popular threads in this forum