6 ms·
One nefarious method malware could use to get data off the device without RF would be to play sub 20kHz audio through the speakers, assuming there was a device
by milesokeefe 10y ago
One nefarious method malware could use to get data off the device without RF would be to play sub 20kHz audio through the speakers, assuming there was a device with a microphone near by that's able to receive the signal, and of course that the speakers can play a frequency that low.
Along the same lines, but only successful if the user isn't looking, would be to use the flashlight LED.
Or maybe very short low power vibrations, if the receiving microphone is on the same surface.
All of these require somewhat particular situations, but fun to think about in any case :)
- cobbzilla 10y agoyup, there are lots of non-EMF ways to get data off a device. iirc it's easier to transmit data with higher (inaudible) frequencies than lower ones.
- brian-armstrong 10y agoIf anyone would like to see this in action, try this out on your laptop https://quiet.github.io/quiet-js/ https://quiet.github.io/quiet-js/ </plug>
- tripzilch 10y agoCool! I always wondered what the accuracy/success rate of such a sidechannel would be, nice that your tool allows me to test this easily :) Interestingly enough, after some fiddling I could get it from my speakers to phone mic, and phone speakers to laptop mic, but only in the audible spectrum, not in the ultrasonic. Only response I got was one time, an error--probably one packet that failed the CRC check, but the rest of the time nothing. I didn't have time to mess with the code and try different modulation frequencies yet. But it's definitely a cool toy! :D
- brian-armstrong 10y agoWould you mind sharing details about your setup? I assume you have an Android phone since in mobile Safari you can't access the mic, full stop. I'm also curious to hear what the error was. Do you mean an error occurred in the JS console? That isn't supposed to happen in any event. If you want to more thoroughly test, try https://quiet.github.io/quiet-profile-lab https://quiet.github.io/quiet-profile-lab although it's worth noting that this tool can only work on one device, transmitting to itself Finally, it's intended to be a production library, not just a toy ;) edit: it's worth noting that if your receiver is Firefox, you'll never get anything from ultrasonic. That's because firefox resamples to 32kHz, cutting off any frequencies above 16kHz
- tripzilch 10y agoMy apologies for calling it a toy!! ;-) Still fun to play with though ;-) I used Chromium Linux on the laptop and and Chrome for Android on the phone end. I normally use Firefox as my main browser but I opted for Chrome because I assumed it was a PoC and you'd need a lot of uninteresting work to make it smoothly cross-browser and most people here develop for Chrome first--I'd save that effort for the weaponised exploit ;) Or production library, in your case ;) (what is the use case there btw?) Thanks for the heads-up on Firefox's resampling, so I know not to try that ;) Wonder if they chose that for security reasons? Seems a solid protection exactly against this. If so, then comes the question how good their lowpass (resampling) filter is, if nothing leaks through and you can't secretly grab ultrasonics anyhow via longer statistical methods trying to infer which freqs are aliased and which aren't :) So, I tried the audible signal first, to be sure it was making sound (I have my Firefoxes locked down rather tightly, JACK and PulseAudio often fight, so unless it's a mediaplayer or audio-production tool, it doesn't make sound usually). But Chromium did (after re-enabling Pulse). I got decent results for both ways (sometimes partial text, I didn't try images), so recording worked too and the multimedia JS code seems to work fine. One idea on that end; And I never wrote JS audio (I plan to, though) so I don't know if this is hard, but maybe next to the "listen" buttons, you could add a simple VU-meter bar for the mic, so I can clap my hands and check if the mic is indeed receiving (maybe your profile-lab already does this, havent checked). The error I saw looked like an intentional popup-message you wrote in the code. It was a modal DIV popup, styled like the site, more like a debug message perhaps. I didn't quite understand it, so I don't remember it exactly: that it received 1/100 packets, and failed checksum ... sorry I can't be more specific, I only saw it once. It seemed to indicate it detected one packet but it was an incorrect one, or something similar. Given the config mentions CRC checks, I assumed it was that. I didn't check the JS console for messages, but the behaviour of the site didn't indicate to me that there were actual JS errors. Extra info: The sound from Chromium Linux was played through high quality large speakers, the microphone is built-in (Eee 1215B netbook, rather old thingy) so probably not very good. On the phone side, it's running Cyanogenmod on a Samsung S4. I believe the mic on the phone is better than on the laptop because it's rather old and quite noisy. Is there a reason the profile-lab tool only works for one device transmitting to itself? Cause that's part of the fun (yeah yeah no toy :p), transmitting data between two devices that have no connection to each other. If I was to be thorough, I'd set it to airplane mode just to prove the fact :) I'll have another play with quiet.js and also the quit-profile-lab. If I see the error message again or find anything I didn't describe above, I'll report back. If you got any specific things you'd like me to test, let me know.
- eon1 10y agoIt would be around/above 20KHz, not below; our hearing is theoretically ~20Hz-20KHz (though almost noone starts out actually able to hear that high and the high frequencies decrease with age). AD/DA converters will also apply a low pass filter below Nyquist to prevent aliasing - assuming they are operating at 44.1/48KHz (and even if they are spec'd higher there's no real reason they'd always be running the higher rate), Nyquist is about 21KHz, though filtering lower than that is beneficial as it allows them to employ a less steep slope on (very steep filter slopes can create artifacting of their own). The small speaker set up in your average phone would be quite capable of outputting 18-19KHz, which is still outside most people's hearing range, and unless you're particularly attuned to high frequency audio you might not notice or work out what it was anyway.
- tripzilch 10y ago> One nefarious method malware could use to get data off the device without RF would be to play sub 20kHz audio through the speakers, assuming there was a device with a microphone near by that's able to receive the signal, and of course that the speakers can play a frequency that low. did you mean to say "sub 20 Hz"? or rather the ultrasound between 20kHz and 22kHz? it's a bit ambiguous cause both 20 Hz and kHz are lower and upper ranges of human hearing, respectively. if you meant the lower, then no. mobile speakers already almost entirely lack power in the musical bass frequencies (50-150Hz roughly), let alone the infrasonic ones. if the speaker would even have a response to such a signal, it's not going to have a lot of range. .. a sub-20Hz audio signal has a wavelength of more than 17 metres in air, I'm not sure if that's physically impossible, but I'm having a hard time imagining that tiny tweeter to manage such a signal (my knowledge is mostly with digital signal processing, not entirely sure about what speakers can do, Bose has done some pretty amazing room-shaking bass with very clever tiny speakers, that seemed impossible to me as well, has to be some trick there). And then, doing it without getting harmonics in the audible spectrum! :)