VGA Signal In A Browser Window, Thanks To Reverse Engineering

December 30, 2019 by Donald Papp 25 Comments

[Ben Cox] found some interesting USB devices on eBay. The Epiphan VGA2USB LR accepts VGA video on one end and presents it as a USB webcam-like video signal on the other. Never have to haul a VGA monitor out again? Sounds good to us! The devices are old and abandoned hardware, but they do claim Linux support, so one BUY button mash later and [Ben] was waiting patiently for them in the mail.

But when they did arrive, the devices didn’t enumerate as a USB UVC video device as expected. The vendor has a custom driver, support for which ended in Linux 4.9 — meaning none of [Ben]’s machines would run it. By now [Ben] was curious about how all this worked and began digging, aiming to create a userspace driver for the device. He was successful, and with his usual detail [Ben] explains not only the process he followed to troubleshoot the problem but also how these devices (and his driver) work. Skip to the end of the project page for the summary, but the whole thing is worth a read.

The resulting driver is not optimized, but will do about 7 fps. [Ben] even rigged up a small web server inside the driver to present a simple interface for the video in a pinch. It can even record its output to a video file, which is awfully handy. The code is available on his GitHub repository, so give it a look and maybe head to eBay for a bit of bargain-hunting of your own.

Reverse Engineering Liberates Dash Cam Video

October 15, 2019 by Tom Nardi 12 Comments

If you’ve purchased a piece of consumer electronics in the last few years, there’s an excellent chance that you were forced to use some proprietary application (likely on a mobile device) to unlock its full functionality. It’s a depressing reality of modern technology, and unless you’re willing to roll your own hardware, it can be difficult to avoid. But [krishnan793] decided to take another route, and reverse engineered his DDPAI dash camera so he could get a live video stream from it without using the companion smartphone application.

Like many modern gadgets, the DDPAI camera creates its own WiFi access point that you need to connect to for configuration. By putting his computer’s wireless card into Monitor mode and running Wireshark, [krishnan793] was able to see that the smartphone was communicating with the camera using some type of REST API. After watching the clear-text exchanges for awhile, he not only discovered a few default usernames and passwords, but the commands necessary to configure the camera and start the video stream.

After hitting it with the proper REST messages, an nmap scan confirmed that several new services had started up on the device. Unfortunately, he didn’t get any video when he pointed VLC to the likely port numbers. At this point [krishnan793] checked the datasheet for the camera’s Hi3516E SoC and saw that it supported H.264 encoding. By manually specifying that as the video codec when invoking VLC, it was able to play a video stream from port 6200. A little later, he discovered that port 6100 was serving up the live audio.

Technically that’s all he wanted to do in the first place, as he was looking to feed the video into OpenCV for other projects. But while he was in the area, [krishnan793] also decided to find the download URL for the camera’s firmware, and ran it through binwalk to see what he could find out. Not surprisingly the security turned out to be fairly lax through the entire device, so he was able to glean some information that could be useful for future projects.

Of course, if you’d rather go with the first option and build your own custom dash camera so you don’t have to jump through so many hoops just to get a usable video stream, we’ve got some good news for you.

This Tiny Router Could Be The Next Big Thing

February 1, 2019 by Tom Nardi 22 Comments

It seems like only yesterday that the Linksys WRT54G and the various open source firmware replacements for it were the pinnacle of home router hacking. But like everything else, routers have gotten smaller and faster over the last few years. The software we run on them has also gotten more advanced, and at this point we’ve got routers that you could use as a light duty Linux desktop in a pinch.

But even with no shortage of pocket-sized Linux devices in our lives, the GL-USB150 “Microrouter” that [Mason Taylor] recently brought to our attention is hard to ignore. Inside this USB flash drive sized router is a 400 MHz Qualcomm QCA9331 SoC, 64 MB of RAM, and a healthy 16 MB of storage; all for around $20 USD. Oh, and did we mention it comes with OpenWRT pre-installed? Just plug it in, and you’ve got a tiny WiFi enabled Linux computer ready to do your bidding.

On his blog [Mason] gives a quick rundown on how to get started with the GL-USB150, and details some of the experiments he’s been doing with it as part of his security research, such as using the device as a remote source for Wireshark running on his desktop. He explains that the diminutive router works just fine when plugged into a USB battery bank, offering a very discreet way to deploy a small Linux box wherever you may need it. But when plugged into a computer, things get really interesting.

If you plug the GL-USB150 into a computer, it shows up to the operating system as a USB Ethernet adapter and can be used as the primary Internet connection. All of the traffic from the computer will then be routed through the device to whatever link to the Internet its been configured to use. Depending on how you look at it, this could be extremely useful or extremely dangerous.

For one, it means that something that looks all the world like a normal USB flash drive could be covertly plugged into a computer and become a “wiretap” through which all of the network traffic is routed. That’s the bad news. On the flip side, it also means you could configure the GL-USB150 as a secure endpoint that lets you quickly and easily funnel all the computer’s traffic through a VPN or Tor without any additional setup.

We’ve seen all manner of hacks and projects that made use of small Linux-compatible routers such as the TP-Link TL-MR3020, but we expect the GL-USB150 and devices like it will be the ones to beat going forward. Let’s just hope one of them doesn’t show up uninvited in your network closet.

Blowing The Dust Off Of An IBM AS/400 Server

January 13, 2019 by Tom Nardi 111 Comments

If you’ve never seen an IBM AS/400 machine, don’t feel bad. Most people haven’t. Introduced in 1988 as a mid-range server line, it used a unique object-based operating system and was geared specifically towards business and enterprise customers. Unless you’re a particularly big fan of COBOL you probably won’t have much use for one today, but that doesn’t mean they aren’t worth playing around with if the opportunity presents itself.

So when a local IT company went belly up and was selling their old hardware, including a late 90’s era IBM AS/400e Series, [Rik te Winkel] jumped at the chance to take this unique piece of computing history home. He knew it was something of a risk, as maintenance and repair tasks for these machines were intended to be done by IBM certified technicians rather than the DIYer, leaving little in the way of documentation or even replacement parts. But in the end it worked out, and best of all, he documented the successful process of dragging this 90’s behemoth into the blinding light of the twenty-first century for all the world to see.

After getting the machine home and sitting through its thirty minute boot process, [Rik] was relieved to see the code 01 B N pop on the server’s display. This meant the system passed all the internal checks and was ready to go, he just had to figure out how to talk to the thing. Built to be a pure server, the machine didn’t offer any video output so he’d have to log into it over the network.

[Rik] noted that there was no new DHCP entry in his router for the server, but of course that was hardly surprising as the machine would have certainly had a static IP when it was in use. So he shut the server down, plugged it directly into his laptop’s Ethernet port, and watched the output of Wireshark as it went through its arduous boot sequence. Eventually he started to pick up packets coming from the IP address 10.10.10.9, and he had his target.

There are a few clients out there that allow you to remotely log into an AS/400, so he downloaded one and pointed it to the server’s IP. He was surprised to see the operating system was apparently in Dutch, but at least he was in. He tried a few common usernames and passwords, helped along by the fact that this OS from a somewhat more innocent era will actually tell you if you have the username right or wrong, and eventually managed to hack the Gibson with the classic admin/admin combo.

So he was in, but now what? [Rik] decided that he couldn’t truly call this machine bested until he could pull up the Hackaday Retro Edition, so he started work on writing a program to let him pull down the page directly on the AS/400 in IBM’s proprietary Report Program Generator (RPG) programming language. You know, as one does. He didn’t quite feel up to writing a whole HTML parser, but he got as far as generating a HTTP GET request, downloading the page’s source, and opening it up as a local file. That’s good enough for us.

Our very own [Al Williams] documented his adventures poking around an Internet-connected AS/400 machine, which might serve as a helpful primer if you ever find one of these delightfully oddball computers kicking around the local recycling center.

Prisoners Build DIY Computers And Hack Prison Network

April 17, 2017 by Jack Laidlaw 80 Comments

The Internet is everywhere. The latest anecdotal evidence of this is a story of prison inmates that build their own computer and connected it to the internet. Back in 2015, prisoners at the Marion Correctional Institution in Ohio built two computers from discarded parts which they transported 1,100 feet through prison grounds (even passing a security checkpoint) before hiding them in the ceiling of a training room. The information has just been made public after the release of the Inspector General’s report (PDF). This report is fascinating and worth your time to read.

This Ethernet router was located in a training room in the prison. Physical access is everything in computer security.

Prisoners managed to access the Ohio Department of Rehabilitation and Corrections network using login credentials of a retired prison employee who is currently working as a contract employee. The inmates plotted to steal the identity of another inmate and file tax returns under their name. They also gained access to internal records of other prisoners and checked out websites on how to manufacture drugs and DIY weapons, before prison officers were able to find the hidden computers. From the report:

The ODAS OIT analysis also revealed that malicious activity had been occurring within the ODRC inmate network. ODAS OIT reported, “…inmates appeared to have been conducting attacks against the ODRC network using proxy machines that were connected to the inmate and department networks.” Additionally, ODAS OIT reported, “It appears the Departmental Offender Tracking System (DOTS) portal was attacked and inmate passes were created. Findings of bitcoin wallets, stripe accounts, bank accounts, and credit card accounts point toward possible identity fraud, along with other possible cyber-crimes.”

The prisoners involved knew what they were doing. From the interview with the inmate it seems the computers were set up as a remote desktop bridge between internal computers they were allowed to use and the wider internet. They would use a computer on the inmate network and use a remote desktop to access the illicit computers. These were running Kali Linux and there’s a list of “malicious tools” found on the machines. It’s pretty much what you’d expect to find on a Kali install but the most amusing one listed in the report is “Hand-Crafted Software”.

This seems crazy, but prisoners have always been coming up with new ideas to get one over on the guards — like building DIY tattoo guns, When you have a lot of time on your hands and little responsibility, crazy ideas don’t seem so crazy after all.

Secret Listening To Elevator Music

May 24, 2016 by Elliot Williams 24 Comments

While we don’t think this qualifies as a “fail”, it’s certainly not a triumph. But that’s what happens when you notice something funny and start to investigate: if you’re lucky, it ends with “Eureka!”, but most of the time it’s just “oh”. Still, it’s good to record the “ohs”.

Gökberk [gkbrk] Yaltıraklı was staying in a hotel long enough that he got bored and started snooping around the network, like you do. Breaking out Wireshark, he noticed a lot of UDP traffic on a nonstandard port, so he thought he’d have a look.

Continue reading “Secret Listening To Elevator Music” →

How To Make Amazon Echo Control Fake WeMo Devices

July 16, 2015 by Rick Osgood 27 Comments

[Chris] has been playing with the Amazon Echo. It’s sort of like having Siri or Google Now available as part of your home, but with built-in support for certain other home automation appliances like those from Belkin WeMo and Philips. The problem was [Chris] didn’t want to be limited to only those brands. He had other home automation gear that he felt should work with Amazon Echo, but didn’t. That’s when he came up with the clever idea to just emulate one of the supported platforms.

The WeMo devices use UPnP to perform certain functions over the network. [Chris] wanted to see how these communications actually worked, so he fired up his laptop and put his WiFi adapter into monitor mode. Then he used Wireshark to start collecting packets. He found that the device detection function starts out with the Echo searching for WeMo devices using UPnP. The device then responds to the Echo with the device’s URL using HTTP over UDP. The Echo then requests the device’s description using that HTTP URL. The description is then returned as an HTTP response.

The actual “on/off” functionality of the WeMo devices is simpler since the Echo already knows about the device. The Echo simply connects to the WeMo over the HTTP interface and issues a “SetBinaryState” command. The WeMo then obliges and returns a confirmation via HTTP.

WeMo Echo — How Echo Communicates with WeMo Devices

[Steve] was able to use this information to set up his own WeMo “virtual cloud”. Each virtual device would have its own IP address. They would also need to have a listener for UDP broadcasts as well as an HTTP listener running on the WeMo port 49153. Each virtual device would also need to be able to respond to the UPnP discovery requests and the “on/off” commands.

[Chris] used a Linux server, creating a new virtual Ethernet interface for each virtual WeMo switch. A single Python script runs the WeMo emulation, listening for the UPnP broadcast and sending a different response for each virtual device. Part of the response includes the device’s “friendly name”, which is what the Echo listens for when the user says voice commands. Since the virtual WeMo devices are free, this allows [Chris] to make multiple phrases for each device. So rather than be limited to “television”, he can also make a separate device for “TV” that performs the same function. [Chris] is also no longer limited to only specific brands of home automation gear.

There’s still a long way to go in hacking this device. There’s a lot of hardware under the hood to work with. Has anyone else gotten their hands (and bench tools) on one of these?