[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”
[Damien George] just created Micro Python (Kickstarter alert!), a lean and fast implementation of the Python scripting language that is optimized to run on a microcontroller. It includes a complete parser, compiler, virtual machine, runtime system, garbage collector and was written from scratch. Micro Python currently supports 32-bit ARM processors like the STM32F405 (168MHz Cortex-M4, 1MB flash, 192KB ram) shown in the picture above and will be open source once the already successful campaign finishes. Running your python program is as simple as copying your file to the platform (detected as a mass storage device) and rebooting it. The official micro python board includes a micro SD card slot, 4 LEDs, a switch, a real-time clock, an accelerometer and has plenty of I/O pins to interface many peripherals. A nice video can be found on the campaign page and an interview with the project creator is embedded after the break.
Continue reading “Interview with [Damien George], Creator of the Micro Python project”
[Cyber Explorer] recently ditched his collection of physical computers acting as servers by virtualizing the lot of them. But with every change there’s a drawback. Although it wasn’t too hard for him to set up the virtual machines, he did end up spending quite a bit of time trying to improve the bandwidth. Luckily he posted an article chronicling all of the VM tweaks he used to improve the system.
The experience involves both a Windows 8 machine, as well as a some Linux boxes meaning there’s something here for everybody. At each step in the process he performs some throughput tests to see how the boxes are performing. Tweaks are numerous, but include trying out different Ethernet drivers, making sure all modules are up to date, squashing at least one bug, and giving jumbo-frames a try.
[Dan] has his own Stratasys Dimension SST 768 3D printer. It’s a professional grade machine which does an amazing job. But when it comes time to replace the cartridge he has to pay the piper to the tune of $260. He can buy ABS filament for about $50 per kilogram, so he set out to refill his own P400 cartridges.
Respooling the cartridge must be quite easy because he doesn’t describe the process at all. But the physical act of refilling it doesn’t mean you can keep using it. The cartridge and the printer both store usage information that prevents this type of DIY refill; there’s an EEPROM in the cartridge and a log file on the printer’s hard drive. [Dan] pulled the hard drive out and used a Live CD to make an image. He loaded the image in a virtual machine, made some changes to enable SSH and zap the log file at each boot, then loaded the image back onto the printer’s drive. A script that he wrote is able to backup and rewrite the EEPROM chip, which basically rolls back the ‘odometer’ on how much filament has been used.
[Dan] wrote in to share a link to his MythTv to Apple TV setup. He found a way to make the recordings he made on his Linux box available on the 2nd Generation Apple TV. Our first thought is that he would use XBMC on a jailbroken device but that is not the case. The secret is to roll iTunes into the mix.
Take a look at the diagram above. The system starts with an Arch Linux box that runs MythTV, an open source program which allows you to record from tuner or encoder hardware. But actually watching those recordings on an iOS device is difficult for a couple of reasons. First, Apple likes to keep their devices locked up tight in hopes that you buy your entertainment rather than watching over-the-air records. Second, if you’re recording ATSC channels the files may be 1080i or 1080p, neither of which can be handled by the Apple TV 2. [Dan] gets around this by first using the command line version of Handbrake to transcode the recordings to an h264 format. He then uses iTunes running on an Windows 7 virtual machine (on the Linux box) to host the transcoded files in a library the Apple TV can access.