You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
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:
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.
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)
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:
The text was updated successfully, but these errors were encountered: