inkChat

ESP-IDF project making 2 ESP32s talk to each other over ESPNOW, and to the users via serial.

This begun as a shrunk down version of my espnow-serial-idf project that has no GPIO support. Meaning you only need an ESP32, and that's it.

It has since progressed significantly, and meant to succeed it.

Boards are meant to be pair. They share an AES encryption key kept secret, and pair only with other using their MAC addresses.

Software Instructions

1. Clone source code
2. Change the receiver's MAC address in peerMac
3. Generate AES encryption key (openssl rand -hex 16), put it in
4. Set MAX_CHANNEL to your region's standard, to comply with regulations
5. Depending on your board, change main.c to either include "serial.h" or serial_usb.h"
6. Update CMakeLists.txt to include either "serial.c" or "serial_usb.c"
7. idf.py set-target (your chip)
8. idf.py build
9. idf.py flash -p (serial port of your board)
10. Use any serial program to interface (picocom/minicom/screen/putty)

Current Command List (0xCC)

Command	HEX Reply	Description
/	0xE0	Invalid Command: Returns an error on any unrecognized input.
/bf6f7113	0xE1	Version Check: Initiated on boot; not meant to be sent manually by the user.
/status	0xEA	Status Request: Prints out the remote board's current status.
/channel <number>	0xEB	Change Channel: Instructs both boards to switch to the desired Wi-Fi channel.
/encrypt	0xEC	Toggle Encryption: Instructs both boards to toggle AES encryption state.

When a command is sent (as a string), the remote board interprets it, and sends back a command response. With the first two bytes being 0xCC, 0xEx (allows for up to 16 total commands 0-F). Command responses can then optionally add additional data to their repsonse.

This system allows the boards to mutually agree on changes they make.

Say board A sends /encrypt via their terminal. Board B interprets this string, toggles their encrypt variable, sends back the response 0xCC,0xEC and an additonal byte indicating the encrypt state. Right after, board B sets their encryption status accordingly. Board A receives the command response, and thus set their encrypt variable and state accordingly.

Thus, if board B does not respond to /encrypt (maybe because it was offline), board A never makes the change.

One board can NEVER make a change to a crucial setting (encryption, channel) without the other agreeing and confirming.

On boot, the board waits for the user to press any character on the terminal. If it's the first time, it sends /bf6f7113 to board B, and initates a version check. Board B sends back it's version (defined in the source code at compile time), and board A check against it's version. If they match, it prints a green success message, if not, it warns the user in red. In both cases the MAC address of the board also gets printed.

WARNING, WARNING, WARNING

DO NOT use the default AES key provided, as it is public knowledge. Generate one with the provided instructions, and replace it in the source code of both boards. Keep that key secret.

I cannot gurantee the security of this project, do NOT use it for real communication where you are at risk, unless you have read, understand, and agree that the source code and idea are safe.

I take no responsibility for any misuse.

That being said, theoretically, if encryption is on, and you do use your own AES key, all traffic between your two boards is encrypted. I have attempted to sniff with wireshark and can confirm. This is, in theory a secure way of communication between 2 individuals.