Con speakers fear the Nerf gun. Overrun your talk time at your peril; Steve will shoot your arse with extreme prejudice until you STFU. We had to find a way to pwn the gun and shoot him back.
That’s when we found the Nerf Terrascout: a remote tank gun controlled over 2.4GHz, with a video feed to the remote, complete with crosshairs.
At first, we thought this would be a trivial job: figure out the RF and take control. It turned in to a mammoth hardware, firmware and RF reversing project.
This puppy is so over-specced it would drive you to tears.
The talk will cover the fails, hair loss and eventual success. There won’t be any smart dildos in it, though some of the techniques used are equally suited to teledildonics exploitation, if that’s your thing.
Reversing RF in a high frequency environment using SDRs is challenging. We’ll discuss how we worked around these issues using hardware reversing skills.
We had to import hardware from China for this project, which we could then programme ourselves using SPI, impersonate the legitimate controller and ‘jack the tank gun.
This talk will of course include a live demonstration of hijacking the tank gun and (possibly) shooting Steve.
2. Why the hell?
Interesting technology
Unusual protocols in use
Shows basics of reverse engineering and
hardware hacking
IT’S A FRIGGING NERF TANK!!!!
3.
4.
5. We could only get one device
No destructive testing
Could we reverse it from the air?
We needed a plan…
Initial work – RF investigation
10. Taking it Apart
We disassembled the device and assessed the hardware components
And we found….
External Memory A Blob on Board
11. The Firmware
Analysis of the firmware was not required for reverse engineering
Used the full 32-bit ARM instruction
Can be easily identified by looking at a hexdump
15. Identifying Thumb
All operations are 16-bit aligned
PUSH instructions use 0xB5 as second byte
POP instructions use 0xBD as second byte
POP and PUSH instructions will likely be found back-to-back
BL instructions start with 0xFF 0xF7
BXLR instructions defined as 0x70 0x47
These are helpful for quickly determining whether a block of code is likely to be Thumb
21. The Module – SPI Communication
Five sets of commands found:
• Register setting commands from 0x00 – 0x3f
• Register reading commands from 0x00 – 0x3f, with 0x40 always set
• One byte commands where 0x80 is always set
• Register read and write commands at 0x45 and 0x05
Analysing these commands allowed us to present the data in a readable format
22. Analysing The Data - Receiving
Filtering read commands allowed us to view all received data
This showed an incrementing value at the start of each frame which reset, allowing for us to
see the start and end of data payloads
23. Analysing The Data – Receiving
Frames can be stitched together, allowing for analysis of each payload in turn
The header of the payload should be assessed first, as this will contain the most relevant
data
24. Analysing Data Without a Discernible Header
Looks like seemingly random data
This could mean it is encrypted or compressed
A compressed payload will have some form of non-random data
26. Analysing Data Without a Discernible Header
If this data was encrypted, it would require assessment of the firmware
Search firmware for information relevant to the packet, such as a standard size
Standard constants or tables used by encryption algorithms, such as AES Sboxes
Search in the binary for XOR instructions with a jump instruction to a previous point in
subroutine
27. Analysing The Data – Receiving
We found a header which looked like:
• A 32 bit value denoting the full size of the payload
• A 32-bit CRC for error checking
• A 32-bit value providing the number of blocks the payload was separated into
• And finally a JPEG header
28. Analysing The Data – Receiving
Now we have JPEG images to be to be viewed
Tiny: 240x180px resolution
A large number of the packets were found to be corrupted
31. Analysing The Data - Sending
Controller data was simpler and in one frame
Followed standard practice for controllers
• 8-bit values used for analogue controls, with the neutral value being 0x80
• Single bits being set and unset for buttons
A single byte checksum used for data integrity, consisting of a sum of all control values
32. Analysing The Data – Sending
The two analogue controls were the speed settings for the two tank treads
The tank crashed upon rapidly changing the speed of the wheels
Controls were only sent when requested by the tank
• every 22nd frame
• set a bit
33. Analysing The Data – Sending
0x80 was the neutral speed of the treads
0x30 was reverse
0xd0 was forward
0xff was TURBO
34.
35. Searching For The Module
Most common 2.4GHz transceiver manufacturers
iRangeX, contains four common transceivers:
• Texas Instruments CC2500
• Nordic Semiconductor NRF24L01
• Cypress CYRF6936
• Amiccom A7105
Searching the datasheets for these modules revealed that the A7105 was the closest match
36. Searching For The Module
Replaying SPI commands from the logic analyser was inconsistent
Transceiver in use was very likely to be a “similar” chip in the same series
Datasheets were not the most useful:
• copy-and-pasted
• few differences between them
Finding the appropriate transceiver would be difficult
37. Searching For The Module
A large number of the transceivers were found not to be accessible by the general public
Datasheets were hard to find
We ended up cheating stealing the module from the legitimate controller
38. Hijacking The Tank
Choice of a Raspberry Pi or an STM32 development board
Raspberry Pi was too inflexible
An ST NUCLEO-L496ZG development board was used
• Fast
• Precise timings
39. Hijacking The Tank
STM32 boards are extremely easily set up, with tools like the STM Cube allowing for precise
definitions of what each pin does
40. Hijacking The Tank
Programmed the board to:
• replay the initialisation SPI commands
• Send and receive the appropriate packets
Module starts in Half-Duplex SPI mode and has to be set to run in full duplex
Sent received images to the USB host and received controls back
Next step was through the browser…