Asahi Lina (朝日リナ) on Nostr: nprofile1q…shesq nprofile1q…mdexn "Would this feature be possibly useful as part ...

nprofile1qy2hwumn8ghj7un9d3shjtnddaehgu3wwp6kyqpqj3z7k0r0qms2660hlt3z4tg2s5h6rz37l2tg66e6lnxr6tsry07qsshesq (nprofile…hesq) nprofile1qy2hwumn8ghj7un9d3shjtnddaehgu3wwp6kyqpq47653442ud3e8z3l8c9zuz9m548pv0mxcwfn28d49fdkdyqx8sdqlmdexn (nprofile…dexn) "Would this feature be possibly useful as part of a way to hide/obfuscate malicious behavior" is not usually a criteria for labeling something a security issue. There are many ways to hide or obfuscate malicious behavior, especially when you are linking with vendor blobs like this.

There was even a whole contest about this:
https://en.m.wikipedia.org/wiki/Underhanded_C_Contest

Here is an article about how a very, very subtle API misuse in a similar IoT chip due to missing documentation introduced a memory safety issue:

https://tweedegolf.nl/en/blog/145/the-hunt-for-error--22

You could easily just make a similar "mistake" on the ESP32 to create a backdoor, if that was your goal.