# Decrypt AES encoded payload? **URL:** \ **Category:** How to get started\ **Created:** [January 8, 2018, 6:50am UTC](https://www.thethingsnetwork.org/forum/t/decrypt-aes-encoded-payload/11615 "2018-01-08T06:50:14Z")\ **Posts on this page:** 1\ **Showing post:** 9
**Author:** ![arjanvanb](https://www.thethingsnetwork.org/forum/user_avatar/www.thethingsnetwork.org/arjanvanb/32/46626_2.png) [@arjanvanb](https://www.thethingsnetwork.org/forum/u/arjanvanb)\ **Post date:** [January 8, 2018, 11:36am UTC](https://www.thethingsnetwork.org/forum/t/decrypt-aes-encoded-payload/11615/9 "2018-01-08T11:36:50Z")
~~When using ABP, then~~ I guess TTN Console cannot know if the correct Application Session Key (AppSKey) was used. For uplinks, the Message Integrity Code (MIC) is calculated using the secret Network Session Key (NwkSKey), not the AppSKey. But even when TTN determines the packet’s MIC is valid, decryption of the application payload (using the secret AppSKey) ~~might~~ will still silently fail when using different secrets for encryption and decryption. (So: will show different results when the AppSKey in TTN Console and the node do not match.) You can see for yourself with your own data or [an example in the “FRMPayload decrypted” part of the online decoder](https://runkit.io/avbentem/lorawan-packet-decoder/branches/master?data=QK4TBCaAAAABb4ldmIEHFOMmgpU=&nwkskey=99D58493D1205B43EFF938F0F66C339E&appskey=0A501524F8EA5FCBF9BDB5AD7D126F75): just play with the AppSKey to see you’ll get different decrypted data, _without any clue if the right key was used_. Changing the NwkSKey will get you an error though, as for the MIC we know the expected value from the LoRaWAN packet. So: are you sure you used the correct AppSKey in your node? See also [Hex, lsb or msb?](https://www.thethingsnetwork.org/forum/t/hex-lsb-or-msb/2809) --- _[View the full topic](https://www.thethingsnetwork.org/forum/t/decrypt-aes-encoded-payload/11615)._