3 ms·

I have seen this article a few times, and there's enough wrong info in it that it makes me question the rest of its claims: - The article confuses FireWire and

by kop316 5y ago

I have seen this article a few times, and there's enough wrong info in it that it makes me question the rest of its claims: - The article confuses FireWire and USB in the last paragraph. USB, to my knowledge, doesn't do DMA, while FireWire does. (USB-C can if it has thunderbolt, but Linux phones don't have thunderbolt). The article then references this link for why USB is bad: https://madaidans-insecurities.github.io/linux.html https://madaidans-insecurities.github.io/linux.html (here's an archived link: https://web.archive.org/web/20210903200926/https://madaidans-insecurities.github.io/linux.html https://web.archive.org/web/20210903200926/https://madaidans... ) But a crtl+f "USB" comes out empty. - While the accelerometer hack is theoretically possible, it's practically infeasible, EVEN if the accelerometer takes measurements above 4 KHz (being extremely generous here, you probably really want close to 8-10 KHz). But you need that high of a sampling rate to overcome Nyquist. Accelerometer are much closer to 100-500 Hz, so Nyquist will tell you that theorically, you can only recover audio data below 250 Hz. I'm all for discussing security tradeoffs with Linux Phones vs Android vs iOS, but seeing those two issues alone makes me question the other claims that I don't have knowledge about. Edit: For a paper on using an accelerator as a microphone: https://crypto.stanford.edu/gyrophone/files/gyromic.pdf https://crypto.stanford.edu/gyrophone/files/gyromic.pdf So on this paper looking at it, the experiment is done where the speakers are at 75 dB and the phone is one foot away (See Section 3.4). 75 dB looks to be about as loud as a vacuum cleaner. The phone is also completely still, so there is no other data that is being recorded besides (very loud) audio.

concinds 5y ago
> The article confuses FireWire and USB in the last paragraph. I believe he's not; the paragraph about USB and the one about FireWire are separate ones. And his point that kernel isolation of the modem is flawed because of properties of the Linux kernel seem accurate, though I don't have the expertise to confirm that (you'd need to ctrl+f "kernel", not "USB", since the point is a general one)
- kop316 5y ago
  So why bring in FireWire at all to the argument? Why not give USB examples? Giving the benefit of the doubt, the writing is extremely unclear and, to me, gives the impression of a comparison between the two. Same with referring to the other article, there's a general link to another article, where the reader is left guessing where they are making the point. To me, if you reference an article in this manner: "Linux kernel USB stack which is not a strong barrier as shown in the Linux article" I would expect the linked article to reference....well the USB stack, or USB in general. Or reference what section you mean, or quote it and bring it in to the article.
foxfluff 5y ago
Following the leads, DOI:10.1145/2742647.2742658 says the accelerometer in Apple iPhone 6, Google Nexus 5 and Samsung Galaxy S5 supports 4kHz sampling. However, the OS limits it to 200Hz to conserve power. Googling around, it appears there are accelerometers with much higher bandwidths. Here's how 8 bps mono speech at 4kHz sounds like: https://vocaroo.com/102J6NRULedu https://vocaroo.com/102J6NRULedu (download link: http://fpaste.dy.fi/oyU/dl http://fpaste.dy.fi/oyU/dl) Sounds pretty good. At 2kHz it gets a bit hard to listen to but I can still understand a fair proportion of it. I imagine it shouldn't be too hard to come up with an algorithm (or neural net) to resynthesize the higher frequencies and make it easier to understand. 2kHz sample: https://vocaroo.com/18F3LkYrsPNQ https://vocaroo.com/18F3LkYrsPNQ (download: http://fpaste.dy.fi/rvy/dl http://fpaste.dy.fi/rvy/dl) (Obviously these are not accelerometer recordings, just normal microphone recordings downsampled with sox) I agree it's a bit silly complaint though. I see it a lot in security circles: if some feature doesn't give you perfect protection against all possible attacks, it's a problem. At the same time, the same people advocate mitigations and techniques that only apply to certain attacks. It's as if there's no silver bullet, but it's a damn shame if you deploy something that isn't a silver bullet!
- kop316 5y ago
  https://crypto.stanford.edu/gyrophone/files/gyromic.pdf https://crypto.stanford.edu/gyrophone/files/gyromic.pdf So on this paper looking at it, the experiment is done where the speakers are at 75 dB and the phone is one foot away (See Section 3.4). 75 dB looks to be about as loud as a vacuum cleaner. The phone is also completely still, so there is no other data that is being recorded besides (very loud) audio. Good to know about the various phones though. I'm honestly not sure why such a high sample rate is even needed/wanted (though in the paper, it is mentioned that there are ones with much lower sampling rates, so if this is a real concern, populate you device with a chip with a lower sampling rate).
  - genewitch 5y ago
    The higher the sample rate the more fine grained movement it can detect, and, with decimation, the better the signal to noise ratio. MEMS stuff is really noisy because they're mechanical stuff is wobbly enough and the ADCs are pretty sensitive since the mechanical stuff is so small.

by kop316 5y ago

concinds 5y ago

> The article confuses FireWire and USB in the last paragraph. I believe he's not; the paragraph about USB and the one about FireWire are separate ones. And his point that kernel isolation of the modem is flawed because of properties of the Linux kernel seem accurate, though I don't have the expertise to confirm that (you'd need to ctrl+f "kernel", not "USB", since the point is a general one)

kop316 5y ago
So why bring in FireWire at all to the argument? Why not give USB examples? Giving the benefit of the doubt, the writing is extremely unclear and, to me, gives the impression of a comparison between the two. Same with referring to the other article, there's a general link to another article, where the reader is left guessing where they are making the point. To me, if you reference an article in this manner: "Linux kernel USB stack which is not a strong barrier as shown in the Linux article" I would expect the linked article to reference....well the USB stack, or USB in general. Or reference what section you mean, or quote it and bring it in to the article.

foxfluff 5y ago

Following the leads, DOI:10.1145/2742647.2742658 says the accelerometer in Apple iPhone 6, Google Nexus 5 and Samsung Galaxy S5 supports 4kHz sampling. However, the OS limits it to 200Hz to conserve power. Googling around, it appears there are accelerometers with much higher bandwidths. Here's how 8 bps mono speech at 4kHz sounds like: https://vocaroo.com/102J6NRULedu https://vocaroo.com/102J6NRULedu (download link: http://fpaste.dy.fi/oyU/dl http://fpaste.dy.fi/oyU/dl) Sounds pretty good. At 2kHz it gets a bit hard to listen to but I can still understand a fair proportion of it. I imagine it shouldn't be too hard to come up with an algorithm (or neural net) to resynthesize the higher frequencies and make it easier to understand. 2kHz sample: https://vocaroo.com/18F3LkYrsPNQ https://vocaroo.com/18F3LkYrsPNQ (download: http://fpaste.dy.fi/rvy/dl http://fpaste.dy.fi/rvy/dl) (Obviously these are not accelerometer recordings, just normal microphone recordings downsampled with sox) I agree it's a bit silly complaint though. I see it a lot in security circles: if some feature doesn't give you perfect protection against all possible attacks, it's a problem. At the same time, the same people advocate mitigations and techniques that only apply to certain attacks. It's as if there's no silver bullet, but it's a damn shame if you deploy something that isn't a silver bullet!

kop316 5y ago
https://crypto.stanford.edu/gyrophone/files/gyromic.pdf https://crypto.stanford.edu/gyrophone/files/gyromic.pdf So on this paper looking at it, the experiment is done where the speakers are at 75 dB and the phone is one foot away (See Section 3.4). 75 dB looks to be about as loud as a vacuum cleaner. The phone is also completely still, so there is no other data that is being recorded besides (very loud) audio. Good to know about the various phones though. I'm honestly not sure why such a high sample rate is even needed/wanted (though in the paper, it is mentioned that there are ones with much lower sampling rates, so if this is a real concern, populate you device with a chip with a lower sampling rate).
- genewitch 5y ago
  The higher the sample rate the more fine grained movement it can detect, and, with decimation, the better the signal to noise ratio. MEMS stuff is really noisy because they're mechanical stuff is wobbly enough and the ADCs are pretty sensitive since the mechanical stuff is so small.