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)
Related
I have Arduino with some RF 433 receiver and 433 remote to my gate (Moovo/Nice - chip EG301).
I can read codes from this remote, but every next click (on the same button) generate diffrent codes:
Canal C Serie D Rolling Code EDC9976E
Canal C Serie D Rolling Code 760643E1
Canal C Serie D Rolling Code 516B67F9
Canal C Serie D Rolling Code 84AAE281
Clear signals in HEX:
Received 65 bits (x1): 01 0a ea a3 34 9f ff ff fd
Received 17 bits (x1): 01 0a ea
Received 65 bits (x1): 00 50 b2 58 a6 9f ff ff fd
Received 17 bits (x1): 00 50 b2
Received 65 bits (x1): 00 e0 6f 9e 28 9f ff ff fd
Received 17 bits (x1): 00 e0 6f
How can I 'save' my remote and recognize it next time?
EDIT:
My reveiver is simple module MX-RM-5V.
If I good searched, signal from remote is encrypted by keeloq.
Maybe I need special reveiver with handle keeloq?
Rolling code is a protocol that roll codes to make it harder to replicate the remote control.
As you probably know, you can go to any store selling remotes and buy a copyable remote for fixed codes, and for these type of devices your program will suffice, but not for rolling codes.
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 am aware that most of the Base64 encoding has == at the end. Is there any other which uses does the same?
For example, I found this:
nijdRcCHIUnketWzFbcxmvqQKKDnFW05LSE3ttTjoqyBna7JT87AwxeKdoOszXYODMRm6UfA8jK97qgV8A==
But it is not a Base64 kind. What else can it be?
The string you have posted is a valid Base64 string.
A Base64 string will end with == if and only if the number of bytes it encodes, mod 3, equals 1.
>>> for i in range(10):
... print(i, base64.b64encode(b"\x00"*i))
...
0 b''
1 b'AA=='
2 b'AAA='
3 b'AAAA'
4 b'AAAAAA=='
5 b'AAAAAAA='
6 b'AAAAAAAA'
7 b'AAAAAAAAAA=='
8 b'AAAAAAAAAAA='
9 b'AAAAAAAAAAAA'
Do you see the pattern?
It happens that 16-byte (128-bit) encryption keys are very commonly encoded in Base64, and since 16 mod 3 = 1, their encoding will end with ==. But your string, decoded, is 61 bytes (488 bits) long. That is too big to be most sorts of encryption key, and too small to be an RSA key.
This is your string, decoded, and then hexdumped:
00000000 9e 28 dd 45 c0 87 21 49 e4 7a d5 b3 15 b7 31 9a |.(.E..!I.z....1.|
00000010 fa 90 28 a0 e7 15 6d 39 2d 21 37 b6 d4 e3 a2 ac |..(...m9-!7.....|
00000020 81 9d ae c9 4f ce c0 c3 17 8a 76 83 ac cd 76 0e |....O.....v...v.|
00000030 0c c4 66 e9 47 c0 f2 32 bd ee a8 15 f0 |..f.G..2.....|
0000003d
I don't see anything in there to tell me what it actually is, and file(1) is also stumped. It could be random enough to be encrypted, but I can't tell for sure by eye. (And if it is random, that doesn't mean it's encrypted! It could just be the output of a random number generator.)
It is important to understand that Base64 is not encryption, because it has no key. I didn't need to know or guess any piece of secret information to reverse the Base64 encoding of your string. (The term 'encoding' can be confusing — it is more general. UTF-8, Base64, and DEFLATE are all encodings, and so is AES-CBC, but of all of them, only AES-CBC is encryption.)
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?
Can anyone give me information on which standard contains MAP Tags - sm-RP-UI?
04 1a - sm-RP-UI
24 - TP-RP/UDHI/SRI/MMS/MTI
0b - length
91 26 18 18 55 32 f7 - TP-Originating-Address
00 - TP-PID
00 - TP-DCS
90 40 02 91 61 42 82 - TP-Service-Centre-Time-Stamp
07 - TP-User-Data-Length: (7) depends on Data-Coding-Scheme
ca f0 3a 2c a7 87 01 - TP-User-Data
The details are needed for coding and I'd like to know which standard they are in. I have been looking in GSM 29.002, GSM 23.040, and GSM 24.011 and I haven't found them.
Any help would be greatly appreciated,
Thank you.
The SMTL PDUs are defined in 3GPP TS 23.040 - Technical realization of the Short Message Service (SMS)
More specifically:
04 1a
This is ASN.1 tag a length (OCTET STRING). Since you say this is sm-RP-UI
it would be the SignalInfo ASN.1 type defined in 3GPP TS 29.002
used with labels sm-RP-UI on different MAP operations.
24
First thing to look here are the last two bits (TP-Message-Type-Indicator: 9.2.3.1 of 23.040)
Since you have H'24 -> B'00100100. This is an SMS-DELIVER (SC to MS)
SMS-DELIVER (9.2.2.1) contains
TP-Message-Type-Indicator (TP-MTI on 9.2.3.1) (bit 0-1 --> 00)
TP-More-Messages-To-Send (TP-MMS on 9.2.3.2) (bit 2 --> 1: "No more messages are waiting for the MS in this SC
TP-Status-Report-Indication (TP-SRI on 9.2.3.4) (bit 5 --> 1: "A status report shall be returned to the SME")
TP-User-Data_Header-Indicator (TP-UDHI on 9.2.3.23) (bit 6 -> 0: "The TP-UD field contains only the short message")
TP-Reply-Path (TP-RP on 9.2.3.17) (bit 7 -> 0: "Not set")
0b 91 26 18 18 55 32 f7
TP-Originating-Address (TP-OA 9.2.3.7 - Address fields in 9.1.2.5) that works:
** Address-Length: H'B = D'11 (not this is in semi-octets)
** Type-of-Address: H'91=B'10010001 with Type-of-Nuymber (B'001: International number) and Numbering-Plan (B'0001: ISDN/E.164)
** Address-Value: BCD: 62818155327 (F is filler)
00
TP-Protocol-Identifier (TP-PID 9.2.3.9)
00
TP-Data-Coding-Scheme (TP-DCS 9.2.3.10)
90 40 02 91 61 42 82
TP-Service-Centre-Time-Stamp (TP-SCTS 9.2.3.11) 2009/04/20 19:16:24
07
TP-User-Data-Length (TP-UDL 9.2.3.16)
ca f0 3a 2c a7 87 01
* TP-User-Data (TP-UD 9.2.3.24)