PCI pass through is the ability of a virtualized guest system to directly access PCI hardware. Pass through for dedicated GPUs has just recently been added to the Linux kernel-based virtual machine. Soon afterward, users began to find that switching on nested page tables (NPT), a technology intended to provide hardware acceleration for virtual machines, had the opposite effect on AMD platforms and slowed frame rate down to a crawl.
Annoyed by this [gnif] set out to to fix the problem. His first step was to run graphics benchmarks to isolate the source of the problem. Having identified the culprit in the GPU, [gnif] began to read up on the involved technology stack. Three days of wrapping his head around technical docs allowed [gnif] to find the single line of code that resulted in a faulty memory set up and to implement a basic fix. He then passed the work on to [Paolo Bonzini] at patchwork.kernel.org, who released a more refined patch.
The bug affecting PCI pass through had been around for ten years and had received little attention from the manufacturer. It gained prominence when graphics cards were affected. In the end it took one very dedicated user three days to fix it, and then another day to roll out a patch for Open Source operating systems. In his notes [gnif] points out how helpful AMDs documentation was. With the right to repair in debate, DRMed technical docs and standards locked behind paywalls, [gnif]’s story is a reminder of the importance of accessible quality documentation.
In the last couple of decades we have become used to the browser taking over so many of the desktop functions for which we used to rely on stand-alone software. Email clients, calendars, office suites and much more can now be found in the cloud, courtesy of the usual technology companies.
With only a 100-cell memory and dependent entirely upon the processing power available to the host browser, this machine is not likely to set the world on fire. He gives full instruction set details, there are a couple of demo programs, a Fib
ronacci sequence generator and a factorial generator, but its general lack of power is not really the point. Instead its value lies in an elegant demonstration for its own sake that a virtual computer can be built in the unlikeliest of places, and for those interested enough to peer into its code, some idea how that might be achieved.
[via Hacker News]
[Gerardo Iglesias Galván] decided he wanted to try his hand at bug-bounty hunting — where companies offer to pay hackers for finding vulnerabilities. Usually, this involves getting a device or accessing a device on the network, attacking it as a black box, and finding a way in. [Gerrado] realized that some vendors now supply virtual images of their appliances for testing, so instead of attacking a device on the network, he put the software in a virtual machine and attempted to gain access to the device. Understanding the steps he took can help you shore up your defenses against criminals, who might be after more than just a manufacturer’s debugging bounty.
Continue reading “Hacking a Device That Lives Inside the Matrix”
[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?
[Ronnie] recently posted a new chapter in his adventures in malware deconstruction. This time the culprit was an infected Excel spreadsheet file. The .xls file was attached to a phishing email claiming to be related to a tax rebate. With tax season in full swing, this type of phishing message would be likely to be opened by an inexperienced user.
[Ronnie] saved the file to a virtual machine to prevent his real workstation from getting infected. He then opened it up in Excel and noticed that it immediately attempted to run macros. A macro is essentially visual basic scripting that runs inside of the spreadsheet file. You can use it for simple automation, cell formatting, or do even more complicated tasks like reach out to external websites and pull information. This malware focused on the latter.
[Ronnie] used the alt + F11 shortcut to view the macros. Unfortunately the attackers had password protected them. [Ronnie] wouldn’t be able to view the macro code without knowing the password. Luckily, he learned of a surprisingly simple trick to completely bypass the macro password. He opened up the .xls file in Notepad++ and located three keys; CMG, DPB, and G. [Ronnie] then created and saved a new blank .xls document and password protected the macros with his own password. He opened up this new file in Notepad++ as well, and located those same three keys. He copied the keys from the new file into the old one, and saved the old file. This effectively changed the password of the malware file to the new one he had set for his new file. This is a nifty trick that apparently only works on the older .xls formats, not the newer .xlsx format.
After loading the macros, [Ronnie] quickly noticed that most of the code was obfuscated to make it difficult to analyze. There were, however, three named modules that reference possible sandbox evasion techniques. The malware first invokes these functions to detect the presence of a virtual machine or other type of sandbox. If it detects nothing, then the rest of the malware program is decoded and executed. [Ronnie] removed these checks and then executed the macro to verify that his change had worked.
The next step was to try to view the decoded instructions. The decoded gibberish was saved to a variable. The simplest way for [Ronnie] to view the contents of the variable was to have the program create a pop-up box that displayed the contents of that variable. After making this change and running the program again, he was able to see exactly what the malware was doing. The code actually invoked Powershell, downloaded a file from the Internet, and then extracted and executed that file. In the full write-up, [Ronnie] goes even further by downloading and analyzing the executable.
Zork, Hitchhiker’s Guide to the Galaxy, and all the other Infocom text adventures are much more clever than the appear at first glance. They actually run on a virtual machine, with all the code for the game files squirreled away in the Z-machine format. This is great if you’re writing a game for a dozen platforms; once you have an interpreter running on one system, the entire library of games can be shipped out the door.
While the Z-machine has been ported to all the retrocomputers you can imagine and a few different brands of microcontrollers, no one has yet implemented the Z-machine in hardware. There’s a reason for this: it’s crazy. Nevertheless, [Charlie] managed to implement the Z-machine in an FPGA, using only a few extra commands for driving a display.
The circuit is constructed with a $10 eBay special FPGA, the Cyclone II EP2C5. Other than that, it’s just some Flash, some RAM, a display, and a whole lot of wire. The standard Z-machine spec is followed, version 3 specifically, meaning this text adventure on a chip can run nearly every Infocom game ever written. The most popular ones, at least.
This isn’t [Charlie]’s first time in the ring with the Infocom Z-machine. He ported the Z-machine to a freakin’ pen a few years ago.
You can check out [Charlie]’s video demo below. Because there was a bit of extra space in the FPGA, [Charlie] managed to put a Mandelbrot implementation and Space Invaders in as an easter egg.
Continue reading “The Zork Virtual Machine Implemented In Hardware”
[Michael Kohn] sent in a link to the set of projects he’s been working on lately. The Java Grinder is a project that converts Java code for use on microcontrollers. This actually started back in 2009, when he mentioned that the project was worthless because there were already a ton of Java virtual machines out there. But if he had really thought that he’d never learn anything. We’re glad [Michael] picked this back up and made something out of it.
The image above shows the proof of concept. It’s a box bouncing around the Nokia 6100 screen. He wrote the animation in Java, and used his grinder to turn the code into dsPIC assembly, which was then compiled and flashed onto the microcontroller. That’s not all, he’s also coded a Mandelbrot set generator or the same hardware. As it stands he can also produce assembly code for use on MSP430 chips.
This kind of exploration is great for the brain. We see it as a natural extension of the learning you acquire from Nand2Tetris which walks through the essential text The Elements of Computing Systems. If you’re not familiar, that’s a trip from building your first logic gate, which you plunk together with others to build an ALU, then start coding all the way up to a virtual machine to run on your simulated hardware.
Video of the bouncing box and Mandelbrot set is below.
Continue reading “Java Grinder Spits Out dsPIC and MSP430 Assembly Code”