I've been busy as hell this past week.
A lot of people have been asking hard questions about the security of LoRa systems when they hear about mesh radios.
I'm not one to trust the marketing so I and several friends put together two new LoRa tools to help us audit the security claims of LoRa mesh systems!
🤘🏿 📡 ✨
#radio #cybersecurity #privacy #meshtastic #lorapipe #meshmarauder #lora #mesh
The first new tool is lorapipe, a firmware that runs on most consumer LoRa radios.
We've tested it a ton on ESP32-S3 based Xiao Wio boards.
This turns your lora radio into extremely minimal serial device that sends and receives packets in a dirt simple CSV format.
The radio can be tuned on the fly to switch between meshcore, meshtastic and LoRaWAN sync words and frequencies.
And because all the lorapipe firmware is doing is sending and receiving packets it means you can handle the encoding and decoding on a different device.
We tried to keep some of the dispatch behavior in lorapipe so that the firmware will automatically wait for gaps in traffic to find a good time to transmit.
It's pretty damn zippy . . .
Which brings me to part two, MeshMarauder.
An open source tool demonstrating proof-of-concept exploits against the DEFCON 33 Meshtastic firmware.
MeshMarauder will demostrate:
- Tracking user activity on any mesh regardless of encryption usage
- Hijack all meshtastic user profile metadata
- Change any users public key
- Send messages as any user in channel chats that appear authentic
- MITM direct messages
One of the exploits demonstrated is PKI poisoning, this is where we listen for a complete user profile and only change the public key to one we control.
In the case of mesh marauder we also add a little 🥷to the user name so people can see something is wrong.
If they never have seen this user before they will appear as a green contact.
If this is a contact they already knew the meshtastic app provides a warning but appears to replace the original key without user input.
The core issue to the above PKI poisoning attack is that NO core parts of meshtastics protocol is signed.
The user profile transmits the public key and there is no way to verify any of the information in it was even sent by that included public key 🙄
Nothing is signed and simply setting someone else's MAC address in the unencrypted header makes you that user.
The scale of meshtastics avoidance of building security into the design is pretty epic.
It allows for the formation of an entire mesh just for MITMing it.
This ONE liner here in the PKI attack means that once a node gets poisoned the key we created is based on the MAC so -anyone- who knows your MAC can read your MITM'd traffic.
When attackers run mesh marauder against the DEFCON 33 firmware they are all working together. Anyone in range can read the MITM'd DMs.
https://github.com/datapartyjs/meshmarauder/blob/channel-chat/src/lorapipe-raw-packet.mjs#L191-L193
So when it's this easy to get a MITM going things like making posts in public chats as anyone you want feels kinda low key.
But I do hope that extended warranty works out, everyone seems pretty concerned about them.
There's been a ton of bad advice for the privacy conscious and in particular for activist to use meshtastic.
I think that's very bad advice, because meshtastic is in no way architected to meet modern security expectations.
I hope this provides the proof of the dangerously lacking state of security on meshtastic today and some tools to verify if it ever improves.
Expect a more detailed blog post of all the exploits and findings soon.
Please consider donating, I'm housing insecure and going through a ton of costly bullshit right now. Wish I could make more tools and content.
Anything helps.
A few notes on the meshtastic disclosures:
1. I'm an amateur cybersecurity researcher. I've never done this professionally
2. I believe every single exploit we demo'd was previously documented in meshtastics bug tracker 1yr+ ago and were closed by the MT devs and largely ignored for a year.
3. When I began trying MT in 2024 the devs shutdown convos asking for security fixes saying people should use other comms tools if they wanted security. Rather than address fixable security bugs.
As I began reading the code and watching the discord conversations around meshtastic security I began to realize this team simply did not value security design and were rejecting all feedback short of full blown demos of these WELL documented security lapses.
I supported a friend with research who tried for months to get through to the meshtastic devs via discord (bc the github issues were being closed) and frankly the MT team were egotistical, rude and completely disinterested in security.
By January of this year I had run out of personal interest and free resources to devote to the project of meshtastic given the lack of security focus I'd seen in the prior six 6 months.
I wrote a final writeup on my meshtastic experiences and wrote a complete listing of the security issues I and others had already informed meshtastic of at that time.
My last post on the topic fully outlined the PKI poisoning we demo'd a DEFCon's CTF back in January of 2025.
Finally I suspect that IF meshtastic ever does fix their routing algo they will suffer from MITM exploits due to issues around #1, #6, #8, and #9. Bc when you have MAC as the root of trust I can respond to your MAC and poison the routing table. There might even by a solid security downgrade attack here too bc they have backwards compatibility for insecure DMs. So once I clone your MAC I can also downgrade security and ppl are trained to accept downgrades. #meshtastic #cybersecurity #mitm
So I'm not sure how to say it in a more concise way but YES meshtastic direct messages are at risk of MITM (man-in-the-middle) if your public key can be replaced by an attacker who spoofs the PKI.
Due to the way DMs and adverts work I believe this risk likely exists for any device on meshtastic regardless of whether they are on public channels or not.
This segment of meshtastic's DEFCON post are sadly not correct.
I can't tell you why how exactly the firmware and phone app work but I can tell you that if you are near someone PKI spoofing it absolutely does replace the users private key on BOTH the app and the firmware.
The only pub keys that are pinned are your favorites list.
It doesn't matter what -type- of AES is used after the public key is replaced you're already MITMd.
So to hopefully make it more clear, I wrote a CLI tool which can recover the decryption parameters for DM conversations.
It basically does everything but the final AES-CCM decryption. Turns out there's something funky with the meshtastic AES-CCM implementation and I can't seem to fully decrypt using an openssl based library.
This does not mean DMs are any safer, just that I haven't taken the time to crosscompile the MT/arduino AES routines to x86 yet.
https://github.com/datapartyjs/meshmarauder/blob/main/bin/mitm-dm
Over the weekend @meph added some mind blowing new features to lorapipe.
- APRS over LoRa
- Ethernet over LoRa
https://social.treehouse.systems/@meph/115365077448221139
#hamraadio #radio #lora #meshcore #meshtastic #lorapipe #aprs #ax25 #kiss #tnc #packetradio #networking #cybersecurity #offgrid
Attached: 1 image what if I told you that you could do Ethernet over LoRA?
Now that lorapipe has KISS-TNC protocol support for sending and recieving LoRa packets, it means that basically all sorts of ham radio and Linux tooling designed to talk to KISS modems suddenly work over LoRa.
For HAM radio nerds, this means things like APRS -just- work. Follow the instructions in the documentation to get started.
I suspect HAMs can bridge APRS across spectrums to ISM 433/868/915Mhz LoRa now using lorapipe. 😎
https://github.com/datapartyjs/lorapipe?tab=readme-ov-file#aprs-over-lora
Because this KISS-TNC stuff is pretty old, it has really good support on modern Linux.
So we're actually able to setup lorapipe on two different linux boxes and form an ethernet network over LoRa!
The current rev has some MTU limits we can fix, we can also eak out probably another 2x more bandwidth too.
But as is I was able to ping, mosh and ssh over my ethernet-LoRa network between Linux computers!
https://github.com/datapartyjs/lorapipe?tab=readme-ov-file#ethernet-over-lora
All of @meph 's work on #lorapipe is under MIT license.
Features like APRS over LoRa and Ethernet over LoRa serve some interesting niches we're not likely to monetize.
More than anything we want lorapipe to be a rapid prototyping tool for LoRa solutions. It's key for this to be as free and open as we can make it and I hope these features demonstrate our direction.
We'd appreciate donations towards the effort so we can knockout lorapipe v1.
It's true, other technology teams have built similar solutions. lorapipe draws heavily from meshcore's code base and is an independent implementation of KISS separate from rnode's. (Showing this is a cool interop standard)
I for one think my team has communicated a very different set of ideals and values than the teams behind other mesh software.
Pretty sure my followers don't generally wanna support mesh devs using this iconography 👇🏿
nullagent
Bernhard
CountingKyles