Short brief: I have a small toy that uses infrared signals from a remote to change colors of some lights, as well as their patterns. I've managed to capture the pattern timings, wrote a script in python to convert it to 1's and 0's, and then I have an android app that will convert the 1's and 0's to the IR timings for the blaster. I've tested all of these patterns and they make the toy respond as expected from my phone.
Instead of trying to capture every single pattern manually, I think there's some sort of patterns inside the codes - I'm trying to figure them out. It looks like there's a check at the end of each, but that's the part I can't crack. I've tried simple checksum-like things, as well as revEng.
In all honesty, this is a bit over my head - my experience is mostly web-based. I don't even know for sure if there's a CRC code, but it makes sense looking at the data.
Here are a few samples - I've provided them as the binary as well as translated to HEX (less characters to stare at).
Pattern titles are Color / Animation / Transition / Speed
Light Blue / Double Flash / Fade / Normal
1001001100111011011010011100101001010010111110100011011001101000001000110100101011010111101111011110111101001011110110101011101100101001
93 3b 69 ca 52 fa 36 68 23 4a d7 bd ef 4b da bb 29
Light Blue / Solid / None / Normal
1110001100110011011011100111101111111010100111001010010100101111001010110001000011110110101001111110101110100011100001101000111110111101111011011001
e3 33 6e 7b fa 9c a5 2f 2b 10 f6 a7 eb a3 86 8f bd ed 90
Light Blue / Pulse / Straight / Slow
10110011001110110110111100101010010111101111011010101001111011111010001100000110110110011010011100101001010010111010101
b3 3b 6f 2a 5e f6 a9 ef a3 06 d9 a7 29 4b aa
Light Blue / Pulse / Straight / Normal
10110011001110110110111100101011001111101111011010101001111011111010001100000110110110011010011100101001010010111101011
b3 3b 6f 2b 3e f6 a9 ef a3 06 d9 a7 29 4b d6
Light Blue / Pulse / Fade / Fast
11100011001100110110111001111010001000101001110010100101001011111010001101100110111110000011011010001011111010111011111010011111101111110110110000001
e3 33 6e 7a 22 9c a5 2f a3 66 f8 36 8b eb be 9f bf 6c 08
Light Blue / Pulse / Fade / Normal
1110001100110011011011100111101010000000100111001010010100101111101000110110011011111000001101101000101111101011101111101010111110111111011011
e3 33 6e 7a 80 9c a5 2f a3 66 f8 36 8b eb be af bf 6c
Light Blue / Pulse / Fade / Slow
1110001100110011011011100111101111000110100111001010010100101111101000110110011011111000001101101000101111101011101111101101011110111111011011101011
e3 33 6e 7b c6 9c a5 2f a3 66 f8 36 8b eb be d7 bf 6e b0
You can see that the Pulse / Fade patterns all start the same, as well as the Pulse / Straight - which makes me believe even more that the entire IR sequence is simply a list of parameters, not necessarily pre-defined patterns.
tl;dr: Are there CRC patterns at the ends of these, and how can I figure them out?
Related
This is quite long, but if you're into reverse engineering and know stuff about serial protocols, please bear with me. I have the questions at the end once I've laid out all the data and what have I done already.
I have this project ongoing where I try to get the data out of my boiler and store it for monitoring purposes. Boiler it self has a relay board with RS485 connection, that connection is meant to be used with a room controller and is on a same bus than the Boilers own main controller.
I figured out the pins on the relay board as:
51 = GND
52 = RS485/A
53 = RS485/B
54 = +5VDC
Then connected the logic analyzer and got the data out. I have two datasets from the logic analyzer, first when the main controller is idle (capture) and a dataset when the main controller is put to info view which displays the temperatures for different sensors in the boiler (capture3).
During both captures, the boiler and the main controller where connected and there is no way for me to get in between these. So I can only see the traffic in the whole bus, but cannot tell who is sending what.
From both datasets, I assumed that the connection is 115200 8n1.
When the boiler is in "idle" it sends this some pingpong "A3 FD" that gets reply "00" and at times there is some status sent, that I assume is from the relay board.
2021-05-25T05:19:57.038605 A3 FD
2021-05-25T05:19:57.039344 00
2021-05-25T05:19:57.039951 A3 24 09 A2 80 04 83 18 01 00 08 FF
2021-05-25T05:19:57.054151 A3 FD
2021-05-25T05:19:57.054892 00
2021-05-25T05:19:57.100784 A3 FD
2021-05-25T05:19:57.101527 00
2021-05-25T05:19:57.162962 A3 FD
2021-05-25T05:19:57.163702 00
2021-05-25T05:19:57.225138 A3 FD
2021-05-25T05:19:57.225878 00
2021-05-25T05:19:57.287315 A3 FD
2021-05-25T05:19:57.288054 00
2021-05-25T05:19:57.349493 A3 FD
2021-05-25T05:19:57.350235 00
2021-05-25T05:19:57.411669 A3 FD
2021-05-25T05:19:57.412407 00
2021-05-25T05:19:57.473849 A3 FD
2021-05-25T05:19:57.474591 00
2021-05-25T05:19:57.536025 A3 FD
2021-05-25T05:19:57.536764 00
2021-05-25T05:19:57.537370 A3 24 09 A2 80 04 83 10 01 00 08 BB
2021-05-25T05:19:57.551570 A3 FD
2021-05-25T05:19:57.552313 00
Then, when the main controller is put to info view, I can see packets starting with 07 to appear in to the bus. I think I can also identify request-response pattern. So I assume things starting with 07 are from the main controller when it's requesting data.
2021-05-26T05:27:41.475221 A3 FD
2021-05-26T05:27:41.476051 00
2021-05-26T05:27:41.547727 A3 FD
2021-05-26T05:27:41.548452 07 A2 81 81 68 AA 04 00
2021-05-26T05:27:41.596947 A3 FD
2021-05-26T05:27:41.597668 00
2021-05-26T05:27:41.598231 A3 24 09 A2 80 83 68 81 AA 8E 03 6E
2021-05-26T05:27:41.599577 A3 FD
2021-05-26T05:27:41.600422 00
2021-05-26T05:27:41.672082 A3 FD
2021-05-26T05:27:41.672808 07 A2 81 81 69 AA 05 66
2021-05-26T05:27:41.673858 A3 24 09 A2 80 04 83 98 00 00 08 2B
2021-05-26T05:27:41.675972 A3 FD
2021-05-26T05:27:41.676702 00
2021-05-26T05:27:41.677308 A3 24 09 A2 80 83 69 81 AA F3 00 F0
2021-05-26T05:27:41.678559 A3 FD
2021-05-26T05:27:41.679396 00
2021-05-26T05:27:41.734260 A3 FD
2021-05-26T05:27:41.734979 07 A2 81 81 6A AA 06 CC
2021-05-26T05:27:41.783478 A3 FD
2021-05-26T05:27:41.784215 00
2021-05-26T05:27:41.784780 A3 24 09 A2 80 83 6A 81 AA FF 7F 50
2021-05-26T05:27:41.786109 A3 FD
2021-05-26T05:27:41.786961 00
What I have already noted:
Requests
First 4 bytes are always the same
5th byte is a rolling number (maybe sensor id?)
6th byte is always AA (some sort of separator or command?)
7th byte is a rolling number between 01-09
Responses
First 6 bytes are always the same
7th byte is always the same as the requests 5th byte
bytes 8 and 9 are always 81 AA
Last 3 bytes change so it could be the data and checksum
I tried to match the responses to the values in the screen during capture:
T01: 23
T02: 13
T03: --
T04: 47
T05: 88
T06: 24
T07: --
T08: 86
T09: 59
T10: 20
I also assume that the numbers are rounded in the screen and most likely the data is transferred as 16bit signed integer as temperatures (at least outside T2) can be negative.
Questions that I have:
Do you agree with the 115200 8n1 ?
Does someone recognize the protocol ?
Can someone see something else that I'm not seeing ?
Suggestions what to do next to get this thing cracked :)
I've put here all the capture data (Saleae Logic), parsed packets and the request response pairs I though I recognized.
Data in Google Drive.
Note that on the capture data:
Channel 0 = RS485/A
Channel 2 = RS485/B
I have been trying for hours to understand what minecraft packets mean but they don't seem to adhere to the protocol I've been using wireshark to sniff the packets and according to the protocol they should start with 0x something but they never do I'm really confused rn and any help would be greatly appreciated.
Here is some of the data that came with packets:
57 9e e9 f7 7f 3c 0b c7 b2 f0 f2 1d 8e 42 6e
9c 14 57 71 74 6b 83
54 ad d7 3a 51 60 55
any help is really appreciated
0x is just a way of telling (almost all language compilers) that the following number is a hex number, 9e would be written as 0x9e in Java. There are also other number prefixes, e.g. 0b means that the following number is binary (0 and 1's).
I have been trying to parse for a long time, but I just can't get it. I tried a lot of types and converters, but it didn't give any effect. Also i googled everywhere i can.
Here is full block of data:
3D 08 41 CF AC D9 59 64 44 44
Where is
3D - type of data (datetime of length),
08 - length of data and data (of datetime)
41 CF AC D9 59 64 44 44 = 8 October 2020 10:38:46 UTC
All other data was Big-endian and this block, maybe, same.
The closest binary data were Apple Absolute and Ole automation (current data was encoded in DCode and сompared with my data), but nevertheless they were not. Back-end is old and written on Java, maybe this will be some kind of clue.
Edit
Thanks to #GiacomoCatenazzi, business got off the ground. I think that start of time is 01.01.1970, but it is not unix epoch. And there is difference between mod by hour or by seconds (like seconds fracture, but without milliseconds).
The main problem I see at the moment is to find out datetime with or without seconds.
First byte 41 - may be a true value. And last 2 or 3 bytes is often equal.
Relative times to Zero
3C - 3D C2 3F BF -1m
Where 3C - type of data (datetime of 4 bytes)
3D 08 - 41 CE E1 1F E0 00 00 00 -1s
3D 08 - 41 CE E1 1F E0 02 22 22 1s
3D 08 - 41 CF AC EB BF A2 A2 A2 Current datetime (Oct 15 2020 02:59:15 GMT+0300)
3C - 3D C2 3F C0 0 - Center
3C - 3D C2 3F C1 1m
3C - 3D C2 3F FC 1 hour
3C - 3D C2 45 60 1 day
3C - 3D C2 F3 C0 1 month
3C - 3D CA 44 E0 1 Year
3C - 3E 8A BF E0 25 year (Dec 26 1994 03:00:00 GMT+0300)
3C - 3F 59 D6 CC Current date only (Oct 15 2020) (26711820 - minutes since 01.01.1970)
I am trying to use run gsm algorithm command using RUIM tool. The response is 97 0C, but there is no data on Dataout.
The command i am using is.
A088 0000 10 AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
where AA.. is the random number (16 bytes).
Before running this command, I have selected DFgsm file. Successful verification of CHV1 is also done, but still no data on dataout.
Kindly tell me what can be the cause or how to debug it. I am new to this domain so please ignore the mistakes
I only have some experience on GSM USIMs and to my knowledge SW1=97 usually refers to a key/pin issue. however since I see SW2=0C it may be that it is correct for RUIM or CDMA SIMs.
So here is a trace of a successful GSM Run GSM Algo:
> A0 88 00 00 10 AA AA AA AA AA AA AA AA AA AA AA AA AA AA AA AA
< [] 9F 0C
> A0 C0 00 00 0C
< 30 E8 30 F8 E6 6A B2 9D 5D 5D 5F F9 90 00
So I suggest you run the "GET_RESPONSE" APDU i.e. A0 C0 00 00 + SW2
Regards,
I'm trying to implement certificate signature verification on a Microchip pic controller (certificates are generated and signed using OpenSSL). The Microchip PIC controller doesn't support OpenSSL libraries, but it does have an encryption/decryption function. I was successful in getting a SSL connection between PIC controller and a web server. My next step is to setup signature verification on the PIC controller.
After reading PKCS#1 V2.1 RSA Cryptography Standard (http://www.rsa.com/rsalabs/node.asp?id=2125)
I realized that encryption is essentially the same as signature verification and decryption is the same as signing. More specifically both encryption and verification uses the public key and the following formula:
m = s ^ e mod n
Where s is the signature or the message, e is the public exponent, n is the modulus and m is the encrypted message or decoded signature. Therefore, I'm trying to use the encryption algorithm provided to perform signature verification.
In order to verify the certificate, I generated the SHA1 hash of the certificate; Decoded signature using CA's public key and encryption algorithm. Remove the padding from the decoded signature, the result hash should be equal to the SHA1 hash of the certificate.
However, I cannot get the two hash values to be equal. I tried to verify my assumption and PIC controller results using OpenSSL command line.
This is the hash value I got from both OpenSSL command line and PIC controller
openssl rsautl -in signature.txt -verify -asn1parse -inkey pubkey.pem
-pubin
db e8 c6 cb 78 19 3c 0f-fd 96 1c 4f ed bd b2 34 45 60 bf 65
This is what I got from Signature verification using OpenSSL. After removing "ff" paddings I'll end up with asn1 format of the certificate hash.
openssl rsautl -verify -in signature.txt -inkey pubkey.pem -pubin
-raw -hexdump
00 01 ff ff ff ff ff ff-ff ff ff ff 00 30 21 30
09 06 05 2b 0e 03 02 1a-05 00 04 14 db e8 c6 cb
78 19 3c 0f fd 96 1c 4f-ed bd b2 34 45 60 bf 65
However this is what I got from the PIC controller which is much different from the above
8e fb 62 0e 09 c8 0b 49 40 1f 4d 2d a7 7d d6 8c
9b bc 95 e6 bc 98 4b 96 aa 74 e5 68 90 40 bf 43
b5 c5 02 6d ab e3 ad 7b e6 98 fd 10 22 af b9 fb
This is my signature
7951 9b3d 244a 37f6 86d7 dc02 dc18 3bb4
0f66 db3a a3c1 a254 5be5 11d3 a691 63ef
0cf2 ec59 c48b 25ad 8881 9ed2 5230 bcd6
This is my public key (I'm using a very small key just for testing, will make it larger once everything works)
96 FE CB 59 37 AE 8C 9C 6C 7A 01 50 0F D6 4F B4
E2 EC 45 D1 88 4E 1F 2D B7 1E 4B AD 76 4D 1F F1
B0 CD 09 6F E5 B7 43 CA F8 14 FE 31 B2 06 F8 7B
Exponent is 01 00 01
I'm wondering are my assumptions wrong that I cannot use encryption algorithm for decoding signature? or I'm doing something else wrong?
It turned out the method I described above is correct. I was able to get the matching result from hashing the certificate and unsigning the signature using encryption.
The problem that caused my previous failing attempts was the endianess used by Microchip Pic controller. They use small-endian instead of big-endian. I did not pay attention to the endianness of the exponent since 01 00 01 is the same in either format. However I was wrong, it turns out Microchip looks at a 4 byte value as the exponent (RSA standard??). So it pads 00 in the front resulting 00 01 00 01. Therefore, the endianness matters now since 00 01 00 01 is different from 01 00 01 00. And 01 00 01 00 is the small-endian format that Microchip Pic uses.