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.
The TP-Link TL-WR703n is the WRT54G for the modern era – extremely hackable, cheap, and available just about everywhere. Loaded up with OpenWRT, it’s capable of bridging networks: turning Ethernet into WiFi and vice versa. This requires reconfiguring the router, and after doing this enough times, [Martin] was looking for a better solution. The SOC inside the WR703n has two exposed GPIO pins, allowing [Martin] to choose between WiFi access point or client and between bridged or NAT/DHCP.
According to the OpenWRT wiki, there are a few GPIOs available, and after connecting these pins to a DIP switch, [Martin] could access these switches through the firmware. The hard part of this build is building the script to change the settings when the system boots. This script looks at the state of the GPIOs and changes the WiFi into client or access point mode and tries not to muck about with the DHCP somewhere off in the cloud. Yes, we just used cloud in its proper context.
The only other hardware to complete this build was a simple USB to serial converter that should be shoved into the corner of everyone’s workbench. Not bad for an extremely minimal soldering and configuration required for a something that’s extremely useful.
More and more clubs are going digital. When you go out to hear a band, they’re plugging into an ADC (analog-to-digital converter) box on stage, and the digitized audio data is transmitted to the mixing console over Ethernet. This saves the venue having to run many audio cables over long distances, but it’s a lot harder to hack on. So [Michael] trained popular network analysis tools on his ProCo Momentum gear to see just what the data looks like.
[Michael]’s writeup of the process is a little sparse, but he name-drops all the components you’d need to get the job done. First, he simply looks at the raw data using Wireshark. Once he figured out how the eight channels were split up, he used the command-line version (tshark) and a standard Unix command-line tool (cut) to pull the data apart. Now he’s got a text representation for eight channels of audio data.
Using xxd to convert the data from text to binary, he then played it using sox to see what it sounded like. No dice, yet. After a bit more trial and error, he realized that the data was unsigned, big-endian integers. He tried again, and everything sounded good. Success!
While this is not a complete reverse-engineering tutorial like this one, we think that it hits the high points: using a bunch of the right tools and some good hunches to figure out an obscure protocol.
When you’re at HOPE, of course you’re going to see a few Tor proxies, but [Jose]’s is top-notch. It’s a completely portable Tor proxy (.br, Google translation), battery-powered, with a connection for 4G networks.
[Jose]’s OnionPi setup is based on the Adafruit version, but adds a few interesting features that make it even more useful. It’s battery-powered with about a day of charge time, has a built-in battery charger, Ethernet pass through, external 4G and WiFi antennas, all in a sealed case that makes the entire build impervious to the elements.
While this isn’t much of a hack per se, the amount of integration is impressive. There are switches to turn off each individual networking port, and all the relevant plugs are broken out to the front panel, with the AC input and USB serial connection using screw connectors that are supposedly very popular in Brazil.
[Jose] also brought along a new device that isn’t documented anywhere else on the web. It’s called NNCFA, or Nothing New Crypto For All. Using a Cubieboard, an interesting ARM single board computer with a SATA connector, [Jose] created a device that will mount TrueCrypt volumes on a hard drive and share them via Samba.
The Electronic Frontier Foundation have released an alpha of their own Open Wireless Router Firmware as part of the Open Wireless Movement. This project aims to make it easier to share your wireless network with others, while maintaining security and prioritization of traffic.
We’ve seen a lot of hacks based on alternative router firmware, such as this standalone web radio. The EFF have based their router firmware off of CeroWRT, one of the many open source firmware options out there. At this time, the firmware package only targets the Netgear WNDR3800.
Many routers out there have guest modes, but they are quite limited and often have serious vulnerabilities. If you’re interested in sharing your wireless network, this firmware will help out by letting you share a specified amount of bandwidth. It also aims to have a secure web interface, and secure auto-update using Tor.
The EFF has announced this “pre-alpha hacker release” as a call for hackers who want to join in the fun. Development is happening over on Github, where you’ll find all of the source and issues.
A surprising number of projects here are in some way influenced by the webcomic xkcd, but usually not as directly as this. Comic 350, “Network” is the tale of a very odd stickman who keeps multiple VMs running an unprotected, old version of Windows. Between the VMs, they have virtually every virus and are, effectively, a computer virus aquarium.
Now it’s a real thing, and best of all, it’s open to the Internet for normal humans to view, complete with screencaps of all seven nodes updated every 30 seconds, the ability to view all processes on each node, and anyone on the Internet can upload any file to a node. All the files uploaded to the nodes are executed, so you get to see in real-time what the effects of “1TB_of_porn_this_took_a_while_to_upload.exe” are on node 3.
The idea of a virus aquarium is cool, but this actually gets much, much more interesting when the project metas itself. Every 24 hours, a virus scanner runs on each node. As of right now, all the nodes are clean making this not a virus aquarium, but a script kiddie aquarium. On at least one node, TeamViewer is running but your guess is as good as mine as to how anyone will get that working.
Continue reading “xkcd’s Virus Aquarium Made Real”
The D-Link DSP-W215 Smart Plug, a wireless home automation device for monitoring and controlling electrical outlets has just been hacked. Even though it isn’t readily available from Amazon or Best Buy yet, the firmware is already up on D-Link’s web site. The very well detailed write-up explains all the steps that led to this exploit creation.
First, the firmware was unpacked to examine the file system contents. It was found that the smart plug doesn’t have a normal web-based interface as users are expected to configure it using D-Link’s Android/iOS app. The apps however, appear to use the Home Network Administration Protocol (HNAP) to talk to the smart plug running a lighthttpd server. A look at the latter’s configuration file revealed the functions that could be called without any authentication. Another revealed that the firmware could accept an unlimited amount of POST request bytes which were copied in a fix length buffer without any performed checks. We’ll let our readers head to the original article to see where the author went from this point.