[Ronnie] recently posted about his adventures in decoding malware. One of his users reported a phishy email, which did indeed turn out to contain a nasty attachment. The process that [Ronnie] followed in order to figure out what this malware was trying to do is quite fascinating and worth the full read.
[Ronnie] started out by downloading the .doc attachment in a virtual machine. This would isolate any potential damage to a junk system that could be restored easily. When he tried to open the .doc file, he was presented with an error stating that he did not have either enough memory or disk space to proceed. With 45GB of free space and 2GB of RAM, this should not have been an issue. Something was definitely wrong.
The next step was to open the .doc file in Notepad++ for analysis. [Ronnie] quickly noticed that the file was actually a .rtf disguised as a .doc. [Ronnie] scanned through large chunks of data in an attempt to guess what the malware was trying to do. He noticed that one data chunk ended with the bytes “FF” and D9″, which are also found as the ending two bytes of .gif files.
[Ronnie] copied this data into a new document and removed all new line and return characters. He then converted the hex to ASCII, revealing some more signs that this was actually image data. He saved this file as a .gif and opened it up for viewing. It was a 79KB image of a 3D rendered house. He also found another chunk of data that was the same picture, but 3MB in size. Strange to say the least.
After finding a few other weird bits of data, [Ronnie] finally started to see more interesting sections. First he noticed some strings with mixed up capital and lowercase letters, a tactic sometimes used to avoid antivirus signatures. A bit lower he found a section of data that was about the size of typical shellcode. He decoded this data and found what he was looking for. The shellcode contained a readable URL. The URL pointed to a malicious .exe file that happened to still be available online.
Of course [Ronnie] downloaded the .exe and monitored it to see how it acted. He found that it set a run key in the registry to ensure that it would persist later on. The malware installed itself to the user’s appdata folder and also reached out repeatedly to an IP address known to be affiliated with ZeuS malware. It was a lot of obfuscation, but it was still no match for an experienced malware detective.
Light painting, or taking a picture of a moving RGB LED strip with a very long exposure, is the application du jour of Arduinos, photography, and bright, glowey, colorful things. Hackaday alumnus [Phil Burgess] has come up with the best tutorial for light painting we’ve seen. It’s such a good setup, it can be used to create animated .gifs using multiple camera exposures.
The build uses an Arduino Uno, SD card shield, and Adafruit’s new NeoPixel strip with 144 RGB LEDs per meter. Despite a potentially huge mess of wires for this project, [Phil] kept everything very, very neat. He’s using an Altoids case for the ‘duino, an 8 AA-cell battery holder and 3A UBEC for the power, and a wooden frame made out of pine trim.
Part of the art of light painting involves a lot of luck, exponentially so if you’re trying to make a light painted animated .gif. To solve this problem, [Phil] came up with a very clever solution: using a rotary encoder attached to a bicycle. With the rotary encoder pressed up against the wheel of a bike, [Phil] can get a very precise measurement of where the light strip is along one dimension, to ensure the right pixels are lit up at the right time and in the right place.
It’s a wonderful build, and if Santa brings you some gift certificates to your favorite electronics retailer, we couldn’t think of a better way to bring animated .gifs into the real world.
Ditch that fancy wide-format LCD monitor and go back to the days when animation was made up of moving frames played back by a specialized device. [Pieterjan Grandry] built this gif player which does just that. The frames of the animation are printed on a paper disk. When spun and viewed through a looking hole the same size as one frame an animated image is formed.
If you know a thing or two about how movie projectors work you might have a raised eyebrow right now. To make the animation smooth you need a way to hide the changing of the frames. With a projector there’s usually a spinning shutter (like a fan) that covers the transition between frames. In this case, [Pieterjan] has mounted the case of the gif player far enough in front of the paper disk that the image is in shadow, making it hard to see. A microcontroller responsible for the speed of the spinning disk flashes some white LEDs with precise timing which gives light to each frame at just the right time.
This is really a 2D equivalent to the 3D stroboscope we saw a few days ago.
[Fergus Kendall’s] company is making development and breakout boards targeting electronic hobbyists. As with any endeavor that involves selling something, they need marketing. It sounds like [Fergus] was put in charge of getting some nice animated 360 degree images of each component. Instead of going through the drudgery of snapping frames by hand in a stop-motion-style, he whipped up a rotating platform that does the work for him.
The brain of the operation is a Boobie Board, a microcontroller breakout board that is one of their products. It controls a stepper motor attached to the cardboard platform via a quartet of power transistors. [Fergus] mentions in passing that their digital camera didn’t have a connection for a shutter trigger attachment. But they modded it to make things work. There’s no detail on that part of the hack but we’d wager that they soldered a transistor to the contacts for the shutter button.
The stepper motor has 48 steps, so the hardware is programmed to take 48 pictures which become the frames of an animated GIF – embedded after the break – to show off the product.
Continue reading “Photo hardware that automatically produces rotating GIFs”
Researchers at NGS Software have come up with a method to embed malicious code into a picture. When viewed, the picture could send the attacker the credentials of the viewer. Social sites like Facebook and Myspace are particularly at risk, but the researchers say that any site which includes log ins and user uploaded pictures could be vulnerable. This even includes some bank sites.
The attack is simply a mashup of a GIF picture and a JAR (Java applet). The malicious JAR is compiled and then combined with information from a GIF. The GIF part fools the browser into opening it as a picture and trusting the content. The reality is, the Java VM recognizes the JAR part and automatically runs it.
The researchers claim that there are multiple ways to deal with this vulnerability. Sun could restrict their Virtual Machine or web applications could continually check and filter these hybrid files, but they say it really needs to be addressed as an issue of browser security. They think that it is not only pictures at risk, but nearly all browser content.
More details on how to create these GIFARs will be presented at this week’s Black Hat conference in Las Vegas.