In our digital age prying eyes are everywhere. The sad thing is that they may even belong to your own government. But no matter who it is, there are some things you can do to keep your private digital devices and content as secure as possible.

The link above goes to [Jerry Whiting's] discussion on the topic. He’s certainly an interesting speaker, but make sure you’re using headphones at work as the language can be a bit sultry once in a while. He aims the lesson at the Occupy movement, but it’s a fun listen for any conspiracy theorist out there. The topics run the gamut, starting with the specter of physical access, then moving on to protecting your network through traffic analysis and using key pairs. This Security 101 segment comes in two parts (the first one is embedded after the break), each a bit more than thirty minutes. He’s planning to post a second lesson covering hashes and encryption.

NSFW: Language

[Michael Ossmann] came up with a nifty little device that arranges RJ45 plugs into a plus shape for the intent of sniffing Ethernet packets, and named it the “Throwing Star LAN Tap”. While the original design worked fine it does suffer some limitations such as being limited to 10/100 base networks, and one way only. This new version of the “Throwing Star LAN Tap” fixes those and adds some much needed convenience.

Gone are the male plugs, which requires couplers and are prone to break, and fiddly splices in favor of a throwing star shaped pcb, and female sockets. 1000 base networks are supported, but due to the workings of 1000 base and wanting to keep the device passive, capacitors are added to filter out the signal and force the network to drop down to 100 base. Sure, it may be an ugly hack, but it’s an ugly hack that fits in your pocket.

Here’s a chance to learn a little bit about network security. This article walks us through some of the core concepts of network manipulation and packet sniffing using Linux tools. [Joey Bernard] discusses the uses for packages like tcpdump, p0f, and dsniff. They are capable of recording all network traffic coming through your computer’s connection, seeking out machines installed on the network, and listening to traffic for a specific machine. This isn’t going to give you a step-by-step for cracking modern networks. It will provide some insight on what is going on with your network and you should be able to purpose these tools to check that you’ve got adequate security measures in place.

[Aram Bartholl] is building his own filesharing network that screws those fat cats who want to control your freedom. He’s added file cache devices throughout NYC (five so far but more to come) that are anonymous and free to use. Upload what you want, download what you want. They’re completely offline which means monitoring who’s doing what gets a lot harder and quite possibly requires a warrant from a Judge (we’re obviously not legal experts, your mileage may vary).

As for the slew of comments that are sure to point out the dangers of malicious USB device; We think everyone knows they’re taking on some risk when connecting to a USB plug protruding from a brick wall.

[Thanks Neckbeard]

Wanting to save space and weight on his project build [Florin] set out to find a way to add Ethernet connectivity without the magnetics. His ill-advised first try involved directly coupling two switches, frying both in the process. After some research he found that Ethernet hardware manufacturers have considered the need for devices without the magnetics and there are several application notes available on the subject. [Florin] followed the information that Realtek has for their devices and learned that they can be couple capacitively. After depopulating the magnetics from a second pair of switches he wired up some resistor-capacitor networks on a breadboard and got the connecting to work.

It’s no secret that the central US is feels like a very humid oven right now. [Erik's] window AC hack might help you out if you’re coping with triple-digit temperatures. He added network connectivity to the unit above but the picture is a bit deceiving. The blue CAT-5 cable that enters the bottom isn’t connecting directly to the network, but extends the up and down button connections for the unit to an external relay board. From there he uses an SNMP board to connect it to the network and uses PHP commands to reset the temperature. The unit has a working range of 66-88 degrees Fahrenheit so he cycles enough button press to reach the maximum or minimum level, then sets the desired temperature (avoiding the need to know what temperature the unit is currently set at).

If you’ve got an AC unit with a remote control you could always use an IR device to patch into the system for similar functionality.

Wired took a look at this year’s Ninja Party badges. We were giddy about all the goodies involved in last year’s must-have badge that served as an invitation to the party. It was tailor-made for hacking, including an on-board disassembler. This year’s details are still a bit sparse but the offering is more along the lines of a market-ready product. The badges come in hand held gaming format, with a d-pad and two buttons. They can connect wirelessly with each other and with hidden base stations, allowing participants to fight in the digital realm for LED-indicated achievements. The teaser is tantalizing and we can’t wait to hear details about the real/digital gaming adventure soon to unfold.

[Kenneth Finnegan] is back with another video showing some cool stuff he’s doing to connect his microcontrollers to the internet. Usually, we see this done with a prebuilt module like an iobridge. [Kenneth] is using a Microchip ENC28j60 module for the communication and he’s managed to stuff it all onto a tiny Electroboards piece.  [Kenneth] is starting to become a regular around here.

[via HackedGadgets]

[Nicholas] built an active tracking system using RFID tags. The system’s tags operate in the 2.4 GHz band and are used to track either people or assets. The readers are on a mesh network and can triangulate the location of any tag for display on a map. His system is even set up to show the travel history of each tag. [Nicholas] shared every detail in his writeup including some background about available hardware options and how he made his final decisions on what devices to use for the job. His conglomeration of software that ties the whole project together is also available for download.

A post about Operation Chokehold popped up on (fake) Steve Jobs’ blog this morning. It seems some folks are just plain tired of AT&T giving excuses about their network. The straw that broke the camel’s back came when AT&T floated the idea of instituting bandwidth limitations for data accounts. Now, someone hatched the idea of organizing enough users to bring the whole network down by maxing their bandwidth at the same time.

We’re not quite sure what to think about this. Our friend Google told us that there’s plenty of press already out there regarding Operation Chokehold so it’s not beyond comprehension that this could have an effect on the network. On the other hand, AT&T already knows about it and we’d wager they’re working on a plan to mitigate any outages that might occur.

As for the effectiveness of the message?  We’d have more sympathy for AT&T if they didn’t have exclusivity contracts for their smart phones (most notably the iPhone). And if you’re selling an “Unlimited Plan” it should be just that. What do you think?

[Thanks Bobbers]

[Headlock photo]

As far as password recovery utilities go, Cain & Abel is by far one of the best out there. It’s designed to run on Microsoft Windows 2000/XP/Vista but has methods to recover passwords for other systems. It is able to find passwords in the local cache, decode scrambled passwords, find wireless network keys or use brute-force and dictionary attacks. For recovering passwords on other systems Cain & Abel has the ability to sniff the local network for passwords transmitted via HTTP/HTTPS, POP3, IMAP, SMTP and much more. We think it is quite possibly one of the best utilities to have as a system administrator, and definitely a must have for your toolbox.

We’re starting to think that phone numbers are deprecated; it may be time to integrate how we connect telephones with the new digital millennium. To get a firm grasp on this topic it is important to take a look at the reason we started using phone numbers, why we still use them, and the why’s and how’s of transitioning to a new system.

History of phone numbers

Telephone numbers started out as a way of physically addressing a telephone extension. Whether connected by an operator at a switchboard or through a magnetic exchange, each number corresponded to the hardware switch that connected the handset you were trying to ring. This originally started with named exchanges such as Pennsylvania-6-5000. The geographic location of the extension was  shown in the name and this system gradually transitioned over to area codes and prefixes.

Continued usage

The proliferation of cell phones means that numbers are no longer tied to a physical location but are routed to the nearest tower to which each wireless phone is currently connected. So why have we continued to use telephone numbers? Backwards compatibility is paramount. Cell phones overtook land lines years ago but there are still millions of people connected to the telephone companies’ wired networks. Most of the phones used on these land lines rely on the touch tone system to function. Even the advent of Voice over Internet Protocol implements the same system of connecting calls by dialing a number.

What works better than phone numbers?

How many different phone numbers does your family have? Many households have a home phone, a cell phone for each family member, and a work phone for each adult. What if all of these numbers were addressed similarly to how the Domain Name System works for internet addresses? Something like this:

phone://famiy.johndoe2155.voice/john_at_home

phone://family.johndoe2155.voice/jane_at_home

phone://www.your_company’s_domain.com/customer_service

This can be accomplished in the near future. All cell phones and many land line phones already have the ability to store numbers so that you only have to enter them once. Cell phones can already input web-style addresses and a firmware upgrade would allow for a new system of addressing and storing voice connection information. Service providers like Comcast and Charter are already providing phone service that utilizes VOIP, paving the way for dialing from your computer. For legacy hardware an inexpensive interface box similar to the digital cable converter boxes could be implemented. The new box would have a keyboard and character LCD and be rolled out in the same way that caller ID boxes were.

Conclusion

No one wants to change their telephone number and be in the position of trying to inform everyone who might ever call them. This is why laws were enacted to allow you to keep your telephone number if you change carriers. If each family owned their “voice domain”, changing carriers, cities, or even countries would be as simple as editing the domain registration. Transitioning to a new system of dynamically addressed telephone extensions is the next logical step in voice communications. Although it would be a change for billions of people, it is possible and worth taking a look at.

[photo credit Projekt Runeberg]

[Florian] and [Xavier Carcelle] started the day at 25C3 by covering power line communication. PLC technology is not widespread in the US, but has gained popularity in countries like France where it’s included in set-top boxes. PLC lets you create a local network using the AC wires in your wall. The team started exploring PLC because despite being newer technology, it had a few principles that made it similar to old networks. There’s no segmentation in the wiring, which means it behaves like a layer 2 hub. You get to see all of the traffic unlike a switched network. Most power meters don’t filter out the signal, so it’s possible that you might see your next-door neighbor’s traffic on your line. [Florian] reports having seen all the traffic in a six-story building just by plugging in. The wiring also acts as a large antenna so you could employ tempest attacks.

The technology involved is certainly interesting, but they found a lack of tools to work with it. They wrote FAIFA to fill this gap. It’s currently a command line tool for probing and configuring Intellon-based PLC devices (Intellon is the majority chip supplier for PLC). You can query devices and it even has a sniffer mode. Sniffing may not seem interesting since devices that support the HomePlug AV standard use encryption, but they’re all shipping from the factory with the same default key. In the future, they hope to build their own open source FPGA based PLC device to take even more control of the system.

This mini web server is slightly smaller than a business card. There are a lot of tiny one-board servers out there, but this is probably the smallest you can etch and solder at home. Unlike many embedded web servers, files are stored on a PC-readable SD card, not in a difficult-to-write EEPROM. Read on for the web server design, or catch up on PIC 24F basics in the previous article: Web server on a business card (part 1).

Concept overview

The goal of this project is to build a web server on a business card that serves web pages and files from a FAT formatted SD card. The server is based on a PIC 24F that connects to a TCP/IP network using the ENC28J60 ethernet MAC/PHY. Network layers and low-level services, such as DNS and DHCP, are handled by the Microchip TCP/IP stack. A FAT 12/16/32 formatted SD card contains web pages and files. A very simple HTTP server ties everything together by handling page requests on port 80, searching the SD card for requested, and serving them with the correct content type.

Hardware

(full size schematic .png)

Microcontroller (Microchip PIC 24FJ64GA002)

The brain of the server is a 16-bit PIC 24FJ64GA002 (IC1), a 28pin microcontroller available in several hobbyist friendly packages. Check out our PIC 24F introduction for more about working with this chip.

PIC 24Fs operate between 2 and 3.8volts, which is perfect because the ethernet chip (IC2) and SD card both run at 3.3volts. This chip has 8K of RAM, plenty for the TCP/IP stack and a few K for working with a full FAT file system. The 24FJ64 has two SPI modules, so the SD card and ethernet IC each get a dedicated data bus.

The PIC processor core operates at 2.5volts, and requires a 10uF capacitor (C2) for the on-chip voltage regulator. The datasheet specifies a tantalum capacitor, but we used a low-ESR electrolytic in a prototype without incident. Every power pin needs a 0.1uF decoupling capacitor (C4,5).

The internal 8MHz oscillator provides a 32MHz clock source with the 4x PLL multiplier enabled. We’re also using an external 32.768KHz crystal (Q1) with 2 x 27pF capacitors (C17,18) to enable the real time clock calendar.

Programming connections are brought to a header (SV1). We chose to use programming pin pair three (PGx3). The master clear and reset (MCLR) function is enabled with a 2K resistor (R1) from V+ to the MCLR pin. Optionally, add a button (S1) from MCLR to ground for a manual reset switch.

Ethernet connection (ENC28J60)

An ENC28J60 (IC2) handles the network physical connection (PHY) and MAC layer. The ENC28J60 needs a number of support parts beyond the typical 0.1uF decoupling capacitors (C6,7,9,10). A 25MHz crystal (Q2) and 2 x 27pf capacitors (C15,16) provide a clock signal. The internal core voltage regulator requires a 10uF tantalum capacitor (C1), but an electrolytic capacitor also worked fine. Two LEDs (LED1,2) with 330ohm resistors (R2,3) display link and data status.

A bias resistor (R12) is required; the value will depend on the ENC28J60 version you’re using. Current chips should be B5 (PDF) or B7 (PDF), and require a 2.32K 1% resistor.

The PHY I/O portion specifies 4 x 49.9ohm 1% resistors (R8-11), and a ferrite bead (L1).

The most difficult-to-find part for the ENC28J60 is the correct RJ-45 jack with integrated magnetics (RJ1). We used a J1006F21 PulseJack from Pulse Engineering. Be sure to check the pin configuration and connections if you use a different jack, they will probably be different than ours. A Cadsoft Eagle part library for the JP1006F21 is included in the project archive. This was a $4 part, but it’s gone up to $7. If you know of other jacks that work we’ll add them here.

microSD card

We used a microSD/transflash card in this design because SD cards waste a lot of board space under the holder. microSD cards are smaller versions of SD cards with the same data interface, and most come with an adapter for use in standard SD card readers. The card needs a holder (SD1) and a 0.1uF decoupling capacitor (C8).

If you want to use a full-size SD card, take a look at our version one prototype in the project archive. We used Alps SD card holder #SCDA1A0901. Unfortunately, this part is has been discontinued and we’ve yet to find a suitable replacement. Don’t try #SCDA5A0201, that’s for sure. If you have a favorite, we’ll add it here. Sparkfun has one, and a matching Cadsoft Eagle part library.

Power supply

An adjustable LM317 voltage regulator (IC3) is set to 3.3volts using a 390ohm (R6) and 240ohm (R7) resistor. We considered several 3.3volt regulators, but nothing was cheaper than a LM317 and two resistors. There’s a 0.1uF decoupling capacitor (C13,14) and a 10uF capacitor (C3,19) on both sides to help support the power hungry Ethernet transceiver. The LM317 will output 3.3volts from an input of 5 to 20volts+, but it gets really hot with greater than 9volts supply. The specified input capacitor is only rated 16volts, so consider an upgrade if you plan to use a supply greater than about 9volts.

For the first time ever, we incorporated a power jack (J1) into a design. A jack with a 2.1mm diameter internal pin seems to be the most common DC connector. We used a cheap through-hole DC power jack, like SparkFun #PRT-00119 or Mouser #163-7620-E. It mates with a plug like Mouser #1710-0721.

Circuit board

The PCB (full size placement .png) was designed in Cadsoft Eagle 5.0. Freeware versions are available for all major platforms. Renderings were done with Eagle3D, beta version. Schematic and board files are included in the project archive (ZIP).

We designed the project with large SOIC chips and 0805 surface mount (SMD) parts, but haters can rest assured that chips are available in a through-hole package. We prefer to use SMD parts because the resulting circuit boards are smaller, cheaper, and faster to produce. 0805 parts are dirt cheap, and easy to solder with a normal iron. Don’t expect this project to work on a breadboard, there’s probably too much capacitance for this circuit.

We took full advantage of the PIC’s programmable pin placement to get the simplest trace routings possible. Just four jumper wires are needed on an otherwise single-sided board.

The traces are large and clean, DIY toner transfer boards should be easy. We made our PCB using an inkjet printer transparency mask over an UV sensitive circuit board.

In addition to the final design, the project archive contains our v1 prototype design. The prototype uses a full size SD card (SCDA1A0901) and all electrolytic 10uF capacitors. We also put the RJ45 Ethernet jack on a daughterboard to better accommodate different pinouts.

Partslist

Firmware

Three firmware examples are included in the project archive [zip]. The examples compile with Microchip’s demonstration C30 compiler. Learn more about working with the PIC 24F in our previous article: Web server on a business card (part 1). MPLAB isn’t great about project portability, you may need to locate all the project files again if your path doesn’t match the ‘c:wsbc’ format that we used.

FAT12/16/32 disk library

Our first step was to get the FAT library reading from a SD card. FAT 12/16/32 are simple disk storage formats that work with PCs, MACs, digital cameras, music players, and other electronics. Here’s our favorite FAT tutorial/teardown (PDF).

Microchip’s FAT 12/16/32 library gives us simple functions for working with SD cards. The included demo application creates some files and directories to demonstrate each function. Here’s how we configured it to work on our custom hardware, you can find these changes by searching for the tag ‘HACKADAY’ in the code:

• HardwareProfile.h assigns actual PIC hardware to generic references in the code library. For the SD card this is an SPI interface, and pins for chip select and card detect. First, we deleted all the unused hardware profiles to make the code more manageable. Next, we configured the FAT library to communicate with the SD card using an SPI module (line 132). Finally, we defined the SPI pin assignments (line 152). Pin setup is shown in the table below.
  

  Pin	Port
  Chip select	B0
  SD card detect	A2
  SPI clock	B2
  SPI MOSI	B1
  SPI MISO	B3

• Demonstration.c. On line 48 we set a custom oscillator fuse configuration, as described in our PIC 24F introduction. This is also the logical place to configure pin assignments with peripheral pin select (line 63).
• FSConfig.h. This file enables various components of file system library, affecting the amount of memory and program space used. A read-only library is very small, a full write configuration is bigger. We didn’t have to make any changes for the demonstration, but this is an important file to note.

At first, the library failed to recognize our SD card. It only supports disks with a master boot record (MBR). Windows XP formats SD cards as a DOS disk: a single partition with no MBR. To verify this, open a Windows-formatted disk with a utility like HxD and inspect sector 0 of the physical disk. Byte 446 should be the location of the first MBR partition entry, but instead it’s the NTLDR executable code.

To format the disk in the ‘correct’ FAT format, use a digital camera’s format function or a utility like Panasonic’s SD card formatter. We also considered using a different FAT library that reads DOS disks, like DOSFS, or adding similar features to the Microchip firmware.

TCP/IP stack

Microchip’s free TCP/IP stack performs the convoluted configuration and networking functions needed to run a web server. You can read all about the stack in various application notes and documentation. Wikipedia is our favorite TCP/IP learning resource; we wrote our first TCP/IP stack using only Wikipedia.

Microchip’s TCP/IP stack used to be messy and confusing. Now it’s just confusing. The last few versions of have improved considerably in code clarity and structure. Here’s what we did to to configure the base TCP/IP stack example for our hardware, you can find these changes by searching for the tag ‘HACKADAY’ in the code:

• HardwareProfile.h assigns actual PIC hardware resources to generic references in the code library. We added our custom oscillator configuration (line 68), and configured the server status LED to use the LED attached to PORTB7 (line 83).  We defined the SPI interface to the ENC28J60 as follows (line 116):
  

  Pin	Port
  Reset	B8
  Chip select	B9
  SPI clock	B10
  SPI MOSI	B11
  SPI MISO	B12
  Wake on lan	B13
  Interrupt	B14

• MainDemo.c. We eliminated a bunch of unused code, and added the peripheral pin select configuration code to the InitializeBoard() function (line 332).
• TCPIPConfig.h defines the TCPIP stack components included in a compile. We’ve enabled DNS, DHCP, the IP announcer, and the ping server (line 56):

#define STACK_USE_DNS            // Domain Name Service Client
#define STACK_USE_DHCP_CLIENT    // Get DNS automagically
#define STACK_USE_ANNOUNCE       // Microchip Ethernet Device Discoverer
#define STACK_USE_ICMP_SERVER    // Enable the PING server

After loading this firmware, we’re ready to connect the server to a network for the first time. During initialization, the TCP/IP stack negotiates with the network router for an IP address using DHCP. We need to know this address to communicate with the device. If the device had a screen we could display the IP address, but instead we use the MCHPDetect.exe utility from Microchip.

When the TCP/IP stack finishes initializing, it broadcasts an announcement packet to port 30303 of all locally connected computers. MCHPDetect extracts the IP address from these packets. A new announce packet is sent on every PIC reset.

It’s also possible to read the IP address directly from memory with a debugger. The address is stored in the AppConfig.MyIPAddr variable, the .byte form follows the standard x.x.x.x IP notation.

Once we have the IP address, we can ping the server and test its responsiveness.

If ping shows high latency or malformed packets, you can use Wireshark to inspect network traffic at the byte level. Unless you’re in Germany, because it might be criminal.

Building the custom HTTP server

The custom web server looks for requested files on the SD card, and sends them with the correct content type. We used the Microchip HTTP example server v1 (HTTP.c) as a base for our FAT file server (FATHTTP.c).

Microchip’s HTTP server used a simple file system called MPFS to index web pages on an EEPROM chip. We replaced calls to MPFS functions with calls to functions in the FAT library (see the HTTPProcess and Sendfile functions in FATHTTP.c). Our changes demonstrate the concept as simply as possible, without adding confusing pointers and other handy C obfuscations. The code leaves a ton of room for improvements, have at it. File writes are disabled in the default compilation, but there’s enough program space to enable them if you want to write to the SD card (see FSConfig.h).

It’s necessary to registered our custom FATHTTP server with the rest of the TCP/IP stack. We did a search and replace for the original HTTP server components, and added calls to our new FATHTTP server as needed. That turned out to be these places:

• TCPIPConfig.h. First we inserted some definitions that enable the FATHTTP server (line 70), and added a TCP socket for the FATHTTP server (line 248).
• TCPIP.h. Next, we added FATHTTP to the list of services that require the TCP/IP stack (line 170) and then included the necessary headers (line 351).
• StackTSK.c. We added the FATHTTP server initialization (line 138) and processing (line 340) functions to the list of TCP/IP stack tasks.
• Helpers.c. We also needed to include a few helper functions for working with URLs (line 259).

At long last, it’s time to put some files on an SD card and test this thing. Make sure your files follow the 8.3 file name format. The project archive contains a sample website with a test image and zip file.

After grabbing the server’s IP address with MCHPDetect, we pointed a browser at it. The IP address entered alone will redirect the browser to index.htm, whether or not it exists. Web pages and images stored on the SD card display in the browser, but unknown binary types trigger a download prompt.

Taking it further

We see a lot of potential projects using this tiny web platform.

• Add hooks in the FATHTTP.c source for special URLs that trigger events or configure pins.
• Build a remotely accessible data logger. Use the extra pins to read sensors and log data to the SD card. Logs are retrievable from a web browser, or directly from the FAT readable SD card.
• Get remote access to an ancient serial terminal or BBS, optionally log the console output. Use two external pins as a serial port, and forward commands from the Internet using Microchip’s Telnet server and Ethernet-to-serial bridge examples.
• Your suggestions?

Next time, we’ll use the mini server to make an Internet connected, electronic indoor graffiti wall. This will be an interactive project where everyone can contribute graffiti and animations on-line.

Schematic, board, and firmware files are included in the project archive (ZIP). Use the freeware version of Cadsoft Eagle to view the schematic and PCB. The firmware is written in C, and compiled with the Microchip demonstration C30 compiler.

Making a passive network tap can be an easy and inexpensive undertaking as shown in this Instructable. Passive monitoring or port mirroring is needed because most networks use switches which isolate the network traffic and this does not allow for the entire network to be monitored.  This example uses a single tap, using multiple taps will provide access to the full-duplex data separately. By using two taps you are able to monitor inbound data that is passed through one tap, and outbound data that is passed through the other tap.  Separate taps are desired because most sniffer software handles half-duplex traffic only and requires two network cards for full-duplex.

It is easy to insert a passive Ethernet tap inline, as shown in the picture above from a different multitap project,  simply plug the incoming line into a host port and a patch cable from the other host port to the outgoing port, then verify your connection status. Now connect the Ethernet port of your sniffer computer into either of the tap connectors on the passive Ethernet tap. This tap works by using sniffer applications that put your Ethernet card into promiscuous mode.  This allows you to monitor all traffic on the network not just the traffic directed to your network adapter. After you install your favorite sniffer program, such as Wireshark, Snort, TCPDump, WinDump, or Ettercap to name a few,  you are then able to monitor all traffic any way you see fit, like looking for passwords in the video below.