[brandontreb]

I did quite a bit of Jailbreak/tweak dev in the past, and I was curious if you could just hook into AVAudioRecorder and show an alert any time it was invoked.

So, I did this sort of thing years ago when I wrote a tweak for the InPulse smartwatch (later became Pebble) https://github.com/brandontreb/inPulseNotifier .I was able to hook into the system messaging, forward it to a custom bluetooth stack (sending it to the watch) and forward the message up the stack to be displayed by the system.

It would stand to reason that the same sort of process would be effective for catching Facebook invoking audio recording. Once you hook into the AVAudioRecorder's interface, you could theoretically observe the following:

1. Open the Audio Recorder app and hit Record - An alert should show to prove your tweak is working.

2. Open the Facebook app. If you receive a similar alert at some point, you could at least prove that FB is invoking the audio recorder at some point without the user's expressed permission.

Am I crazy or could this test actually work?

[sine]

It's possible Facebook could be using an exclusive method to access hardware more directly, much like how Uber had access to restricted developer debugging tools which allowed them to record the screen even when the app was closed.

https://thehackernews.com/2017/10/uber-screen-record-iphone....

[gcb0]

If you want to get paranoid... Maybe it can detect jailbreak and do nothing. or even better, detect jail break, use it to detect if there is hooks into the audioRecord interface, if no hooks, record even more with it's new found powers :)

[adtac]

This is straight up malware behaviour.

[Sargos]

Which is why it doesn't do that.

[dest]

It reminds me the amazing Skype protections against reverse engineering

[andai]

Could you remember a little harder?

[zero_iq]

All sorts of anti-debugging tricks, self modifying code, runtime checksums, network traffic obfuscation, etc.

http://www.secdev.org/conf/skype_BHEU06.handout.pdf

http://runtux.com/files/download/skype.4.pdf

[willstrafach]

I have checked. Facebook does not do this.

[pdkl95]

> does not do this

Do you have the hashes to prove that what you tested matches what is actually installed elsewhere?

No, I'm not actually claiming there actually are different versions in the wild. I just find it strange that anybody can make broad claims about what widespread software may or may not be doing. Widespread use of "A/B testing" and forced remote updates should make everyone question the nature of every binary, even when they have the same name (including version number).

[FridgeSeal]

Fb's well known for large scale A/B testing though. Isn't it more than possible that the binaries/versions/etc that you tested simply weren't part of the test?

[madeofpalk]

You can't A/B test iOS app binaries though.

[_0ffh]

You could A/B test different app behaviour with the same binary by branching on some pseudorandom (quasi-) constant like IMEI or phone number.

[madeofpalk]

Sure. But once you know that everyone has the same binary, you can reverse engineer the binary you know everyone has.

[willstrafach]

The nice thing is that you can reverse engineer it and sniff traffic to find out what the A/B tests are and what they do.

[Zhenya]

Couldn't you test 2 different behaviors in the same binary thought?

[logicallee]

how have you checked (what do you have access to). if you work for Googe on Android would be a good answer for example :)

[traek]

From his bio:

> information security research. ceo @ sudo security group (https://verify.ly).

> previously: founder of "Chronic Dev Team" responsible for many years of iOS jailbreaking solutions (24kPwn, absinthe, corona, greenpois0n, etc).

[logicallee]

I still think "how have you checked" is a fair question.

[willstrafach]

My company collects/analyzes apps from the App Store to test their security, so I have pretty easy access to the machine code for apps.

Certainly a fair question.

[maccam94]

On the Android side, it's not terribly difficult to send a copy of the app to a computer and decompile it. Then you can simply search for any code that invokes the Android function for mic access.

[tectonic]

...and I just deleted the Uber app.

[linkregister]

Delete Uber for a good reason, such as the fact that ride sharing makes driving unreliable as a source of income. Professional drivers have seen their incomes decrease and hours increase drastically.

The article in question starts out breathlessly accusing Uber of spying on users, only to completely walk back the claim by the end. Just by reading the article alone we see that the permission was granted to overcome a capability lapse in the Apple Watch.

[hueving]

>such as the fact that ride sharing makes driving unreliable as a source of income.

That's a terrible reason. Taxi drivers also have an unreliable source of income with the burden of medallion rent in some of the larger cities.

Do you also boycott all construction since that is also unreliable for basic laborers?

[macintux]

The parent’s point was that ridesharing makes life worse for other paid drivers.

If Taskrabbit started sabotaging income for highway construction workers I might avoid it (although to be fair I’ve never used it).

[bryondowd]

Seems like an insufficient reason to me. Many software developers automate processes which in turn eliminates jobs entirely. It's a little different, but still a case of one person/group benefitting at the cost of another's livelihood.

[taneq]

Waitstaff also have an unreliable source of income and see their incomes decrease or hours increase drastically. Planning to boycott restaurants?

[macintux]

See my reply to hueving

[brandontreb]

It is, however when building a mobile substrate tweak, you have visibility / access to the headers of every single system class. One could theoretically hook into any number of audio recording mechanisms (assuming they knew where to look ;) )

[bluesign]

yeah but this would be obvious (can be seen easily) as it will require some "entitlements"

[madeofpalk]

But Facebook doesn't have any extra, special entitlements.

[conradev]

The Microphone access switch in Privacy settings is not just to make users feel better – it enforces that the app has zero access to the microphone. If someone has reason to believe that's not the case, they should report it to Apple Security.

The tricky bit is when users give microphone access to the app (i.e. for video recording functionality), but want to verify it's only being used then.

[nugi]

That is the marketing statement, yes. But the technical implementation is somewhat more complex and possible to bypass than your boilerplate comment suggests.

[conradev]

The technical implementation is called the sandbox, and it's a fundamental part of iOS security. Yes, it is possible to bypass the sandbox, but it would involve exploiting security vulnerabilities on the user's device, which Apple offers up to a $25k bounty for. You generally have bigger problems if something escapes the sandbox on your device, though :)

[notyourwork]

Please clarify ...

[wtvanhest]

My theory is that a different 3rd party app is listening and that FB/Goog are buying the data without even knowing the 3rd party app is listening. Some of the coincidences could be frequency illusion, but I really don't think so. Some of the coincidences are just too strange.

[gcb0]

And that might very well be siri.

Which explain the race to voice assistant, that are used maybe once or twice a year, yet everyone invest millions. from cortana to Echo.

[midgetjones]

I think it's more likely to be amazon/google than apple

[bluesign]

This works for sure, but only on jailbroken devices.

On the other hand, facebook can check (at least on IOS) easily if the device is jailbroken and behave differently.

You can also patch binary and inject some code, (probably swizzle AVAudioRecorder methods) for the same effect.

In this case, Facebook can check binary integrity, and change behavior accordingly.

So this is kind a cat and mouse game.

[lucideer]

> On the other hand, facebook can check (at least on IOS) easily if the device is jailbroken and behave differently.

I'm not 100% sure what's involved in jailbreaking iOS, but I'm pretty sure on a rooted Android you could put measures in place to "fake" results for any root checks the Facebook app would run. You could patch any APIs Facebook could use to make such checks.

[userbinator]

Indeed, that's the whole point of having "root" --- to have complete control over the device and what the applications on it see.

It is a bit of a cat and mouse game, but as the long history of software cracking shows, as long as they still own the machine, the crackers always have the upper hand.

[perfectstorm]

what we really need is a Facebook whistleblower.

[brandontreb]

Interesting. So you are suggesting they may have already considered this and may have some defensive programming around it?

[bluesign]

I don't think Facebook will do this to be honest.

But if they decide to do, I think best way of action will be some defensive programming around it, with plausible deniability.

I am guessing they are already checking binary integrity etc, also they can probably push code updates from server. So when you put this pieces together, they have everything they need technically.

[brandontreb]

So, code updates from the server doesn't matter as we can hook all of the audio recording APIs at a system level. Their _only_ defense IMHO is to NOT do it on Jailbroken devices. You are right, it's super easy to detect jailbroken devices.

[bluesign]

Technically they can also check if you hooked on the recording APIs. This is like a rabbit hole :)

[conradev]

It's not a cat and mouse game if you put this detection in a process that Facebook does not have access to.

[wycy]

If I were Facebook and I were trying to surreptitiously record users via the microphone, I think I would do it by using lower-level hardware APIs rather than high-level Cocoa APIs.

Disclaimer: I don't really know a) if there is some other way to interface with the mic or b) what I'm talking about in general.

[mattnewton]

I am not an expert in this at all, but I would think they would need special permission from apple; many of these undocumented APIs get your app auto rejected.

[dannyw]

Apple is known for giving large apps (eg Uber and their whole screen recording, even outside of the app) special, hidden entitlements though.

[mattnewton]

My impression was that involved a great deal of trust, and if they breached that trust Apple wouldn’t hesitate to smite them. Recording people’s mic seems like it’s pretty harmful to the iPhone brand... But you are right, this could be happening today, and Apple is giving them too much trust, and the smite-ing is yet to come.

[notyourwork]

Am I the only one who finds this completely trust breaking?

[wizardforhire]

Not disagreeing but this is this the hook... facecrook on one hand, you would think would want to save face from a pr perspective. However, on the other they have huge economic incentives to not give af. Given their track record we as individuals assume the best at our own peril.

[nudpiedo]

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?

[brandontreb]

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.

[hypervis0r]

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.

[jageen]

I am wonder, can we not just use wireshark and see that is any audio packet send to Facebook or not.

I am not network guy so just asking and seeking for valid explanation.

[pliny]

How can you know if a packet contains audio?

[ndesaulniers]

As a thought experiment, such content would likely be encrypted. The request size can give away the content type, but speech-to-text could be done on device, making it harder to guess the contents based on request size (assuming the identified speech would be significantly smaller compressed relative to audio).

[taneq]

Then correlate speaking with CPU usage. Processing audio is always going to have /some/ cost /somewhere/, and likely one we can detect for the time being.

[oe]

Processing doesn't have to be real-time

[taneq]

It does if you want to catch everything that might be important.

[edf13]

What if...

- The audio packets aren't recorded from the Fb App?

What if...

- The audio packets aren't then sent to Fb?

Fb only buys this data + integrates = problem solved

[taneq]

If both of those are true then your concern is of the form "ANY party records audio data and sells it".

Which is why we don't want random apps having permanent mic access. Or permanent anything access. This is why data mining is bad, not just because the party doing the mining can get the data, but because they can sell it to third parties who combine it in unexpected ways to leak data that you really don't want to be public.

[edf13]

It's all about consent... if you give consent that's fine.

It's when an App goes behind your back and does it (And then sells it on) then it's bad.

[taneq]

Totally agree. Although now might be a good time to raise the issue that "an obfuscated single-line mention buried in a 60-page clickwrap license presented in an 80x4 character window resulting in over 9000 pages of bullshit that you can't possibly realistically read does not 'consent' make".