LoRaWAN 1.0.x packet decoder

A frontend towards lora-packet.


Specify the secrets if you want to validate the MIC and decrypt the payload. For an OTAA Join Request or Join Accept see the explaination below. Secrets are sent to the server and might be stored in log files of RunKit.

 
Assuming hex-encoded packet
402F15022600010020564DE4

Message Type = Data
  PHYPayload = 402F15022600010020564DE4

( PHYPayload = MHDR[1] | MACPayload[..] | MIC[4] )
        MHDR = 40
  MACPayload = 2F150226000100
         MIC = 20564DE4

( MACPayload = FHDR | FPort | FRMPayload )
        FHDR = 2F150226000100
       FPort = 
  FRMPayload = 

      ( FHDR = DevAddr[4] | FCtrl[1] | FCnt[2] | FOpts[0..15] )
     DevAddr = 2602152F (Big Endian)
       FCtrl = 00
        FCnt = 0001 (Big Endian)
       FOpts = 

Message Type = Unconfirmed Data Up
   Direction = up
        FCnt = 1
   FCtrl.ACK = false
   FCtrl.ADR = false

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 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:

  • install Node.js and npm
  • run: npm install -g lora-packet
  • run: lora-packet-decode --base64 ADFGUkFEshgAdAoAAACyGADXQ5rzpZs=
    or lora-packet-decode --hex 003146524144B21800740A000000B21800D7439AF3A59B

The maintainer of this page is not affiliated with lora-packet. See & star https://github.com/anthonykirby/lora-packet.