November 7th, 2007 Greg
Of the many programs I’ve taken the time to probe and dissect, none has instilled me with such a love-hate sensation as iTunes. My favoured media player by some distance, it is beautiful, easy to use, cleanly written, reliable, and all the rest. But with the iTunes (Music) Store came iDRM, as DVD Jon famously termed it. Apple make it pretty clear that they don’t like DRM any more than the users do, but that their hands are tied, and I respect that. Why then do they insist on doing such a bloody good job of making it very difficult to crack? Everybody knows that it will be broken sooner or later, so why go to all the effort - and it is a lot of effort - to choose ‘later’?
After months of sitting quietly while Apple’s DRM remained unbroken, with my previous encounters with iTunes encryption in mind (maybe I’ll write about them some day) I felt compelled, maybe even prepared, to take matters into my own hands. This was the birth of DisaRM, my home-grown iDRM-removal tool.
Why have you never heard of it? Well, call me a selfish coward but I didn’t want the attention or bother of being responsible for maintaining such a keenly sought taboo. And why didn’t I release the source code? Partly because my method was so awfully hacky, as you’ll see, that most programmers would run a mile. As it happened, QTFairUse6 was released mere days after I produced a working prototype (and well before DisaRM was ready for human consumption) so the onus was lifted.
For the sake of education, and self-indulgence, I’ll take a few posts to describe the story of DisaRM, gory details included.
Posted in RCE | 2 Comments »
November 5th, 2007 Greg
DLL Hell, SxS libraries, manifest files, ‘The application configuration is incorrect’.
Oh my!
It seems that every C++ blogger and his dog is talking about the side-by-side hell that Microsoft have cooked up, but after having a hard enough time finding answers myself, I figured that it’s best to be part of the solution. If you’ve stumbled upon this post from a Google search, it’s likely that you’re one of the many poor souls who has no idea why their program refuses to run on any computer other than the one it was compiled on.
![[Side-by-side error message]](/images/sxs.png)
The necessity for all of this incompatibility is clear when you consider how many different versions of the Windows kernel interfaces are floating around, but it’s still a pain for those of us who just want to compile a program for personal use. The most correct way to address the situation is to package your application with the MSVC++ runtime library. This way, the executable can’t be used without running an installer that ensures all the appropriate DLLs are present. But for most of us this is unnecessary bloat, and VC++EE doesn’t even offer a means of producing such a setup package.
There is a lot of talk about determining the dependencies with a PE-viewer or the dependency-walker, copying the appropriate SxS DLLs from Windows/WinSxS/ to a carefully-crafted directory hierarchy, and manually editing an XML manifest file to tell the OS how to find them. This is error-prone, beginner-unfriendly and seems to be causing more confusion than good.
But the solution that Microsoft have kept quiet is somewhat cleaner. If you configure the Visual C++ IDE to statically link against the multithreaded libraries (Project | Properties | Configuration Properties | C++ | Code Generation | Runtime Library := Multithreaded [Debug]) then the program will never have any such unpredictable external dependencies and so avoids the problem altogether. This will of course mean that you have an extra 150kB of PE to carry around, which may be undesirable for widely-distributed DLLs, but for small-time projects it’s a worthwhile trade.
Posted in Game Programming | No Comments »
November 5th, 2007 Greg
There’s something uncomfortable about setting up a machine to be as insecure as possible, but that’s what I’ve been doing today. Not being the sort to have sacrificial computers lying around, I settled for a virtual machine. So after a quick and easy installation of the VMare Workstation trial, I got straight to setting up Vaughn, my computer-within-a-computer.
The oldest non-biblical version of Windows I have is XP Pro SP1. While it isn’t that old, it’s still vulnerable to the RPC exploit responsible for the 2003 Blaster Worm epidemic, and is still one of the most popular avenues for the black-hat hacker. So after installing the OS, automatic updates were turned off and the bridged network connection was added to my router’s demilitarised zone, to make sure that Vaughn was fully exposed to the internet. XP SP1 didn’t distribute with a firewall, so that’s not a problem. Some essential pieces of software were installed including my full RCE toolkit and the excellent Wireshark packet analyser. Even though no outbound connections are made on the VM’s part, simply being on an active LAN is enough to invite some network traffic, so I had to set up a filter to remove the unrelated packets picked up by Wireshark. So as to prevent Vaughn participating in anything he shouldn’t, I installed an upstream-bandwith throttler and configured the connection to filter any known DoS traffic.
So now we wait, for as long as it takes. Maybe forever. Or at least until my VMware trial expires.
Posted in RCE | 5 Comments »
November 4th, 2007 Greg
While universally troublesome and inherently evil, there’s something exciting, even sexy, about zombie networks. The idea that somewhere out there is a global army of dormant computers, their owners blissfully unaware, which could spring to life at the whim of a bedroom hacker and coordinate DDoS attacks to take down a country’s internet presence, distribute unimaginable quantities of spam, or crack a 56-bit DES key in minutes – it’s the stuff of science fiction. Only it isn’t, and the Storm botnet is testament.
Many of us grey-hat hackers fantasise about controlling such power but don’t have the time, skills, lawyers or lack of moral-fibre to do anything about it. So what’s the next best thing? Well that would be to play with somebody else’s illegal toy.
The first step is to get hold of the worm. You’d think it would be easy enough to get hold of a program whose primary goal is to spread to the ends of the earth, but it’s actually trickier than you might imagine to come by a sample or network that isn’t already tainted by the holy paws of the antivirus companies of the world. So rather than giving myself a headache, I plan to let the worms do the work and wait for them to come to me.
In the coming days, I’ll be setting up a honeypot and crossing my fingers. I have promised to analyse and, if necessary, publicly humiliate any interesting malware that comes my way. With a little skill and a lot of luck, I may even find myself to be the proud owner of a zombie, albeit a neutered one.
Posted in RCE | No Comments »
