Armachat - standalone offgrid messenger

Development Hardware
1

Hi everybody,

I am working on this standalone messenger, is based on SAMD21+RFM95 with QWERTY kayboard
and small tft display

Armachat project page

I have now only simple device to device communication

Thinking about meshtastic compatibility but it look like very complex device + android app.

Supporters are welcome http://patreon.com/bobricius

11 Likes
2

Hi,
I already stumbled over your projects/youtube videos and was really impressed by your PCBs. The devices look really retro, which I think is very nice.

Only the fancy interface is a little bit too much for my taste. :wink:

When I was was a child, I dreamed of such devices to text with my friends in our small village. Would be great if I can give such devices to my childs (some time I have some^^).

2 Likes
3

I remember this project when I was doing research and it looked very promising. Still has potential for multiple applications where there is no smartphone involved. Would be good to find a way to protect your messages to have some privacy.

2 Likes
4

As long as there is enough RAM I think running Metastatic would be relativity easy.

This could be an excellent stand alone device without Bluetooth or the Android app.

2 Likes
5

Yep. I havenā€™t looked but if it is esp32 based I suspect it would be a fairly straightforward effort (a couple of days?). At least initially - then youā€™d want to add a local message composition UI to take advantage of that nice keyboard.

2 Likes
6

It is based on SAMD21 I am not good programmer, I read your protocol and everything here is super high level. Maybe I will succeed with only forward messages over Meshtastic network between 2 armachat units, or I just use your addressing scheme and radio settings.

1 Like
7

I configured radio, rewritten addressing.
now I receiving encrypted meshtastic packet, I can decode header :wink:
Also I can send packet to meshtastic network, nodes forward empty package
with message I receive debug ā€œInvalid protobufs in received mesh packet!ā€
protobufs are far away from may skils, also encryption, maybe if meshtastic can forward raw packet
etc some flag in header. With this I can use meshtastic network as relay between armachats.

is somewhere described FLAGS bytes in header? I received etc FLAGS: 15:fd:45:03

5 Likes
8

re: FLAGS encoding documentation.
Sort of ;-). Here https://github.com/meshtastic/Meshtastic-device/blob/master/docs/software/mesh-alg.md and https://github.com/meshtastic/Meshtastic-device/blob/915427c9649364f03ca18c281f84998bfe0f2afe/src/mesh/RadioInterface.h#L14

Though Iā€™m not surprised that your packet got dropped (because yeah - it didnā€™t like the encryption of the payload). Alas, currently meshtastic assumes that (even for routing other packets) that the payload is protobufs. I wouldnā€™t be too scared of protobufs because the tools to convert proto files into C++ code are pretty painless (see bin/regen-protos.sh for how we do it). Also - the generated code is tiny.

Iā€™m a huge fan of protobufs because they are a) pretty small on the wire, b) nicely self documenting, c) cross platform (which was important for meshtastic talking to outside devices/APIs/apps). For instance, hereā€™s how the payload portion of a meshtastic message is representated:

That said: It wouldnā€™t be too hard for me to add a ā€œsend this opaque blobā€ flag like you describe. Would you mind putting a bug in meshtastic-device? Though there are some higher priority 1.1 features ahead of it, so it will be a couple of months.

1 Like
9

Thanks for links, I am watching to your sources every day, your points are very helpful.
Now are packets encrypted or they are only protobufs? one packet is is entire text message or is divided to more packets ?
I created github issue for this feature https://github.com/meshtastic/Meshtastic-device/issues/383

Thanks for help.

10

the headers are never encrypted, but the payloads are encrypted when sent over the wire (these payloads correspond to ā€œSubPacketā€ in the protobuf documentation).

And entire packet corresponds to ā€œMeshPacketā€ in the protobuf docs, but thatā€™s the one place we donā€™t use protobufs when going over LoRa (though we do when sending them over bluetooth, serial or wifi). Because we want the radio chips do do their own filtering based on addresses (eventually), we send all of those packet headers as the 16 bytes described in mesh-alg.md.

2 Likes
11

If I good understandā€¦
I receive header 16bytes (This easy and I have encoded)
next is payload encrypted with AES256 ā€¦ where is encryption key?
key is fixed or changing?
After encryption I need received part encode do protobufs OK?

12

one more stupid question where is etc ā€œaes_wrap.hā€ or where is crypto library?

13

Hey, I just saw your device.I would really consider buying some if they can handle the Meshtastic protocol.
It would be verry cool if you could try to make one dedicated for the meshtastic protocol by using a compatible chip and good amounts of ram.I donā€™t know how difficult this is but I would love to see an ARMA device with GPS and LORA independent from the phone.Thank you

4 Likes
14

I have no programing skils for displaying meshtastic messages, maybe in future I can trasmitt messages in meshtastic network if autor implement raw forwarding. Also I want keep simplicity with using SAM21 as main MCU, which mave some advantages as native usb with simple drag&drop update to MSD device and low power consumption. Complete armachat with full bright display consume 60mA and with low bright 30mA. (30mA display, 10mA lora module, 20mA MCU)

2 Likes
15

I think I can help with those questions:

  • the encryption key is channel specific and shared as part of the channel ā€˜URLā€™.
  • the default channel key is well known (therefore not particularly secure) it is
    /// 16 bytes of random PSK for our _public_ default channel that all devices power up on (AES128)
    static const uint8_t defaultpsk[] = {0xd4, 0xf1, 0xbb, 0x3a, 0x20, 0x29, 0x07, 0x59,
                                         0xf0, 0xbc, 0xff, 0xab, 0xcf, 0x4e, 0x69, 0xbf};
  • The algorithm for the crypto is described here https://github.com/meshtastic/Meshtastic-device/blob/master/docs/software/crypto.md
  • aes_wrap.h comes in from the ESP32 toolchain. That toolchain gets fetched automatically into ~/.platformio when you do ā€œpio runā€. On the ESP32 processors I use their hardware AES implementation, on the NRF52 processors I use a ARM library that implements AES-CTR.
  • The keys for a channel can be set with the python tool or the android app. If the key is 16 bytes long we use AES128, if 32 bytes long AES256. ** if zero bytes long ** we turn off encryption. This might be useful for you. I think "meshtastic --setchan psk ā€œā€ " should do this.

Oh yes, I forgot to record your request to support totally opaque payloads. Iā€™ll put that in the wiki to do soonish.

Does that help?

1 Like
16

Everything helps, THANKS
I am checking android app form all sides but I not found button for psk change, also no button for chat clear

17

Alas the Android app generates and installs auto generated random AES256 keys any time you make a new channel. If you want to turn off the enc currently the only way is the python cmd.

18

D:\PYTHON\Meshtastic-python-master\meshtastic>meshtastic.exe --device COM46 --setchan psk ā€œā€
Trigger powerFSM 9
Trigger powerFSM 11
Transition powerFSM transition=serial API, from=ON to=SERIAL
Shutdown BT: 237112 heap size
Connected to radio
Setting channel parameter psk to
Canā€™t set psk due to Cannot set ChannelSettings.psk to ā€˜ā€™: ā€˜ā€™ has type <class ā€˜strā€™>, but expected one of: (<class ā€˜bytesā€™>,)
Writing modified preferences to device

D:\PYTHON\Meshtastic-python-master\meshtastic>pause

I try everything

19

oh oops - I forgot, that field is a byte array, not a string. Iā€™ll fix tomorrow:

20

Armachat powered with stirling engine

8 Likes