MeshCore LoRa node app for Flipper Zero (RFM95W/SX127x)
Find a file
isac.selea 7bbf924c01 Add MeshCore LoRa app for Flipper Zero
Standalone Flipper Zero FAP that speaks the MeshCore over-the-air LoRa
protocol directly (RFM95W/SX127x add-on), analogous to flipper-meshtastic
but for MeshCore instead of Meshtastic. Implements packet framing, Ed25519
identity/signing, X25519 ECDH, AES-128 + HMAC-SHA256 encrypt-then-MAC,
public channel chat, direct messages, advert broadcast/parsing, and
flood relay, built against upstream MeshCore source (ripplebiz/MeshCore).

Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_012kF1YGpsqZHtnz3ayXYicn
2026-09-01 15:05:05 +02:00
src Add MeshCore LoRa app for Flipper Zero 2026-09-01 15:05:05 +02:00
application.fam Add MeshCore LoRa app for Flipper Zero 2026-09-01 15:05:05 +02:00
icon.png Add MeshCore LoRa app for Flipper Zero 2026-09-01 15:05:05 +02:00
README.md Add MeshCore LoRa app for Flipper Zero 2026-09-01 15:05:05 +02:00
THIRD_PARTY_NOTICES.md Add MeshCore LoRa app for Flipper Zero 2026-09-01 15:05:05 +02:00

flipper-meshcore

An unofficial, community Flipper Zero app that turns the Flipper (plus a cheap RFM95W/SX127x LoRa add-on) into a standalone MeshCore node — same idea as flipper-meshtastic, but speaking the MeshCore over-the-air protocol instead of Meshtastic.

This is a from-scratch reimplementation of MeshCore's radio-level packet format directly on the Flipper (no separate ESP32/nRF52 "companion" device required) — the architecture the flipper-meshtastic project uses, applied to a different mesh protocol.

Hardware

Same wiring convention as flipper-meshtastic and most Flipper LoRa add-ons (HC-12/RFM95 GPIO shields etc):

Flipper GPIO pin Signal
2 (A7) MOSI
3 (A6) MISO
4 (A4) CS / NSS
5 (B3) SCK
6 (B2) DIO0 / G0
7 (C3) EN

Any RFM95W / SX1276 / SX1278 breakout wired this way should work. Set the correct region frequency in Settings before transmitting.

Features

  • Standalone LoRa TX/RX using MeshCore's actual wire format — no phone, no ESP32/nRF52 "T1000/Heltec/RAK" companion node needed.
  • Public Chat — send/receive on MeshCore's well-known default "Public" channel (interoperates with real MeshCore nodes/apps out of the box).
  • Contacts — passively builds a contact list from received ADVERT packets (name, signal, Ed25519 signature verified or not).
  • Direct Messages — end-to-end encrypted 1:1 messages to any contact, using Ed25519→X25519 ECDH + AES-128 + HMAC-SHA256, exactly as upstream MeshCore does it.
  • Broadcast Advert — announce your node's name/identity to the mesh.
  • Auto-relay — optionally rebroadcasts other nodes' flood packets (with random jitter + a CAD-based polite/no-collision check before every transmit), so your Flipper also helps extend the mesh, not just use it.
  • Persistent Ed25519 identity (or import an existing MeshCore private key) and settings, stored on the SD card.

Protocol implementation notes

Built directly from the upstream MeshCore source (ripplebiz/MeshCore: Packet.h/.cpp, Identity.h/.cpp, Utils.h/.cpp, Mesh.cpp, helpers/BaseChatMesh.cpp, helpers/AdvertDataHelpers.*), verified byte-for-byte against that source as of September 2026:

  • Packet wire format, header bit-packing, ADVERT payload layout + Ed25519 signing, TXT_MSG/GRP_TXT envelope layout, and the AES-128-ECB + HMAC-SHA256(truncated to 2 bytes) "encrypt-then-MAC" scheme all match upstream.
  • The default Public channel PSK (8b3387e9c5cdea6ac9e5edbaa115cd72) is the real, publicly documented default MeshCore ships with.
  • Crypto is vendored, unmodified, from well-known public-domain/permissive libraries: orlp/ed25519 (Ed25519 + X25519 key exchange), kokke/tiny-AES-c (AES-128), and Brad Conte's public-domain SHA-256 (github.com/B-Con/crypto-algorithms).

Known limitations (not implemented)

  • Source-routed DIRECT messages / return-path tracking are not implemented. Every outgoing packet uses flood routing. This works fine on real MeshCore networks (it's exactly how a first message to a new contact is sent), it's just less efficient than a node that has learned a direct path.
  • Delivery ACKs are not decoded — sent messages don't show a delivered/failed status.
  • Multi-hop path/TRACE/REQ-RESPONSE/room-server/repeater-login flows are not decoded (packets of those types are still correctly relayed if Auto-Relay is on, just not acted on locally).
  • Only the 1-byte path-hash "V1" packet encoding is supported (this is what current MeshCore firmware uses).
  • Only one group channel (Public) at a time.
  • Contacts are not persisted across reboots (rebuilt from adverts each session).
  • The default LoRa sync word (0x12) is a best-effort value — MeshCore doesn't publish this as a stable protocol constant the way Meshtastic does. If you don't see any traffic, double check your MeshCore node's radio config and adjust the sync word to match if needed.

None of this is a correctness risk for what is implemented — the crypto/signing/envelope format was checked directly against upstream source, not guessed. It just means this client is intentionally simpler than full MeshCore firmware, which is a much larger C++ codebase.

Building

Requires the Flipper Zero toolchain (ufbt or fbt from a firmware checkout):

ufbt          # build the .fap
ufbt launch   # build + install + run on a connected Flipper

This has been written carefully against the documented Flipper furi/gui APIs and the SX127x register map, but has not been build- or hardware-tested in this environment (no Flipper toolchain or device available here) — please report build errors/issues.

Disclaimer

Unofficial, community project. Not affiliated with the MeshCore project or Flipper Devices. Check your local regulations for LoRa frequency/power limits before transmitting.