freqy/protomolecule
3
1
Fork 0
Code Issues Pull Requests Releases Wiki Activity

Update 'NOTES-e.md'

Browse Source
This commit is contained in:
e 2022-08-18 02:55:12 +00:00
parent d0f96f9df8
commit 3f36dc03c8
1 changed files with 4 additions and 17 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

21
NOTES-e.md
View File

@ -1,23 +1,10 @@
# Notes
### by e
## Conceptual Attacks
After re-reading a lot of this, I will need to re-write my notes as a lot of the shit I wrote was wrong as hell.
#### De-Auth + DFU firmware push?
Two big takeaways that I still think we need 100% is rfcomm and l2ping capabilities. rfcomm may be able to be done through sockets in Golang by default now??? idk, will have to look into this. after looking at l2ping.c, it should be easyish in go, but I am no coder.
Since the layout of the dfu init packet is as follows:
I do believe this may be the biggest vector of attack on nRF devices though - obviously.
Device type: A 2-byte value specified by the developer that identifies the device type, for example Heart Rate Belt.
Device revision: A 2-byte value that can be used to restrict the update to be accepted only on devices with a defined revision number.
Application version: A 4-byte value identifying the version of the application that is being transferred. This value can be used to allow only software upgrades and prevent downgrades. No example code is provided for this feature.
Supported SoftDevices: A list of 2-byte values identifying the SoftDevices that are compatible with the application, for example, S132 v2.0.0.
Checksum: A 2-byte CRC-16-CCITT for the image to transfer.
it seems that the only true thing we will need to work hard for is checksum. Which I believe we can pull, but I will need to look further into this. I feel like we can glean most other information via advertisement packets sent via the devices themselves.
If we can craft packets based on information gathered from both a CRC pull(??) and scraping the advertisement packets + possibly active connection enumeration, we can then use something like l2ping or rfcomm to deauth the device trying to receive the device and send it the crafted init packet, followed by the malicious payload, be it firmware or whatever.
I feel like l2ping will probably be someone easy to replicate in go, but rfcomm may give us some issues, although I am pretty sure we can actively use RMCOMM through btproto on unix.Socket /shrug, I don't know Golang, but it looks like we can, I think at that point we can just craft outright from that.
To be continued when I have another brainblast...
The more I read into this, the more I will update this, as well as clean it up. ADHD brain took over a bit