Over the past few months, a number of companies and designers have started picking up the newest Intel SoCs. Intel has to kill ARM somehow, right? The latest of these single board x86 computers is the Lattepanda. It’s a tiny board that can run everything a 5-year-old desktop computer can run, including a full version of Windows 10.
This isn’t the first time we’ve seen a tiny x86 board in recent months. Last October, an x86 board that takes design cues from the Raspberry Pi 2 hit Kickstarter. These are proper PCs, with the ability to run Windows 10, Linux, and just about every other environment under the sun.
The specs for the Lattepanda include a quad-core Cherry Trail running at 1.8GHz. the RAM is either 2GB or 4GB depending on configuration, and 32GB of eMMC Flash. Peripherals include USB 3.0, Ethernet, WiFi, Bluetooth, and integrated graphics supporting either HDMI or a DSI connector.
But of course a computer is just a computer, and you can’t sell a machine that only runs Skype to the ‘maker’ market. The Lattepanda also includes an ATMega32u4 as a coprocessor, giving this board ‘Arduino functionality’. In my day we walked uphill both ways to get a parallel port, but I digress.
While these tiny x86 boards might not be available in a year’s time, and the companies behind them may fall off the face of the planet, the introduction of these devices portends a great war over the horizon. Intel wants the low-power SoC market, a space until now reserved entirely for ARM-based devices.
Programmers and software engineers will always use the latest development environments, the trendiest frameworks, and languages they learned only 21 days ago. What if this weren’t the case? What if developers put care into their craft and wrote programs with an old world charm? What if Windows executables were made with the same patience as artisanal firewood, or free range granola? [Steve] has done it. He’s forging a path into the wilds of truly hand crafted executables.
The simplest executable you could run on a Windows box is just a simple .COM file. This is an extremely simple file format that just contains code and data loaded into 0100h, and a jump to another point in the code. The DOS .EXE file format is slightly more complicated, but not by much. [Steve]’s goal was to build a proper Windows executable without a compiler, assembler, linker, or anything else.
Continue reading “Bespoke, Artisanal, Hand Made Executables”
Manufacturers of 3D printers have a lot to do before they catch up with makers of the cheapest 2D, paper-based printers. If you’ve ever taken an inkjet apart, you’ll most likely find some sort of closed-loop control on at least one of the axes. The 2D printer will tell you when you’re out of ink, when a 3D printer will go merrily along, printing in air without filament. File formats? Everything is Gcode on a 3D printer, and there are dozens, if not hundreds of page description languages for 2D printers.
The solution to some of these problems are drivers – software for a 3D printer that slowly consumes the slicing of an object, printer settings, and placing an object on the bed. It’s coming, and the people who are responsible for making your 2D printer work with your computer are busy at work messing up the toolchain for your 3D printer.
The latest version of CUPS (C Unix Printing System) adds support for 3D printers. This addition is based on meetings, white papers, and discussions in the Printer Working Group (PWG). There has already been a lot of talk about what is wrong with the current state of 3D printer toolchains, what can be improved, and what should be completely ignored. Let’s take a look at what all of this has accomplished.
Continue reading “Drivers for 3D Printers and Why We Need Them”
[Voltagex] was fed up with BSODs on his Windows machine due to a buggy PL2303 USB/serial device driver. The Linux PL2303 driver worked just fine, though. A weakling would simply reboot into Linux. Instead, [Voltagex] went for the obvious workaround: create a tiny Linux distro in a virtual machine, route the USB device over to the VM where the drivers work, and then Netcat the result back to Windows.
OK, not really obvious, but a cool hack. Using Buildroot, a Linux system cross-compilation tool, he got the size of the VM down to a 32Mb memory footprint which runs comfortably on even a small laptop. And everything you need to replicate the VM is posted up on Github.
Is this a ridiculous workaround? Yes indeed. But when you’ve got a string of tools like that, or you just want an excuse to learn them, why not? And who can pass up a novel use for Netcat?
[Daniel] found himself with a need to connect a single USB device to two Linux servers. After searching around, he managed to find an inexpensive USB switch designed to do just that. He noticed that the product description mentioned nothing about Linux support, but he figured it couldn’t be that hard to make it work.
[Daniel] started by plugging the device into a Windows PC for testing. Windows detected the device and installed an HID driver automatically. The next step was to install the control software on the Windows system. This provided [Daniel] with a tray icon and a “switch” function. Clicking this button disconnected the HID device from the Windows PC and connected the actual USB device on the other side of the USB switch. The second computer would now have access to the HID device instead.
[Daniel] fired up a program called SnoopyPro. This software is used to inspect USB traffic. [Daniel] noticed that a single message repeated itself until he pressed the “switch” button. At that time, a final message was sent and the HID device disconnected.
Now it was time to get cracking on Linux. [Daniel] hooked up the switch to a Linux system and configured a udev rule to ensure that it always showed up as /dev/usbswitch. He then wrote a python script to write the captured data to the usbswitch device. It was that simple. The device switched over as expected. So much for having no Linux support!
After [Brian] starting selling his own Raspberry Pi expansion boards, he found himself with a need for a robot that could solder 40-pin headers for him. He first did what most people might do by looking up pre-built solutions. Unfortunately everything he found was either too slow, too big, or cost as much as a new car. That’s when he decided to just build his own soldering robot.
The robot looks similar to many 3D printer designs we’ve seen in the past, with several adjustments. The PCBs get mounted to a flat piece of aluminum dubbed the “PCB caddy”. The PCBs are mounted with custom-made pins that thread into the caddy. Once the PCBs are in place, they are clamped down with another small piece of aluminum. A computer slowly moves the caddy in one direction, moving the header’s pins along the path of the soldering irons one row at a time.
The machine has two soldering irons attached, allowing for two pins to be soldered simultaneously. The irons are retracted as the PCB caddy slides into place. They irons are then lowered onto the pins to apply heat. Two extruders then push the perfect amount of solder onto each pin. The solder melts upon contact with the hot pins, just as it would when soldered by hand.
The system was originally designed to be run on a Windows 8.1 tablet computer, but [Brian] found that the system’s internal battery would not charge while also acting like a USB host. Instead, they are running the Windows WPF application on full PC. All of the software and CAD files can be found on [Brian’s] github page. Also be sure to check out the demo video below. Continue reading “Open Source, DIY Soldering Robot”
Most of us know that we should lock our computers when we step away from them. This will prevent any unauthorized users from gaining access to our files. Most companies have some sort of policy in regards to this, and many even automatically lock the screen after a set amount of time with no activity. In some cases, the computers are configured to lock and display a screen saver. In these cases, it may be possible for a local attacker to bypass the lock screen.
[Adrian] explains that the screen saver is configured via a registry key. The key contains the path to a .scr file, which will be played by the Adobe Flash Player when the screen saver is activated. When the victim locks their screen and steps away from the computer, an attacker can swoop in and defeat the lock screen with a few mouse clicks.
First the attacker will right-click anywhere on the screen. This opens a small menu. The attacker can then choose the “Global settings” menu option. From there, the attacker will click on “Advanced – Trusted Location Settings – Add – Add File”. This opens up the standard windows “Open” dialog that allows you to choose a file. All that is required at this point is to right-click on any folder and choose “Open in a new window”. This causes the folder to be opened in a normal Windows Explorer window, and from there it’s game over. This window can be used to open files and execute programs, all while the screen is still locked.
[Adrian] explains that the only remediation method he knows of is to modify the code in the .swf file to disable the right-click menu. The only other option is to completely disable the flash screen saver. This may be the safest option since the screen saver is most likely unnecessary.
Update: Thanks [Ryan] for pointing out some mistakes in our post. This exploit specifically targets screensavers that are flash-based, compiled into a .exe file, and then renamed with the .scr extension. The OP mentions these are most often used in corporate environments. The exploit doesn’t exist in the stock screensaver.