Well you need to implement a lorawan 'stack' which can parse the packet but the basic procedure is
1) Convert from Binary64 in bytes
2) Parse the byte sequence according to the spec to discover the elements in the crypto block(s) as per 4.3.3.1
3) Use AES to encrypt the block in 2 ( note encrypt! - weird I know )
4) Xor the block with the remaining FRMPayload blocks to recover the original data
I am guessing this is done to create blocks so the data is scrambled even if you send the same packet.
Actually it's not completely trivial and is normally part of a lorawan network server implementation.
However there is a case the application server should not share it's AppKey with the network server and hence be required to implement it. In this case the best thing would be for the network server to pass the crypto blocks along with the payload so the application server has the information it needs without having to decode the full lora protocol stack (including potentially > 16 bit counters )
In this case if the networkserver ( TTN ) replies to your data request with
{ crypto blocks }, {FRMPayload}
You would recover your data as (pseudo code)
foreach block in cryptblocks
decodedData += AES.encrypt(AppsKey, block) XOR FRMPayload.NextBlock()
In this way the Appskey is secret with respect to the NetworkServer (TTN) while keeping the application decoder simple.