Reverse engineering the Motorola Sensorhub: Part 1 | Hacker News Reader

Reverse engineering the Motorola Sensorhub: Part 1

ristovski.github.io

54 pointszdw12 comments

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

Please, post the Part 2 here on HN as soon as it out. This Part 1 was an amazing read!

I 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!

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 (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!

> 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!

Impressive work. In case someone wants more of an academic read, this is the earliest paper I could find: https://syslab.cs.washington.edu/papers/mobilehub-ubicomp15....

This paper did not introduce the sensorhub concept, but provides a good primer. If anyone has a paper on the actual concept, would be interested to know.

While doing my initial research, I stumbled upon a patent [0], where Motorola was listed as the applicant, it seems to be similar in concept to the current sensor hub implementation.

It also mentions "training" and more advanced processing (which would be ideal for the Qualcomm Hexagon DSP, shame it's practically unused on non-Pixel phones).

[0] https://patentimages.storage.googleapis.com/cc/ee/a2/e631f84...

> your favorite reverse engineering suite, like Ghidra

I'm thrilled at the adoption Ghidra has gotten, and glad the NSA used my tax dollars to contribute something useful to the world

I also loved the trick of using objcopy to turn the bytes into an ELF; that's just damn crafty

Pretty sure they could have used the "set image base" option under the memory map view to accomplish the same thing, but it's still a cool workaround nonetheless.

You're right! However, I don't remember the exact issue, but Ghidra behaves differently when loading a raw binary vs when you load an ELF file. Perhaps it was something with the analyzers, I can't recall (there are ELF-specific ones for example).

I miss the double-chop torch action sooooo much since moving away from my moto.

I use it multiple times every day. My old Moto is dying and I am dreading the day I buy a new phone.

Reply on news.ycombinator.com