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,
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 have SL7000 meter and GSM Modem iRZ. When i send by using RS-485 cable - everything work. But when i'm trying to use GSM modem i'm getting issues.
When i send SNRM like this:
7E A0 0A 00 22 00 51 03 93 6A 34 7E
I get normal UA.
But when i try to send SNRM like this:
7E A0 21 00 22 00 51 03 93 6B 21 81 80 12 05 01 80 07 04 00 00 00 02 08 04 00 00 00 01 3D 93 7E (It's from DXDLMSDirector)
I get nothing. Absolutely!
Maybe there is some trick to use hdlc with gsm modem? Maybe special delays or something?
If both of these frames work via the RS-485, and not via the GSM, then there are a couple of possible answers:
1) the addressing you are using is not permitted if this is a seperate port
2) if it is the same port on the meter, then the GSM Modem is not directing traffic to the same RS485 address
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'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.