Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Document Syncbot protocol #42

Open
AshyHacker opened this issue Mar 16, 2025 · 0 comments
Open

Document Syncbot protocol #42

AshyHacker opened this issue Mar 16, 2025 · 0 comments

Comments

@AshyHacker
Copy link

AshyHacker commented Mar 16, 2025

BT Name: V
Service UUID: 0000ffe0-0000-1000-8000-00805f9b34fb
Tx and Rx: 0000ffe1-0000-1000-8000-00805f9b34fb

Tx message

Connection initialization

Command: f0c82c000000000000000000000000000000e4

Command submission

Example message: f0c9575195fd2100c257d1c2976000000000b7

The message consists of 19 bytes of data.

  • byte 0: signature
    • always 0xF0
  • byte 1: signature
    • always 0xC9
  • byte 2: data
    • Represents "stroking".
    • By capturing packets, I have observed the values from 0(pull) to 255(push).
    • This byte is encrypted.
  • byte 3: data
    • Represents "rotation".
    • By capturing packets, I have observed the values from 0(CCW) to 255(CW). 128 is neutral.
    • This byte is encrypted.
  • byte 4: data
    • Represents "grip".
    • By capturing packets, I have observed the values from 38(CCW) to 216(CW). 128 is neutral.
      • Note that these end values are not balanced from neutral. More investigation may be needed.
    • This byte is encrypted.
  • byte 5: data
    • unused?
    • This byte is encrypted.
  • byte 6: checksum1
    • sum of unencrypted values of bytes 2-5 mod 256
    • This byte is encrypted.
  • byte 7: null?
  • byte 8: frame ID
    • This value is incremented by 1 every frame, and wraps around when it reaches 256.
  • byte 9-13: encrypt key
    • See details in below section.
  • byte 14-17: null
  • byte 18: checksum2
    • sum of bytes 0-17 mod 256, including encrypted values of bytes 2-5.

Encryption

The data from byte 2 to byte 6 is encrypted using a simple XOR algorithm. The encryption key is sent with the encrypted data, so each packet can be decrypted independently.

The encryption key is 5 bytes long (as the data) and is stored in bytes 9 to 13. Reverse engineering suggests that this encryption key has a unique value for the frame ID and is generated using the Mersenne Twister algorithm, but no detailed analysis has been done. Data encrypted using an encryption key that does not match the frame ID is ignored by the device, so it seems that a verification is performed to ensure that the correct encryption key is used.

According to the packet capture in my environment, the encryption keys corresponding to the 256 frame IDs are as follows:

Encryption keys (frame ID = 0 to 255)
eaa4b22321
4376236d79
3693c527ef
196ceb2d04
e5d4d9de34
382f6aebcb
3eb5c6ec4b
e64dcff926
485bb5d412
c4e87d8548
9b33441d66
2c5715ec16
3a5ba7def4
28df05f982
f258a0d6eb
649c81f936
bf44b642ad
8962cda897
aa8e31edb9
2ecd8b260e
0a0f6be951
9d6c8dc558
dc5e37ed52
4927b1a36e
b34de44204
9abce8bba9
2e7f111b0a
2acebfb6c5
2772115725
149bbe5152
fd3b0084b3
e191a2d0c1
e9d0745222
def3e5b8bd
903595bbf6
6a9ff6326b
4249506621
b54346bd96
16a149533d
f4b5d30ce4
2abd219f50
c383337e2c
16af2701bd
607d37bc81
b456449167
853f1affea
132b176b16
8ef721a346
e74e6d9aa9
e718edf7cf
f2a3957afa
9d47148231
2daf165471
7afa8581e0
89bf1e7916
30c53937a4
851192eb0a
c096427a91
5cfe32a64a
b063550785
1fd7315482
612d5b02bc
cb406734cf
4e00a22aa0
3c7ebdd99f
eeadfd24e3
d481654de0
5e6fecac60
01a09d5e23
77ba306ad4
a72c443f51
a909e5100a
32ac12893d
aa2264d6b1
e47e2bf4df
b60f165e43
8062ed7d05
31f0822837
4d3d014bc0
b65d4d6b96
6035ae45e0
9ec64725dc
21db56c6ec
b1754a7796
253e68bce4
3daacc9e6f
12a1bd4a16
9d42040c97
82b94da1f8
c68ea7fc5d
61fea02774
b63679131e
dc7842ea43
f760d0857b
76f7108232
b11f76de9b
1b8beb0907
306ccd0ca8
1a95e06088
b5b0611098
17818007ce
c76cec012f
69ff96e6a7
630182d98e
487977e3d8
f0999eeeb8
1659fd9916
19d485568d
9c0a5f0c9a
4e75bdb7f6
2e271756ce
a9b7e034e6
2e38825822
a72770d7f0
f19936ed3b
b8af755439
a242d28229
9e3934d2bb
41b5bd69d3
9b8125a66a
5461dd765f
f16f556194
9b868665cf
57ba87975d
9eea30f987
481a1cf930
aec9e8628d
07e6e6d4dc
17472fb762
f014274e03
3b75b7f379
2a8832ff75
b14959e36b
1d330d593b
19d646be84
1482344fe5
80915b524c
5e61b7a0a8
fb62c49536
4bc6d0ce2f
bb415c8a13
2254a4b6cf
a3e0731b59
205c2c488b
3aa8a0c32a
30ad4dd5a9
5c998a28b5
db2bfa0283
82e781c74d
e7d5f3603c
022eec6e51
95026b3d0c
3e653d351c
392905ac24
965978b897
1ab807d243
543e11fa3e
4680f1b8d9
b53a6b389b
0b71d986f5
a4caf35c3e
c269806e24
cfa1f1b014
73edada2fe
5af55238e0
f368924c89
87f0c2d1aa
c41cd8ad8a
22d6a50566
1fb8f672e0
3b39107003
8aa36dd512
3c245208aa
eda0835116
8affe667d1
5d4df72acf
532bcc7d6b
8ac3b5aa92
2208e5a7ac
7cfe13cf09
d9be4af091
af0e1d54cb
f2efa82e3a
2294e4e63e
47fb68e879
ccc13181ff
49a19635f5
161c04655f
b3da4eb17e
bab85fad94
de4466ae23
9607f70e81
f2351a3cf7
8366b7ac16
57d1c29760
6042800860
aa46dfecd3
374ac8377e
90f110f497
8473dbeaeb
3d06e6b3c9
f21f9851bb
83cbc8aa66
7b7b3bc0e4
0f9c5cffea
1f9d8c9900
a4e960e128
1c86488edc
3cecaa5083
1f3400e93c
c9fe579596
91daba5713
ab95ed0aa4
5ce00fd173
32ad7ae4f6
91dfc30ae3
36b4c460ec
c1f3e3c418
beeeeac6bd
a2b90a08ba
6dc569e612
a1019ef3c3
601ff398ee
3684f70c5d
277a4e6029
b48ef9118d
992fc25a2c
10a74c0565
369267c384
e90143e730
6d849acf40
59f4fdba8e
4a0d6aeda2
af4f858566
bd11750ff2
1ddfe385e2
c6203516e2
48707d5c5c
5af8c9b04f
cc052a6936
96216e5cac
af841345c0
cf687e18fc
d500b37cd6
83486caf7b
382f768390
528d1eeb8c
4f3d0bdf5b
1965e6e33a
cacc42a327
e95babda69
849d916c2d
189a24f9eb
92ca2e5e54
d628f05eea
6e03b45305

As for the frame ID, it is assumed that the data is not verified, since it works normally even if a value incremented by 1 for each frame is not used.

Rx message

Example message: f0ce50000000000400c204020a4b1f5000009e

I have not performed a detailed analysis of the Rx messages, but from reverse engineering the following observations have been made:

  • byte 0: signature
    • always 0xF0
  • byte 1: signature
    • always 0xCE
  • byte 2: Battery Level
  • byte 3: ???
    • According to the binary, these bytes appear to represent "RSSI", but the details are unclear.
    • It is observed that the value of this field is always zero.
  • byte 4-5: touch slider sensor
    • 16 bits of data correspond to each of the 16 sensors, with the MSB of byte 4 at the top and the LSB of byte 5 at the bottom.
  • byte 6-7: ???
    • According to the binary, these bytes appear to represent "ErrNum", but the details are unclear.
    • The second bit from the MSB (seventh bit from the LSB) of the byte 7 may indicate whether the device is connected to a power source.
  • byte 8: null?
  • byte 9: frame ID
  • byte 10-17: ???
  • byte 18: checksum
    • sum of bytes 0-17 mod 256
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

1 participant