Broken Yoga Becomes Firewall

It seems the older I get, the density of broken and/or old laptops on my garage grows. That’s one of the reasons it’s interesting to know which projects are being made to bring back to life these things. [zigzagjoe] sent us an interesting project he made out of a Lenovo Yoga 2 motherboard: a pfsense router/firewall.

The laptop was damaged, but the main board was functioning just fine. What started as adding an old Pentium heatsink to it and see how good it would work, escalated to a fully working, WiFi, 4 port gigabyte NIC, 3D printed case firewall. The board had PCI-E via an M.2 A/E key slot for the WiFi module but [zigzagjoe] need a normal PCI-E slot to connect the quad-port NIC. He decided to hand solder the M.2 A/E (WiFi card) to have a PCI-E 1x breakout since his searches for an adapter came out empty or too expensive. For storage, he chose 16GB SanDisk U100 Server half-slim SSD for its power efficiency. Once again, the SSD cable had to be hacked as the laptop originally used a super-slim HDD with a non-standard connector. The enclosure was then designed and 3D printed.

But [zigzagjoe] went further to optimize his brand new router/firewall. On the project documentation, we can see a lot of different modifications went into building it, such as bios modification for new WiFi modules to work, an Attiny85 fan driver for extra cooling, a 45W PSU inside the case and other interesting hacks.

This is not your typical laptop to firewall hack, that’s for sure.

Continue reading “Broken Yoga Becomes Firewall”

Dummies Guide to Reverse Engineering

[Juan Carlos Jiménez] has reverse engineered a router — specifically, a Huawei HG533. While that in itself may not sound substantial, what he has done is write a series of blog posts which can act as a great tutorial for anyone wanting to get started with sniffing hardware. Over the five part series, he walks through the details of identifying the hardware serial ports which open up the doors to the firmware and looking at what’s going on under the hood.

The first part deals with finding the one or several debug ports on the hardware and identifying the three important pins – Rx, Tx and GND. That’s when he shows novices his first trick – shining a flashlight from under the PCB to find the pins that have trace connections (most likely Rx and Tx), those that don’t have any connections (most likely CTS and DTR) and those that have connections to the copper pour planes (most likely VCC and GND). The Tx signal will be pulled up and transmitting data when the device is powered up, while the Rx signal will be floating, making it easy to identify them. Finding the Baud rate, though, will require either a logic analyser, or you’ll have to play a bit of a guessing game.

Once you have access to the serial port and know its baud rate, it’s time to hook it up to your computer and use any one of the several ways of looking at what’s coming out of there — minicom, PuTTY or TeraTerm, for example. With access to the devices CLI, and some luck with finding credentials to log in if required, things start getting interesting.

Over the next part, he discusses how to follow the data paths, in this case, looking at the SPI signals between the main processor and the flash memory, and explaining how to use the logic analyser effectively and decode the information it captures. Moving further, he shows how you can hook up a USB to SPI bridge, connect it to the flash memory, take a memory dump of the firmware and read the extracted data. He wraps it up by digging in to the firmware and trying to glean some useful information.

It’s a great series and the detailed analysis he does of this particular piece of hardware, along with providing a lot of general tips, makes it a perfect starting point for those who need some help when getting started on debugging hardware.

Thanks, [gnif] for posting this tip.

Continue reading “Dummies Guide to Reverse Engineering”

[Huan] Liberates a Router

[Huan Truong] was given a WiFi router and thought he’d improve it by installing a free firmware on it. Unfortunately, the router in question is a bit old, and wasn’t ever popular to begin with, which meant that it was unsupported by the usual open firmware suspects. The problem was that it only had a 4 MB flash to boot off of, but [Huan] was determined to make it work. (Spoiler: he did it, and documented it fully.)

The flash workaround consisted basically of repartitioning the space, and then telling u-boot where to find everything. On a router like the WNR2000 that [Huan] had, the flash is memory-mapped, which meant adding an offset to the flash start (0xbf000000 instead of 0x00000000) and remembering to do this consistently so that he doesn’t overwrite things like the MAC address.

[Huan] went for the LEDE fork of OpenWRT, and rebuilt it from source because he needed a small version to fit inside his limited flash. With this task completed, it worked. All done? Nope, [Huan] then submitted a pull request to LEDE, and now you can enjoy the fruits of his labor without replicating it. But if you’ve got another low-flash, obscure router, you’ve got a head start in getting LEDE up and running on it.

Routers are perhaps the most-hacked device that we see here, and they can be made pretty darn useful with the right firmware. Sometimes getting a custom firmware running is relatively easy, as it was here, and sometimes it requires some deep reverse engineering. But it’s good to keep up your router-hacking chops, because they may not always be as open as they are now.

TP-Link Debug Protocol Gives Up Keys To Kingdom

If the headline makes today’s hack sound like it was easy, rest assured that it wasn’t. But if you’re interested in embedded device hacking, read on.

[Andres] wanted to install a custom OS firmware on a cheap home router, so he bought a router known to be reflashable only to find that the newer version of the firmware made that difficult. We’ve all been there. But instead of throwing the device in the closet, [Andres] beat it into submission, discovering a bug in the firmware, exploiting it, and writing it up for the manufacturer.  (And just as we’re going to press: posting the code for the downgrade exploit here.)

This is not a weekend hack — this took a professional many hours of serious labor. But it was made a lot easier because TP-Link left a debugging protocol active, listening on the LAN interface, and not requiring authentication. [Andres] found most of the information he needed in patents, and soon had debugging insight into the running device.

Continue reading “TP-Link Debug Protocol Gives Up Keys To Kingdom”

This Quick Hack Will Keep You Online During Your Next Power Outage

The modern human’s worst nightmare: a power outage. Left without cat memes, Netflix, and — of course — Hackaday, there’s little to do except participate in the temporary anarchy that occurs when left without internet access. Lamenting over expensive and bulky uninterruptible power supplies, Youtube user [Gadget Addict] hacked together a UPS power bank that might just stave off the collapse of order in your household.

This simple and functional hack really amounts to snipping the end off of a USB  power cable. The cable is then attached to a screw terminal to barrel connector adapter and plugged it into a pass-through power USB power bank. No, really — that’s all there is to it. [Gadget Addict] notes that while most modems and routers are designed to run off a 12V power supply, they still operate at 5V. He goes on to connect several router and router/modem combination units to the power bank. In each case the system appears to boot up and perform normally.

Continue reading “This Quick Hack Will Keep You Online During Your Next Power Outage”

Maslow Brings The Wall Plotter Into The Woodshop

Hanging plotters, or two steppers controlling a dangling Sharpie marker on an XY plane, are nothing new to our community. But have you ever thought of trading out the Sharpie for a wood router bit and cutting through reasonably thick plywood sheets? That would give you a CNC machine capable of cutting out wood in essentially whatever dimensions you’d like, at reasonably low-cost. And that’s the idea behind [Bar]’s Maslow. It’s going to be a commercial product (we hope!), but it’s also entirely open source and indubitably DIYable.

[Bar] walks us through all of the design decisions in this video, which is a must-watch if you’re planning on building one of these yourself. Basically, [Bar] starts out like any of us would: waaaay over-engineering the thing. He starts out with a counterweight consisting of many bricks, heavy-duty roller chain, and the requisite ultra-beefy motors to haul that all around. At some point, he realized that there was actually very little sideways force placed on a sharp router bit turning very quickly. This freed up a lot of the design.

His current design only uses two bricks for counterweights, uses lighter chains, and seems to get the job done. There’s a bit of wobble in the pendulum, which he admits that he’s adjusted for in software. Motors with built-in encoders and gearing take care of positioning accurately. We haven’t dug deeply enough to see if there’s a mechanism to control the router’s plunge, which would be great to cut non-continuous lines, but first things first.

Taking the wall plotter into the woodshop is a brilliant idea, but we’re sure that there’s 99% perspiration in this design too. Thanks [Bar] for making it open! Best of luck with the Kickstarter. And thanks to [Darren] for the tip.

Distributed Censorship or Extortion? The IoT vs Brian Krebs

Now it’s official. The particular website that was hit by a record-breaking distributed denial of service (DDOS) attack that we covered a few days ago was that of white-hat security journalist [Brian Krebs]: Krebs on Security.

During the DDOS attack, his site got 600 Gigabits per second of traffic. It didn’t involve amplification or reflection attacks, but rather a distributed network of zombie domestic appliances: routers, IP webcams, and digital video recorders (DVRs). All they did was create HTTP requests for his site, but there were well in excess of 100,000 of these bots.

In the end, [Krebs’] ISP, Akamai, had to drop him. He was getting pro bono service from them to start with, and while they’ve defended him against DDOS attacks in the past, it was costing them too much to continue in this case. An Akamai exec estimates it would have cost them millions to continue defending, and [Brian] doesn’t blame them. But when Akamai dropped the shields, his hosting provider would get slammed. [Krebs] told Akamai to redirect his domain to localhost and then he went dark.

Continue reading “Distributed Censorship or Extortion? The IoT vs Brian Krebs”