In the old days, spies eavesdropped on each other using analog radio bugs. These days, everything’s in the cloud. [Sebastian] from [Hacking Beaver] wondered if he could make a WiFi bug that was small and cheap besides. Enter the ESP8266 and some programming wizardry.
[Sebastian] is using a NodeMCU but suggests that it could be pared down to any ESP8266 board — with similar cuts made to the rest of the electronics — but has this working as a proof of concept. A PIC 18 MCU samples the audio data from a microphone at 10 kHz with an 8-bit resolution, dumping it into a 512-byte buffer. Once that fills, a GPIO pin is pulled down and the ESP8266 sends the data to a waiting TCP server over the WiFi which either records or plays the audio in real-time.
[Sebastian] has calculated that he needs at least 51.2 ms to transfer the data which this setup easily handles, but there are occasional two to three second glitches that come out of the blue. To address this and other hangups, [Sebastian] has the ESP8266 control the PIC’s reset pin so that the two are always in sync.
The main hurdle was using an SPI on the ESP8266 — every time the PIC attempted to hand off 512 bytes of data, the ESP would reset! After a number of different attempts, [Sebastian]’s solution was to bitbang the SPI, slowing down the transfer but without crashing. Result! We wonder how far he could push this with a little data compression before sending over WiFi.
The only question now is whether or not you need to start smashing any nearby speakers for fear of being listened to. Even if you manage that, there are still a few old-school methods to keep an ear out.
He could easily do adpcm to cut the bitrate in half with little processing overhead and probably entropy encode it from there. Probably can’t do anything with the complexity of mp3 encoding, though its powerful enough for mp3 decoding.
He could also use an I2S microphone, then he probably wouldn’t need the PIC18.
Heck, There’s I sitting here thinking about how he could simply add an i2c-DSP,
You’ve hit the simplicity nail not only on the head, but straight to the point first time!
“In the old days, spies eavesdropped on each other using analog radio bugs. These days, everything’s in the cloud. ”
Turning cellphones into a bug.
no need to plant anything suspicious when everyone already carries an always-on snooping device with them BY CHOICE.
@HAT says: “no need to plant anything suspicious when everyone already carries an always-on snooping device with them BY CHOICE.”
I say: no need to plant anything suspicious when [almost] everyone already carries an always-on snooping device with them BY IGNORANCE.
Not sure about eavesdropping on SKYPE over Wi-Fi. I know the USG was really worried about that a few years back as the original inventors of SKYPE in Estonia built in Rijndael encryption at the UI level and also made it a peer-to-peer Internet propagation methodology which really confounded many intelligence agencies as well as the Russians.
But ever since Microsoft purchased it, they really gutted it severely taking out much of it’s hardening assisting American intelligence agencies to listen in now. Most bad guys would go next to an open Wi-Fi hotspot and fire up SKYPE to phone home world wide (SKYPE to SKYPE hardened with Rijndael, however SKYPE to PSTN not so much). SKYPE was/is a Wi-Fi bandwidth hog so highly detectable. However, at one time no one could listen in, even someone on the same LAN. Now I do not know.
I don’t suggest you use SKYPE over Wi-Fi as part of your OPSEC today. It may be very insecure these days.
https://www.schneier.com/blog/archives/2013/01/who_does_skype.html
Who said anything about Skype?
>The main hurdle was using an SPI on the ESP8266 — every time the PIC attempted to hand off 512 bytes of data, the ESP would reset! After a number of different attempts, [Sebastian]’s solution was to bitbang the SPI, slowing down the transfer but without crashing.
Those Tensilica MCUs are kinda shit, innit?
I’d bet my bottom dollar it was causing the watchdog to time out.
If you use too many resources for too long time, the WiFi-core will stop working and may trigger a reset – you need to plan for this in software that the WiFi-part of the code gets attention as well. It’s not a fault of the hardware.
This! WiFi must be serviced every 50 ms, and he even calculates out that his big packet is taking 51.6 ms (or whatever). I put my money here. Just send shorter packets from the PIC?
Hi,
I’m [Sebastian], the guy that created the project.
I’m reading inside the ESP the 512 bytes of SPI data from the PIC in a task.
With bitbanged SPI, this reading of 512 bytes takes ~13ms.
When I tried to use the hw SPI, this read operation should have taken much less time, but the ESP would just reset when reading the SPI data.
Also for sending over WI-FI the 512 bytes of data, I don’t keep the ESP blocked.
That’s the time that I measured between calling the data send function (non-blocking) and the callback that the data was sent.
This is why I think the watchdog reset doesn’t fit.
Thank you for your intereset in the project! :)
[mr burns] ooo! and we could mine these data with the latest AI…
The project uses a ADC with SPI interface to sample the microphone. But an I2S microphone would be even cooler.
https://hackaday.com/2016/07/15/baby-monitor-rebuild-is-also-esp8266-audio-streaming-how-to/
I looked at this and said, “why the PIC”. I am sure this can all be done with just the ESP8266. I’ll put it on my project list.