you mean introduce a traceable side effect in the underlying dll/system-api? Sure that could work (many debuggers do that), but perhaps they are just not using the same API, or just find another way to stream the data without go through the same interfaces (idk, perhaps through browser APIs or they keep recording all time and just send portions of data which is locally inspected)... it is a good challenge and certainly observing the interruptions hardware could be the right way to go.
In the other hand that is a considerable effort for someone who does not usually work with this part of the stack... would you be able to introduce this changes in an android OS?
See my response to the other comment about them using private APIS. Basically, we would have to try and guess which APIs they were accessing under the hood.
But you are right, this would def be a considerable effort for someone not in the jailbreaking space. I would love to hack it up, but unfortunately haven't dabbled in JB dev since 2011.
That's why I posted the comment to HN. In hopes it might inspire someone in that space to build it. Might also be worth jumping in the theos IRC channel. For someone with the toolchain already set up and a jailbroken iOS device, the code is actually pretty trivial.
This method would be a waste of time and energy. Just reverse the app and find it out. No need to play it like a binary is a magic black box that's impossible to inspect.
In the other hand that is a considerable effort for someone who does not usually work with this part of the stack... would you be able to introduce this changes in an android OS?