I AM SO SIGMA !!!IOEUFOASDUFSDJIOF

1 files changed, 40 insertions, 99 deletions

diff --git a/README.md b/README.md
index f46df1a..34ef283 100644
--- a/README.md
+++ b/README.md
@@ -2,28 +2,19 @@
 
 ## What will you find here?
 - Research on how the Bodet Harmony PSA Protocol works
+- Checksum Generator for Harmony Packets
 - Tools to allow features to be used your Netsilon can't do
 - Research on replacing the Bodet Software Called SIGMA and the Time Server for it (I can't even take its name serious) and eventually links to the replacement software called BE-YOUR-OWN-SIGMA (if I achieve reverse engineering it to a certain decentish degree).
 
-**Important Disclaimer:** While the structural fields of the packets are mostly well understood, the checksum calculation remains quiet mysterious. Without correctly reproducing the checksum, generating functional packets yourself remains unreliable unless you copy known working ones, therefore this can only be used for repetitive actions with already learnt and working commands.
-
-## Sample Data Folder :
-Contains valid payloads that get accepted by the system if sent to multicast address 239.192.55.2
-stop-payloads.txt
-
 ## Research folder contains active stuff im working on right now.
 If you want to help out with figuring things out this is where to look I'd say
 
-
-Please IF YOU KNOW HOW TO MAKE THE CHECKSUMS WORK PROPERLY OR KNOW MORE THAN ME PLEASE HELP ME!!!
-
 ## General info
 
-
 ### Common Hardware Details (Seemingly for all but Master Clock)
 
 - **Platform**: Freescale MQX RTOS
-- **MCU**: Most likely a Freescale/NXP Cortex-M4 (based on MQX + strings + 2017 build date)
+- **MCU**: Some Freescale/NXP Cortex-M4
 - **Networking Stack**: LwIP
 - **Storage**: MFS-style filesystem, Speakers and Sound Generating Components have an SD Card
 - **Web Interface**: Embedded HTTP server (`Server: MQX HTTP - Freescale Embedded Web Server`)
@@ -48,25 +39,7 @@ Based on repeated appearances in both firmware strings :
 | `public` | `jkl1vi5erjnfh`      |
 | `public` | `aSe2=9Z8gOi37*`     |
 
-### Checksum Observations
-
-- Found log strings that explicitly reference checksum calculation and failures:
-`CHK = %04x (%d)`
-`CHK BAD !!! %d`
-- Could however also be just for firmware integrity maybe? Rather unlikely though.
-
-Also of note : 
-```
-F_traitement_trame_PROTOCOLE
-F_traitement_trame_vie_repeteur
-REP STREAM !!! ERREUR !!!
-RX %d/%d (%d/%d)
-```
-- These functions appear responsible for:
-- Receiving and validating packets
-- Detecting checksum mismatches
-- Possibly retrying on failures?
-
+PS: Not tested extensively
 
 ## IP Button Packet Anatomy
 
@@ -98,8 +71,7 @@ Seems to send two of the packets each time a button is pressed
 ### Sequence Number
 
 * 2 bytes, Little Endian
-* Only the **first byte** appears to increment; the second is often `FF`, suggesting padding or reserved space
-* Likely acts as a replay or event counter
+* Only the **first byte** appears to increment; the second is just `FF`, suggesting padding or reserved space
 
 ### Command Code
 
@@ -138,14 +110,14 @@ Seems to send two of the packets each time a button is pressed
   * `02` - Repeat count (or `00` for infinite)
   * `01  - Probably Fixed field or field to actually tell the device yes play something lol
   * `09` - Melody ID (9 in this case)
-  * `0100` - **Possible end-of-command marker**, appears to terminate command blocks (expept for stop commands)
-  * `01` - Fixed
+  * `0100` - **end-of-command marker**, appears to terminate command blocks (expept for stop commands)
 
-### Checksum (1 byte)
+### Checksum (2 bytes)
 
-* **Position:** Final byte of packet
-* **Behavior:** Matches `(sum of all previous bytes) & 0xFF` in most cases, but not always.
-* **Status:** **SEND HELP** (see section below)
+* **Position:** Final two bytes of packet
+* **Algorithm:** PSA Checksum algorithm
+* **Implementation:** See the Checksum Implementation section below
+* (Looks often like this `014a`)
 
 ---
 
@@ -165,83 +137,52 @@ Seems to send two of the packets each time a button is pressed
 ### Stop All Zones
 
 ```
-4d454c 001a 0100 24ff 5002 ffff ffff ffff ffff ffff ffff 0f 01 07
+4d454c 001a 0100 24ff 5002 ffff ffff ffff ffff ffff ffff 0f 0107
 ```
 
 * All zones = `FF FF ...` (you actually cant choose which zone to turn of system refuses zonemaps here)
 * Command = Stop (`5002`)
 * Ends with `0F 01` instead of `0100` → supports theory that `0100` indicates only the end of melody/alarm command block
-* Checksum = `07`
+* Checksum = `0107`
 
 ---
 
-## Checksum Problem
+## Checksum Implementation
 
-While many packets obey a simple rule:
+The checksum algorithm used by Bodet PSA protocol has been successfully reverse engineered thanks to severe insanity (I didn't realize it as 2 bytes until I already wasted 5 days reverse engineering it). It works as follows btw:
 
 ```python
-checksum = sum(packet[:-1]) & 0xFF
+def compute_psa_checksum(data: bytes) -> bytes:
+    var_e = 0x0000  # Starting seed value
+    for i in range(len(data)):
+        var_e ^= (data[i] + i) & 0xFFFF
+    return var_e.to_bytes(2, 'big')  # 2-byte checksum, big-endian
 ```
+PS: I extracted this info by decompiling the SIGMA Software Package by Bodet
 
-... others **diverge** due to what appears to be a variable offset or conditional logic. Several hypotheses have been explored:
-
-* Static or conditional offset subtracted from the sum
-* Offset based on specific bytes (e.g., command, zone byte)
-* Very small chance of a lookup table (LUT) approach per command (dont think so though since IP buttons have only 256KB RAM)
+Key characteristics:
+- Uses a seed value of 0x0000
+- For each byte in the data:
+  - Adds the byte value and its index
+  - XORs the result with the running checksum
+  - Applies a 16-bit mask (0xFFFF)
+- Returns a 2-byte big-endian checksum
 
-### Consequences
+This algorithm allows for generating valid packets for the Bodet PSA system. It was verified against known working packets and matches the behavior observed in the system.
 
-If the checksum is wrong, the Bodet PSA system and its components obviously ignore the packet. Hence generating your own commands reliably is **not yet possible** unless mimicking an exact known good packet.
+To use this algorithm:
+1. Prepare your packet data excluding the checksum
+2. Calculate the checksum using the function above or the python code in this repo.
+3. Append the 2-byte checksum to your packet data
+4. Send to your Bodet Harmony Multicast Address (Port 1681)
 
-This makes full integration with modern systems (for triggering Bodet audio via automation) dependent on further reverse engineering.
+For a ready-to-use implementation, see the `hex_checksum.py` script in this repository.
 
 ---
+##
+
+
+## Reminence of the Journey here.
+
+The `executables/hexen.py` script is not recommended, I used it to make some sample data by listening if the Harmony Speaker would produce noises. It is filled with cursewords
 
-## Please Help me !!!
-
-If you have firmware dumps, better knowladge of UDP and reverse engeneering checksums or just generally more insights, feel free to contribute
-
-## Bruteforcing Tool (`hexen.py`)
-
-The `executables/hexen.py` script provides a utility to send raw hex payloads and includes a bruteforce mode for the last byte of a given hex prefix. This is particularly useful for trying to find working checksums or other variable last bytes.
-
-### How it Works:
-
-1.  **Initiating Bruteforce:**
-    *   Run the script: `python hexen.py`
-    *   To start a bruteforce, type: `brute <hex_prefix>`
-        *   Example: `brute 4d454c0021010004ff300180000000000000000000000000010202010f010001`
-        *   The script will then iterate through all possible last bytes (0x00 to 0xFF) appending them to this prefix.
-
-2.  **Configuration Prompts:**
-    *   **Mode Selection:**
-        *   `(1) Manual`: Sends one packet at a time and asks for feedback.
-        *   `(2) Auto Ascending`: Sends all packets from `<prefix>00` to `<prefix>ff` automatically.
-        *   `(3) Auto Descending`: Sends all packets from `<prefix>ff` down to `<prefix>00` automatically.
-    *   **Delay:**
-        *   Prompts for the time (in seconds, e.g., `0.5`, `1`) to wait between sending each packet.
-
-3.  **Interactive Controls (During Bruteforce):**
-    *   **Manual Mode (`1`):**
-        *   After each packet is sent, you'll be prompted: `Did it work? (y/n/auto/stop/r=retry last 3/c=cancel):`
-            *   `y`: Confirms the current hex string worked. The bruteforce for this prefix stops, and the successful string is saved to the `MAGIC` file.
-            *   `n`: Continues to the next hex value.
-            *   `auto`: Switches to auto-ascending mode for the remainder of the current prefix.
-            *   `stop` or `c`: Aborts the current bruteforce operation.
-            *   `r`: Resends the last up to 3 packets (including the current one).
-    *   **Auto Modes (`2` or `3`) (Windows Only - requires `msvcrt`):**
-        *   An initial message will inform you: `During auto mode: press 'c' to cancel, 'r' to retry last 3, 'p' to pause/resume.`
-            *   `c`: Cancels the current bruteforce operation.
-            *   `r`: Pauses sending, resends the last up to 3 packets, then resumes.
-            *   `p`: Toggles pause/resume for the auto-sending process.
-
-4.  **Saving Results to `MAGIC` File:**
-    *   The `MAGIC` file path is defined at the top of `hexen.py` (default: `/Users/crt/Documents/bodeting/research/bad-bruteforcing/attempt-1.txt`).
-    *   **Successful Bruteforce:** If you confirm a packet worked (with 'y' in manual mode), the complete successful `full_hex_string` is automatically appended to this file.
-    *   **Cancelled/Completed (No Success):** If the bruteforce is cancelled or finishes all iterations without a 'y' confirmation, you'll be prompted:
-        `Kein Zauber hat gewirkt oder du hast abgebrochen. Gib den Suffix für '<hex_prefix>' ein, um ihn ins Buch zu kritzeln (oder Enter zum Überspringen):`
-        *   If you enter a suffix (e.g., `fa`), the script will save `hex_prefix + entered_suffix` to the `MAGIC` file.
-        *   If you press Enter, nothing is saved for that attempt.
-    *   The script checks if the directory for the `MAGIC` file exists and if the file is writable, providing error messages if issues are encountered.
-
-This tool aims to simplify the process of testing variations of known packet structures, especially when only the checksum isnt known