7 ms·
Author here. Thanks for posting! I have done some progress since, just didn't have much time to churn out a Part 2 (soon™, maybe) Feel free to ask any question
by Ristovski 5y ago
Author here. Thanks for posting!
I have done some progress since, just didn't have much time to churn out a Part 2 (soon™, maybe)
Feel free to ask any questions
- denysvitali 5y agoPlease, post the Part 2 here on HN as soon as it out. This Part 1 was an amazing read!
- Ristovski 5y agoI never anticipated people would find it this interesting which is why I barely got enough motivation to write the first part, so thanks for the encouragement!
- mrlambchop 5y agoI'm curious if the use of little add on MCUs to cellphone designs like this opens up the opportunity to back door into the OS (such as reprogramming the MCU and sending malformed data into the kernel). (re: weird bug where calling __aeabi_uidiv calls __exidx_end, could be hard fault handler getting invoked due to either div by 0 or incorrect linkage - that M0 has a few caveats around this instruction that I vaguely recall needing specific compiler settings for) Great write-up BTW - subscribe!
- Ristovski 5y ago> I'm curious if the use of little add on MCUs to cellphone designs like this opens up the opportunity to back door into the OS I would say that the possibility is there - imagine a buffer overflow (or something as bad) in the driver running in the kernel. However, getting the malicious firmware onto the MCU would be the difficult part. But I suppose even a purposefully "bad" batch of MCUs that have an extra core executing malicious code is not exactly science fiction in these times :P > could be hard fault handler getting invoked due to either div by 0 or incorrect linkage Interesting! I will look into this, cheers. > Great write-up BTW - subscribe! Thank you, much appreciated!