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
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.
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 using trying to add the following IAS zone devices (from HEIMAN) to my ZCL co-ordinator(CIE) + IoT gateway (from NXP)
emergency button - gets added easily and triggers successfully
door sensor - joins the network but no enrolment process is seen
Q1. Why is it such that one device undergoes enrolment process correctly and the other doesn't? My understanding is that the ZCL stack should do all the enrolment activities. Am I correct?
Q2. I tried writing IEEE address of the CIE to the node's cluster(0x0500) attribute (0x0010) of attribute type (0xf0). But no response. How to tackle this issue?
For a CIE device, the enrolment is more complex and the ZCL stack will not perform this for you (although this may depend on the stack, and any add-on features it provides).
A CIE device may perform its own service discovery using the ZDO Match Descriptor functions. It may send a MatchDescriptorRequest report looking for an IAS server, and you will need to respond with the MatchDescriptorResponse to report that you support this. Typically the request will be looking for the IAS Zone Server cluster (0x500), but you should inspect the packets and respond appropriately. See 2.4.3.1.7 Match_Desc_req, and 2.4.4.1.7 Match_Desc_rsp of the ZigBee specification. If an IAS device is looking for a zone controller, it may not accept any requests until it receives this response, and in fact some devices may leave the network if they don't find the services they are requesting.
Next, it may enrol with the IAS service by sending the ZoneEnrollRequest command, and your application will need to respond to this with the ZoneEnrollResponse to tell the device that it is now enrolled in your system. Refer to 8.2.2.4.2 Zone Enroll Request Command in the ZCL specification.
From your traces, it is hard to say what is happening as the log viewer doesn't provide any information on the contents of the Data Request frames in this view. However, we can see a lot of frames being sent from the device to the coordinator, and it is likely that it is performing one, or both of the discovery services discussed above. You should inspect the requests to find out what they are, and check the appropriate sections of the ZigBee specification, or the ZigBee Cluster Library Specification.
CIE IEEE Address to IAS zone worked successfully. Tested using Xbee s2c.
Explicit Addressing Command Frame (API 2)
7E 00 22 7D 31 01 28 6D 97 00 01 04 2B 7D 5D FF FE E8 01 05 00 01 04 00 20 00 01 02 10 00 F0 6B 7A 29 41 00 A2 7D 33 00 FD
Start delimiter: 7E
Length: 00 22 (34)
Frame type: 11 (Explicit Addressing Command Frame)
Frame ID: 01 (1)
64-bit dest. address: 28 6D 97 00 01 04 2B 7D
16-bit dest. address: FF FE
Source endpoint: E8
Dest. endpoint: 01
Cluster ID: 05 00
Profile ID: 01 04
Broadcast radius: 00 (0)
Transmit options: 20
RF data: 00 01 02 10 00 F0 6B 7A 29 41 00 A2 13 00
Checksum: FD
Explicit RX Indicator (API 2)
7E 00 16 91 28 6D 97 00 01 04 2B 7D 5D A3 87 01 E8 05 00 01 04 21 18 01 04 00 3A
Start delimiter: 7E
Length: 00 16 (22)
Frame type: 91 (Explicit RX Indicator)
64-bit source address: 28 6D 97 00 01 04 2B 7D
16-bit source address: A3 87
Source endpoint: 01
Destination endpoint: E8
Cluster ID: 05 00
Profile ID: 01 04
Receive options: 21
RF data: 18 01 04 00
Checksum: 3A
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 experimenting with creating a Bluetooth Low Energy Peripheral on my Linux computer (The goal is to send data over Bluetooth From an iPhone). Im currently using the Tools hciconfig, hcitool and hcidump.
My current experiment is to advertise a Service with a Specific UUID, that the iOS CoreBluetooth Library will pick up. (Note: I'm not trying to create an iBeacon).
Right now, it's actually as simple as One Single Command that is bugging me.
hcitool -i hci0 cmd 0x08 0x0008 15 02 01 1a 11 07 41 42 43 44 45 46 47 48 49 4a 4b 4c 4d 4e 4f 50
What I think it should do is the following:
0x08: Setting Group to BLE
0x0008: Setting Command to HCI_LE_Set_Advertising_Data
0x15: Setting the Length of the Significant Bytes in the Header to 21. (3 Byte for the Flag packet, 18 Byte for the Service Structure)
0x02: Setting the Length of the Flags structure to 2 Bytes
0x01: Setting the structure Type to AD Flags
0x1a: Flag Value:
bit 0 (OFF) LE Limited Discoverable Mode
bit 1 (ON) LE General Discoverable Mode
bit 2 (OFF) BR/EDR Not Supported
bit 3 (ON) Simultaneous LE and BR/EDR to Same Device Capable (controller)
bit 4 (ON) Simultaneous LE and BR/EDR to Same Device Capable (Host)
(End of Flag)
0x11 Setting the Length of Service Structure to 17 Bytes
0x07 Setting the Structure Type to 128 Bit Complete Service UUID List
0x41 ... 0x50 Setting the UUID of the Test Service to ABCDEFGHIJKLMNOP
As far as I can see with hcidump, it's executed properly and looks the way I wanted to. But it's rejected with Error:
LE Set Advertising Data (0x08|0x0008) ncmd 1
status 0x12
Error: Invalid HCI Command Parameters
And I have spent a whole day trying to get it right. Does someone skilled see what I have done wrong? And is this the correct way to advertise a Service?
(Context for the Interested reader: I have successfully accomplished what I want to do using the Bleno Library in NodeJs. However, this will not fit into the bigger picture in our System. Using HCITool directly for advertising is just for experimentation and will be written in Python later)
The length of the the HCI_LE_Set_Advertising_Data payload should be exactly 32 bytes. Try zero padding the command to reach 32 bytes:
hcitool -i hci0 cmd 0x08 0x0008 15 02 01 1a 11 07 41 42 43 44 45 46 47 48 49 4a 4b 4c 4d 4e 4f 50 00 00 00 00 00 00 00 00 00 00
You can gain some more insight using hcidump --raw.
Compare the output of the original command:
$hcidump --raw
HCI sniffer - Bluetooth packet analyzer ver 5.30
device: hci0 snap_len: 1500 filter: 0xffffffffffffffff
< 01 08 20 16 15 02 01 1A 11 07 41 42 43 44 45 46 47 48 49 4A
4B 4C 4D 4E 4F 50
> 04 0E 04 01 08 2
With the zero padded one:
HCI sniffer - Bluetooth packet analyzer ver 5.30
device: hci0 snap_len: 1500 filter: 0xffffffffffffffff
< 01 08 20 20 15 02 01 1A 11 07 41 42 43 44 45 46 47 48 49 4A
4B 4C 4D 4E 4F 50 00 00 00 00 00 00 00 00 00 00
> 04 0E 04 01 08 20 00
Another way to gain more insight is to run hciconfig hci0 leadv and use hcidump --raw to examine the payload of the SET_ADVERTISING_PARAMETERS command send by hciconfig.
By the way, I've noticed that sometimes a non zero padded command also works, it might depend on the bluez version you are using.