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.
Finally setup the github builder and now there's pre-release lorapipe firmware available for download!
We're building 79 different variants so testing on your favorite LoRa devices is highly encouraged!
By the way lorapipe is now called MeshTNC!
We recently noticed we had a naming conflict with an older project so we renamed ours.
MeshTNC is the new name we settled on and both the old and the new project link below should get you to the right place ππΏ
https://github.com/datapartyjs/MeshTNC
#MeshTNC #lorapipe #meshtastic #meshcore #amateurradio #offgrid #embedded #lora
@bernerd @nullagent the novel aspect that you're probably missing is that lorapipe has much wider hardware support than rnode. after looking at RNode and Reticulum again, I noticed that Reticulum can work over any KISS TNC, and that's just what I've provided, but to almost all hardware that is supported by Meshcore. This opens up possibilities for Reticulum as well.
As far as I can tell, lorapipe has support for every feature that RNode does at this point, but with wider hardware support. If you ask me, the code quality of lorapipe is also better. Take the KISS parsing support for instance:
lorapipe: https://github.com/datapartyjs/lorapipe/blob/main/src/helpers/CommonCLI.cpp#L421
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 @nullagent in my local hacker/activist community, we are working really hard to get people to ditch Meshtastic in favor of Reticulum, including building out our own local mesh network with it. To anyone that has been sold on the promises of Meshtastic, I'd definitely recommend you do the same!
The security/encryption of Reticulum is far superior, and the feature set is far more complete (it can be used for text, voice calls, hosting websites, TCP/IP tunneling, really anything), it can interoperate on way more radio protocols than just LoRa (including many non-radio protocols), and the development team seems far more committed to FOSS and anti-corporate ideals.
It also doesnt use flood-routing, unlike Meshtastic, so the network gets significantly more efficient as nodes are added, rather than getting bogged down the way Meshtastic does.
Thank you for putting this info out there, it's very refreshing when so many out there are parroting Meshtastic's marketing materials on its security while simultaneously advocating its usage in high-risk environments like protests.
@nullagent so just out of curiosity, what's the reasoning behind posting vulnerabilities like this publicly and not doing a responsible/coordinated vulnerability disclosure? After the blog post they made, it was clear you had their attention already.
Just seems a bit hostile towards the users to release such things publicly before allowing for a patch to be made available.
Appreciate your work otherwise. The Meshtastic community has been begging for more eyes on it from security researchers to help harden things up.
This software, meshtastic, simply does not deliver really any of the security people expect. This is due to fundamental architectural flaws around MAC address as the root of trust.
At some point users MUST know these issues exist and to what extent.
Finally, the blog from MT indicated that they are NOT taking this architectural deficiency seriously and continue to be evasive.
Ffs they attempted to "patch" it using copilot which just introduced more sec regressions.
Lastly. This architectural flaw is a TOP notch teaching moment.
I hope people pickup the defcon 33 firmware, flash some nodes and play with the PKI posion and MITM attacks themselves.
Read the code from both sides and learn why this is so flawed.
There really is no better lab material for developers and cyber-security curious people.
My primary focus is that this is an extremely interesting and educational for developers to learn from.
this looks to me to be a time to design a 2.0 MT protocol.
They need to tie the mac address to the public/private key pair.
They also need to actually sign things.
They need to at least sign the node advertisements that contain the full public key.
Lastly the app needs WAAY better UX that's very similar to SSL UX flow. Give users the info to verify or trust a new key. They should never automagically replace keys like this.
So far most of my early complaints with meshcore have reduced or been significantly addressed by the core devs.
MC is also far ahead on basic security and the protocol is FAR more efficient with airtime (it's far more usable than MT).
That being said MC is less than a year old still a ton of basic dev work to do so if you check back in some months i think it will have a lot more figured out
@Willow I love the OpenModem you mentioned looks sick! My ham friends were just teaching me about TNCs lately. We realized there's a need for a LoRa KISS-TNC to take pressure off of MT/MC for ppl who want to do more ham like things.
We haven't finished the TNC feature yet but the audio tnc made me think of it
nullagent
Bernhard
Dan
CountingKyles
Shawn Wilsher
Christian Horn
That first spark π³οΈββ§οΈπ₯·π΄π₯
eyes
mirth
adingbatponder 
πΎ
Boko
Alex
Willow 
ι£ζ³