A frontend towards lora-packet.
Assuming base64-encoded packet YOEvASaKGQAFA9KthANV/wADLIV4/Q== Message Type = Data PHYPayload = 60E12F01268A19000503D2AD840355FF00032C8578FD ( PHYPayload = MHDR | MACPayload[..] | MIC ) MHDR = 60 MACPayload = E12F01268A19000503D2AD840355FF0003 MIC = 2C8578FD ( MACPayload = FHDR | FPort | FRMPayload ) FHDR = E12F01268A19000503D2AD840355FF0003 FPort = FRMPayload = ( FHDR = DevAddr | FCtrl | FCnt | FOpts[0..15] ) DevAddr = 26012FE1 (Big Endian) FCtrl = 8A FCnt = 0019 (Big Endian) FOpts = 0503D2AD840355FF0003 Message Type = Unconfirmed Data Down Direction = down FCnt = 25 FCtrl.ACK = false FCtrl.ADR = true
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.
OTAA Join Requests are not encrypted; specify the AppKey in the field of AppSKey, and leave NwkSKey empty to validate the MIC.
OTAA Join Accepts cannot be verified or decrypted above, as those need some additional data to validate their MIC and derive the secret session keys.
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.
lora-packet can also be installed as a command line utility, and since 0.7.7 can also validate/decrypt then:
npm install -g lora-packet
lora-packet-decode --base64 ADFGUkFEshgAdAoAAACyGADXQ5rzpZs=
lora-packet-decode --hex 003146524144B21800740A000000B21800D7439AF3A59B
The maintainer of this page is not affiliated with lora-packet. See & star https://github.com/anthonykirby/lora-packet.