Here’s a puzzler for you: If you’re phreaking something that’s not exactly a phone, are you still a phreak?
That question probably never crossed the minds of New Yorkers who were acoustically assaulted on the normally peaceful sidewalks of Manhattan over the summer by creepy sounds emanating from streetside WiFi kiosks. The auditory attacks caused quite a stir locally, leading to wild theories that Russian hackers were behind it all. Luckily, the mystery has been solved, and it turns out to have been part prank, part protest, and part performance art piece.
To understand the exploit, realize that New York City has removed thousands of traditional pay phones from city sidewalks recently and replaced them with LinkNYC kiosks, which are basically WiFi hotspots with giant HDTV displays built into them. For the price of being blitzed with advertisements while strolling by, anyone can make a free phone call using the built-in VOIP app. That was the key that allowed [Mark Thomas], an old-school phreak and die-hard fan of the pay telephones that these platforms supplanted, to launch his attack. It’s not exactly rocket surgery; [Mark] dials one of the dozens of conference call numbers he has set up with pre-recorded audio snippets. A one-minute delay lets him crank the speakerphone volume up to 11 and abscond. The recordings vary, but everyone seemed most creeped out by the familiar jingle of the [Mr. Softee] ice cream truck franchise, slowed down and distorted to make it sound like something from a fever dream.
Yes, it’s a minimal hack, and normally we don’t condone the misuse of public facilities, even ones as obnoxious as LinkNYC appears to be. But it does make a statement about the commercialization of the public square, and honestly, we’re glad to see something that at least approaches phreaking again. It’s a little less childish than blasting porn audio from a Target PA system, and far less dangerous than activating a public safety siren remotely.
Continue reading “Manhattan Mystery of Creepy Jingles and Random Noises Solved”
Morse code qualifies as a digital mode, although organic brains are somewhat better at copying it than electronic ones. Ham radio operators that did “phone” (ham-talk for voice) started out with AM modulation. Sometime after World War II, there was widespread adoption of single side band or SSB. SSB takes up less bandwidth and is more reliable than AM modulation. On the digital side, hams turned to different and more sophisticated digital transmission types with computers pushing bandwidth down and reliability up. However, a recent trend has been to encode voice over ham radio–sort of VoIP with radio instead of Ethernet–using an open source program called freedv.
[AA6E] made a very informative video where he carries on a QSO (a conversation) with a distant station using freedv. What makes it interesting, is towards the end when the two stations switch to regular SSB. The difference is dramatic and really points out how even with less bandwidth (roughly 3 kHz for SSB vs 1.25 kHz), the digital mode is superior. The freedv software (available for Windows or Linux) compresses audio to 700-1600 bits per second and spreads it over 16 QPSK signals.
Continue reading “Hams Talk Digital”
[Alessandro] is an unlucky VoIP PBX administrator that frequently has to deal with very, very dumb network policies. Often times, he’ll have to change something on his setup which requires him to go out to his client’s location, or ask a client to use Teamviewer so the appropriate change can be made from behind a firewall.
This isn’t the solution to the problem. It will, however, fix the problem. To get around these firewalls, [Alessandro] is using the voice channels he already has access to for changing configurations on his VoIP boxes.
The implementation of this uses the AX.25 amateur radio modules that can be found in just about every Linux distro. This, and an Alsa loopback device, allows [Alessandro] to access a terminal over a voice-only network. Is it a hackey kludge? Yep. Is it just a little bit dumb? So are the network policies that don’t allow [Alessandro] to do his job.
This build isn’t too dissimilar than a bunch of modems from the old BBS days, albeit with vastly more powerful software. [Alessandro] says you’re only going to get about 38400bps out of this setup, but it beats begging for help for remote access.
There’s something so nostalgic about the rotary phone that makes it a fun thing to hack and modernize. [Voidon] put his skills to the test and converted one to VoIP using a Raspberry Pi. He used the RasPi’s GPIO pins to read pulses from the rotary dial – a functional dial is always a welcome feature in rotary phone hacks. An old USB sound card was perfect for the microphone and handset audio.
As with any build, there were unexpected size issues that needed to be worked around. While the RasPi fit inside the case well, there was no room for the USB power jack or an ethernet cable, let alone a USB power bank for portability. The power bank idea was scrapped. [voidon] soldered the power cord to the RasPi before the polyfuse to preserve the surge protection, used a mini-USB wifi dongle, and soldered a new USB connector to the sound card. [Voidon] also couldn’t get the phone’s original ringer to work, so he used the Raspberry Pi’s internal sound card to play ringtones.
The VoIP (SIP) was managed by some Python scripting, available at GitHub. [voidon] has some experience in using Asterisk at his day job, so it will be interesting to see if he incorporates it in the future.
The SIP protocol is commonly used for IP telephone communications. Unfortunately it’s notorious for having issues with NAT traversal. Even some major vendors can’t seem to get it right. [Stephen] had this problem with his Cisco WRVS4400N router. After a bit of troubleshooting, he was able to come up with a workaround that others may find useful.
The router had built in SIP ALG functionality, but it just didn’t work. [Stephen] was trying to route SIP traffic from a phone to an Asterisk PBX system behind the router. The router just couldn’t properly handle these packets regardless of whether SIP ALG was enabled or disabled.
[Stephen] first tried to change the SIP port on the external VOIP phone from the default of 5060 to something else. Then he setup port forwarding on the router to the Asterisk box to forward the traffic to the Asterisk system on the original port. This sort of worked. The calls would go through but they would eventually drop after about 20 seconds.
The only thing that [Stephen] could get to work completely was to change the SIP port in Asterisk’s sip.conf file using the “bindport” directive. He changed it to some random unused high port number. Then he setup port forwarding on the router to forward incoming UDP packets on that port to the Asterisk system. This worked fine, but now all of the original phones behind the router stopped working because they were configured to use the default port of 5060.
Rather than re-configure all of the phones in the organization, [Stephen] made one change on the Asterisk system. He setup an iptables rule to forward all incoming traffic on UDP port 5060 to the new SIP port. Now all of the phones are working with minimal changes across the organization. It’s a lot of hassle to go through just because the router couldn’t handle SIP correctly, but it gets the job done.
[Daniel] picked up a cheap USB handset to use with his VoIP provider, and included in the box was a CD with all the software that would make this handset work with Windows. [Daniel] is running Linux on his main battlestation, rendering the included CD worthless. Using the handset under Linux would be a problem; although the speaker and mic worked, the buttons and screen did not. No problem, then: [Daniel] just played around with the command line until he figured it out.
The handset presented itself to the Linux box as a soundcard and HID device. The soundcard was obviously the speaker and mic, leaving the buttons and display as the HID device. [Daniel] checked this out by running a hexdump on the HID device and pressed a few buttons. His suspicions were confirmed, and he could easily read the button with a little bit of Python.
With the speaker, mic, and buttons on the handset figured out, [Daniel] turned his attention to the one bit of electronics on the phone he hadn’t yet conquered: the display. After firing some random data at the phone, the display blinked and showed a messy block of pixels, confirming the display was controlled through the HID driver. Loading up usbsnoop to see what the original software does to update the screed showed [Daniel] the data format the display accepts, allowing him to control everything in this VoIP phone.