His account was not suspended and the link is not dead, It's a traffic issue. Vistors to his personal blog went from nothing to over 60,000 hits in less than 24 Hours.
This is from his blog
Update on Driver Signing Bypass
I apologize for the lack of news, but after attending CUSEC, I had to spend my time on catching up the two weeks of school and work that I had missed, and exploiting Vista ended up going on the backburner, especially as I had to re-install VMWare 6.0 (which wasnâ€™t being helpful with me) and a new Vista 64-bit image.
That being said, it turns out the code Iâ€™ve written does not work out of the box on a Vista RTM system. Although it can be effective when combined with a reboot, this doesnâ€™t provide any advantage of any of the myriad other ways that this could be done (including booting with the disable integrity checks BCD option or the /TESTSIGN flag).
However, it does bypass DRM. As part of the Protected Media Path, (PMP), Windows Vista sets up a number of requirements for A/V software and drivers in order to ensure it complies with the demandes of the media companies. One of these features, which has been heavily criticized as being the actual reason behind driver signing, is that â€œsome premium content may be unavailableâ€ if test signing mode is used. Originally, I assumed that this meant that the kernel would set some sort of variable, but this didnâ€™t make sense: once your unsigned driver could load, it could disable this check. After reading the PMP documentation however, it seems to me that the â€œfeatureâ€ explained is more likely the cause of this warning on premium content.
This feature is the ability of the PMP to notify A/V applications that there are unsigned drivers on the system, as well as provide a list of unsigned drivers. The idea is that the application can either outright refuse to play content, or that it can scan for known anti-DRM drivers which might be attempting to hook onto the unencrypted stream. This leads me to believe that itâ€™s up to applications, not the OS, to enforce this DRM check.
The great thing about the code Iâ€™ve written is that it does NOT use test signing mode and it does NOT load an unsigned driver into the system. Therefore, to any A/V application running, the system seems totally safe â€” when in fact, itâ€™s not. Now, because Iâ€™m still booting with a special flag, itâ€™s possible for Microsoft to patch the PMP and have it report that this flag is set, thereby disabling premium content. However, beause I already have kernel-mode code running at this point, I can disable this flag in memory, and PMP will never know that it was enabled. Again, Microsoft could fight this by caching the value, or obfuscating it somewhere inside PMPâ€™s kernel-mode code, but as long as itâ€™s in kernel-mode, and Iâ€™ve got code in kernel-mode, I can patch it.
To continue this game, Microsoft could then use Patchguard on the obfuscated valueâ€¦but that would only mean that I can simply disable Patchguard using the numerous methods that Skywing documented in his latest paper.
In the end, the only way that PMP is going to work is with a Hypervisor, and even that will probably fail.
Unfortunately, with almost 0% use for the open source community (which can use test signing mode for their drivers), documenting my method and/or releasing a sample might be viewed as an anti-DRM tool, and defintely a DMCA violation. Although used on its own, this POC doesnâ€™t do anything or go anywhere near the PMP (I donâ€™t even have Protected Media, HDMI, HD-DVD, nor do I know where PMP lives or how someone can intercept decrypted steams), a particularly nasty group of lawyers could still somehow associate the DMCA to it, so Iâ€™m not going to take any chances.
Itâ€™s quite ironic â€” Microsoft claims driver signing is to fight malware and increase system stability, so if I get sued under DMCA, wouldnâ€™t that be an admission that driver signing is a â€œanti-copyright infringment toolâ€?.
Iâ€™d really love to release this tool to the public though, so I will look into my options â€” perhaps emphasizing the research aspect of it and crippling the binary would be a safe way.
After initially being slashdotted, my blog post below got linked across the blogosphere, hit Digg, the Inquirer, BoingBoing and other major news sites, and Iâ€™ve reached some 60 000 visitors in less than 24 hoursâ€¦
Since most of you are therefore new visitors, I just wanted to post a short introduction/information paragraph. First of all, I suggest you visit the About page of the blog, as well as my Wiki page on the ReactOS website. This is just to clear up any confusion on where I currently reside, age, education, etc. If you are interested in my other publications/works as a security researcher, you should visit the Publications page, as well as OpenRCE, where I usually post my latest articles. You can also find a recording of my REcon 2006 talk on Archive.Org. Search for my name; the PDF is available on the Publications page as well. Finally, my project, ReactOS, is having a donation fund; if youâ€™d like to donate some money, that would be very appreciated.
As for the DRM post, I never expected that it would get the kind of attention it has; to be fair, I had completely forgotten that today was Vistaâ€™s launch date (being a beta tester, Iâ€™ve had RTM for months now); I certaintly donâ€™t want to make it seem like I was specifically targetting this day to release anything. Later this week I will release some safe, generic, proof of concept code that targets what I believe is a flaw in the Code Integrity/Driver Signing model. My 64-bit VM is running extremly slow, so it will take me some time to test the code. Because this code will require an initial reboot, Microsoft does not consider it to be a flaw from a security standpoint. And because itâ€™s so generic, it has absolutely nothing to do with DRM or PMP. That being said, Iâ€™m sure someone with knowledge of the PMP implementation might be able to use this as a very smart building block of the entire code that would be required; but that would be like arresting every knife manufacturer because knives can kill people.
Finally, if any of you would like more information about ReactOS or would like to meet in person, I will be giving a talk at the SOCAL5X conference on February 9th, and I will be around LA on the 10th as well.