Network Hacks

229 Articles

Accessing A PBX Through Voice Channels

June 7, 2015 by 9 Comments

[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.

Diagram of Packets Sent by Timeshifter

Encoding Data In Packet Delays

May 28, 2015 by 25 Comments

If you’ve ever been to a capture the flag hacking competition (CTF), you’ve probably seen some steganography challenges. Steganography is the art of concealing data in plain sight. Tools including secret inks that are only visible under certain light have been used for this purpose in the past. A modern steganography challenge will typically require you to find a “flag” hidden within an image or file.

[Anfractuosus] came up with a method of hiding packets within a stream of network traffic. ‘Timeshifter’ encodes data as delays between packets. Depending on the length of the delay, each packet is interpreted as a one or zero.

To do this, a C program uses libnetfilter_queue to get access to packets. The user sets up a network rule using iptables, which forwards traffic to the Timeshifter program. This is then used to send and receive data.

All the code is provided, and it makes for a good example if you’ve ever wanted to play around with low-level networking on Linux. If you’re interested in steganography, or CTFs in general, check out this great resource.

Header of the Project Byzantium website

Meshing Pis With Project Byzantium

April 28, 2015 by 38 Comments

If internet service providers go down, how are we going to get our devices to communicate? Project Byzantium aims to create an “ad-hoc wireless mesh networking for the zombie apocalypse.” It’s a live Linux distribution that makes it easy to join a secure mesh network.

[B1tsh1fter] has put together a set of hardware for running Byzantium on Pis in emergency situations. A Raspberry Pi 2 acts as a mesh node, using a powerful USB WiFi adapter for networking. Options are provided for backup power, including a solar charger and a supercapacitor based solution.

The Pi runs a standard Raspbian install, but uses packages from the ByzPi repository. This provides a single script that gets a Byzantium node up and running on the Pi. In the background, OLSR is used to route packets through the mesh network, so that nodes can communicate without relying on a single link.

The project has a ways to go, but the Raspberry Pi based setup makes it cheap and easy to get a wide area network up and running without relying on a single authority.

File Sharing In Your Pocket

February 26, 2015 by 43 Comments

The idea of a pirate box is pretty simple. All you need is a tiny Linux system with a WiFi adapter, a bit of storage space, and the software that will allow anyone to upload a few files to the server and an interface that will let anyone on the network download those files. In practice, though, a pirate box is a mess of wires and power adapters – not the pocketable device a WiFi file sharing box should be.

[Chris] came up with a much smaller file sharing beacon. It’s not based on a router; instead, [Chris]’ build uses an ez Share WiFi microSD adapter. It’s a device meant to push pics taken by a digital camera up to the Internet, but by configuring the software just so, up to five users can connect to the adapter and pull files down from a microSD card. The build only requires putting power to the correct pins. A LiPo battery and charge controller takes care of this problem.

There are a few shortcomings to this project – [Chris] doesn’t know how to upload files to the device. Maybe someone sufficiently clever can figure out how to make that work. Still, if you’re ever in a situation where you’d like to share some files with people in the same building, this is the device you need.

Thanks [Jake] for the tip.

switchboard

Bypassing Broken SIP ALG Implementations

January 11, 2015 by 15 Comments

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.

Bridging Networks With The Flip Of A Switch

November 16, 2014 by 14 Comments

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.

Protocol Snooping Digital Audio

November 12, 2014 by 21 Comments

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.