Wednesday, March 6, 2019
Tuesday, March 5, 2019
SDR...decrypter 3
LoRaWAN 1.0.x packet decoder
A frontend towards lora-packet.
Examples
Copy the packet from, e.g.,
"data": "ADFGUkFEshgAdAoAAACyGADXQ5rzpZs=" in the gateway's log.
Beware that LoRaWAN packets are binary data, so do not remove leading zeroes. Also note that erroneous packets (including packets that are just LoRa, not LoRaWAN) are likely to show incorrect results without any warning, so specify the secrets to validate the Message Integrity Code (MIC).
If the 4 bytes MIC is valid, then it's safe to assume the packet has not been altered, that it is indeed a LoRaWAN packet, and that the secret NwkSKey is valid too. But even then one cannot tell if the secret AppSKey is valid as well; specifying the wrong AppSKey simply yields different decryption results.
In LoRaWAN 1.0.x, the value of FCnt only holds the 16 least-significant bits (LSB) of the actual frame counter. But for a 32 bits frame counter still all 32 bits are used when calculating the MIC. So, a LoRaWAN server needs to guess or try the other 16 bits when validating the MIC. Such server can use its own internal counters for a best guess, and as LoRaWAN defines a maximum allowed gap between the last known value and current value (MAX_FCNT_GAP, being 16,384), the server will probably only try one additional value for the MSB. Above, boldly all possible 65,536 values for MSB are tried until a valid MIC is found.
Note that a DevAddr is not unique, and a provider will need to try to validate the MIC using the NwkSKey of all devices it knows for a given DevAddr, until it finds a valid MIC. Only when it finds a valid MIC it knows which device the packet belongs to. Beware that in The Things Network, failing to find a match will NOT be reported in the trace part of the gateway's Traffic page in TTN Console.
The output above is the standard output of lora-packet with some enhancements if the secrets are known, to show if the MIC is valid, brute-forcing the 32 bits frame counter, and to show the decrypted payload.
OTAA Join Requests are not encrypted. OTAA Join Accepts are not fully supported above, as those need some additional data to validate their MIC and derive the secret session keys.
lora-packet can also be installed as a command line utility, and since 0.7.7 can also validate/decrypt then:
- install Node.js and npm
- run:
npm install -g lora-packet - run:
lora-packet-decode --base64 ADFGUkFEshgAdAoAAACyGADXQ5rzpZs=
orlora-packet-decode --hex 003146524144B21800740A000000B21800D7439AF3A59B
The maintainer of this page is not affiliated with lora-packet. See & star https://github.com/anthonykirby/lora-packet.
Monday, March 4, 2019
Sunday, March 3, 2019
Subscribe to:
Posts (Atom)
Ambassador @EmbaixadaRusPt URGENT INTEL the guy hedge fund is stable wontget higher to convince investors until end of the day @realDonaldTrump desesperate either help friends either stay with some cents @USTreasury @POLITICOEurope @ecb @FT @WSJ @EUCouncil @DeptofDefense
https://www.mediaite.com/news/billionaire-trump-backer-bill-ackman-skewers-howard-lutnicks-glaring-conflict-of-interest-he-profits-when-ou...
