{"id":44763,"date":"2022-01-11T00:00:00","date_gmt":"2022-01-11T00:00:00","guid":{"rendered":"urn:uuid:13f76905-f985-1378-dda7-728550467e59"},"modified":"2022-01-11T00:00:00","modified_gmt":"2022-01-11T00:00:00","slug":"lorawans-protocol-stacks-the-forgotten-targets-at-risk","status":"publish","type":"post","link":"https:\/\/www.threatshub.org\/blog\/lorawans-protocol-stacks-the-forgotten-targets-at-risk\/","title":{"rendered":"LoRaWAN’s Protocol Stacks: The Forgotten Targets at Risk"},"content":{"rendered":"

<\/p>\n

<\/div>\n

First, we compiled the code into something easily handled by a fuzzer. For our purposes, we used the generation method that will allow us to cover as many code paths as possible with legitimate and dumb fuzzing using the AFL++ framework (evolution of AFL). This supplies some instrumentation for mutating pseudorandom bits, bytes, and words.<\/p>\n

We also attempted to collect every type of message that could be interpreted by the parser. We used the persistent mode to increase the fuzzing process speed from by x2 up to by x20. To deal with the amount of “uniq crash files” found in the repositories after fuzzing, we developed a classification method that can help users focus on the most interesting bugs first. <\/p>\n

The code would then be compiled to a different architecture than x86-64, and with a specific cross compiler with specific options. So, if we try to prove the vulnerability by exploiting it, more time will be wasted adapting the exploit to the right architecture. Firmware can also be closed source, so we need different methods to continue automatic bug finding. <\/p>\n

The following are two of the many methods that exist:<\/p>\n