I continue to add little bits of other people's Javascript on the side of my blog. I just added some code from Technorati. Earlier, I added a hit tracker from Sitemeter and am publishing my RSS feed via Feedburner. The Technorati and Sitemeter things are raw Javascript includes. Oh, and I've started using Zooomr pictures, more Javascript. I haven't added the dozen "pick me!" buttons from Digg et al, yet. But I'm not ruling it out in the future. I don't plan to turn on the ads, but that's just more of the same.
The point is, if you want to 0wn my readers, just compromise Blogger, Technorati, Sitemeter, Zoomr or Feedburner. Or maybe something they depend on. Then you can hand out all of the browser exploits in my name you want.
It's not like attacking one site to compromise another has never been done, or that I haven't been targeted before. I'm just saying.
Web 2.0 is looking a lot like a huge interconnected chain of transitive trust. See also: myspace.
Friday, January 19, 2007
Thursday, January 11, 2007
AACS crack update
So I made some bad assumptions in my earlier post about the AACS crack. That's what I get for assuming and not hunkering down to read the spec. I know more about it now because of today's Freedom to Tinker post from J. Alex Halderman. He explains:
Halderman refers to the process as "some serious crypto wizardry." Now, I still haven't read the spec, and he has. But I don't see why this should be significantly more complicated than the whole CA/PKI arrangement. The AACS guys probably are a master CA, the licensees are sub-CAs, and they issue a private key/cert pair to each device. When there's a leak, the AACS people can surgically revoke the leaked set.
Does this change the end game? I don't think so. Halderman talks about some possible things like a title key-issuing oracle. Sounds like too much trouble to me. Here's how I think I might do it:
Other potential problems that I foresee popping up:
Blacklisting would be a PR and business disaster if it meant a lot of consumers had to throw away their fancy players as a result of a crack. That’s why AACS allows each individual player to be assigned its own unique set of device keys that can be uniquely blacklisted without adversely affecting other players.So, the AACS people are smarter than I gave them credit for. If manufacturers follow recommendations and issue individual keys to each device, then only one person's device is disabled, and there's a good chance that person was involved in leaking the key, so maybe that's appropriate. Further, Halderman says that they only disable new discs with the revocation, and they don't brick the device. Hm, I guess they are nicer than I might be in their situation. ;)
Halderman refers to the process as "some serious crypto wizardry." Now, I still haven't read the spec, and he has. But I don't see why this should be significantly more complicated than the whole CA/PKI arrangement. The AACS guys probably are a master CA, the licensees are sub-CAs, and they issue a private key/cert pair to each device. When there's a leak, the AACS people can surgically revoke the leaked set.
Does this change the end game? I don't think so. Halderman talks about some possible things like a title key-issuing oracle. Sounds like too much trouble to me. Here's how I think I might do it:
- Put in the hard work to find some software or hardware device that I know how to recover the keys from; leak those keys, and only the one set
- At my leisure, stock up as many other keys as I think I'm going to need
- Wait for the script kiddies to complain that Star Trek XV won't work with my keys
- Leak the next set
Other potential problems that I foresee popping up:
- Maybe I flood the Internet with tons of keys. The revocation list gets large and unwieldy. Maybe discs start to fill up, maybe players take forever to parse through them.
- I don't expect the software players to cut a key for every single user, especially if it's like current DVD player software that gets thrown in the box of every Dell computer. They don't want to cut custom CDs, and I assume these keys are all too long to type in from a printed label. On the contrary, the Internet would work fine for some soft of "activation" scheme which gets you a key set right then and there. The problem with that is that you now have a website that essentially cuts keys for you at will, and they have their CA private key stored somewhere where it could get stolen.
- I don't expect every Taiwanese hardware manufacturer to do what they are supposed to, and they will reuse player keys
- Someone could leak or steal a CA keyset
- There might be a crypto break like with CSS
- And last but not least, how about I keep my keys to myself, and just release the decrypted movies?
Wednesday, January 10, 2007
Testing Zooomr
Please stand by, I'm trying to see how Zooomr works with Blogger.
Here's a picture of part of one of my bookshelves:
OK, looks like Blogger really wants you to limit things to sizes that work with their layout. I guess I'll be sticking to small sizes that you can blow up by clicking on.
Now, to see why Zooomr doesn't store the original size... Ah, OK once you have a Pro account, it looks like you get to keep the original size, too.
Also, it would be ungenerous of me to not point out that Zooomr is giving away free Pro accounts for something as simple as posting a pic like this on your blog.
Here's a picture of part of one of my bookshelves:
OK, looks like Blogger really wants you to limit things to sizes that work with their layout. I guess I'll be sticking to small sizes that you can blow up by clicking on.
Now, to see why Zooomr doesn't store the original size... Ah, OK once you have a Pro account, it looks like you get to keep the original size, too.
Also, it would be ungenerous of me to not point out that Zooomr is giving away free Pro accounts for something as simple as posting a pic like this on your blog.
Unpacking I
Recently, I was given a copy of a piece of malware by Curt Wilson. He had unpacked it in memory, but wasn't quite sure how to finish the process in order to load it up again for further analysis. As a simple howto, and as a way to keep a few notes for myself, I'm documenting the unpacking process.
The sample in question was found as upnp.exe on disk. Looking at it, it was packed with Morphine. I don't personally consider knowing which packer it is ahead of time to be critical, though there are a couple of exceptions. First, if I know it is UPX packed, then I may just try using the latest UPX to unpack it. It works maybe half the time. The other half, there are UPX "corrupters" out that there will break that, and there is at least one packer designed to look somewhat like UPX. Second, there are a couple of packer out there that are probably easily beyond my skill level, and I wouldn't bother trying. The two I can think off of the top of my head are both written by Nicolas Brulez.
If you want to find out what packer was used, you can usually get an answer from PEiD, or by trying the VirusTotal service. Here is the VirusTotal analysis of upnp.exe, for example. Both of those correctly identify this as Morphine, though I got through the hard part of the unpacking without knowing that.
The basic unpacking technique is to execute the program with a debugger until the original binary (or as much as is left) is uncompressed in memory, and then you dump the copy in memory. Usually, when you dump it you also fix the imports so that your analysis tool will know which functions are being called. I'll show you an example in a moment. For a somewhat more advanced example, you can watch a video where Nicolas does an unpack on a binary that has more than one packer used on it, each with multiple antidebugging tricks. This was from a talk we gave at RECON.
First thing, the warnings: If you choose to try to unpack malware, you are taking a chance that you will make a mistake, and just run the thing. If you do this on a real production machine, you will be sad, and infected. If you're smart, you will have a sacrificial machine you can do this on, that you can restore to a known state with no place for the malware to hide. VMWare is popular, though unfortunately, a lot of malware now checks to see if it is running in a VM and shuts down.
The strictest AV guys will also tell you that it is irresponsible to do any analysis on a non-isolated machine, because there's a good chance you will spread it further. If you work on a non-isolated machine and people find out, there's a chance that some or all AV companies will never employ you. That may not seem like much of a threat, but you never know who Symantec or McAfee are going to buy next.
In other words, do as I say, not as I do. When you press the wrong button in your debugger, and run the malware all the way, you will find yourself very interested in finishing the analysis in a hurry in order to find out what you've just done to your machine. You should also know which cable to pull in a hurry to disconnect yourself from the Internet.
So, on with the debugging. Load the program in your favorite debugger. I like to use the debugger now built into IDA Pro. Another popular (and free) debugger is Ollydbg. With both, you need to set an initial breakpoint, and then run the program. Generally speaking, what you will be doing is stepping through the code until you get to the point where you think you've hit the original packed binary, then you leave it paused.
This is the easiest place to screw up. For one, in both debuggers, the step, step over, and run keys are all next to each-other. If you fat-finger the keypress, you just infected your machine. Also, you may encounter antidebugging tricks. I can't say I noticed any with Morphine, but I have certainly seen them with others. Even if you're single-stepping, if you miss accounting for an antidebugger trick, you may find that the program finishes executing without you.
One of the things that pretty much all packers do is to replace a certain portion of the OS's loader. For Windows, this almost always means replacing the portion that takes care of loading and mapping the imports. So, if you are tracking through packer code, you will see the packer calling LoadLibrary and GetProcAddress, in a loop. Packers also almost always compress and/or obfuscate the binary code, so there's also going to be some loops where it is iterating over memory segments. These memory segments are usually create by calling VirtualAlloc.
I bring this up, because you really, really want to step over these functions and not waste time stepping through them or trying to follow them into the kernel. You will also need to become adept at spotting loops. You will need to skip those most of the time, just because they will be too tedious to step through manually. Yet another place to screw up.
Here's an example of something I can spot from experience:
You see where it's pushing a bunch of bytes in the ASCII range onto the stack, and then calling something? Let me decode it to make it a little easier to read:
Read the function names backwards. This tells me I'm in the beginning stages of restoring the imports. Then it calls VirtualAlloc:
And you trace through some loops where it is importing all the libraries and fixing up pointers to the functions.
Eventually, you will arrive at something like this:
There is often a telltale "JMP EAX" or "CALL EAX", or similar. Step one more instruction, and you're at the Original Entry Point (OEP). This is when you're unpacked, or as much as you're going to be. If you trace much farther, you start initializing things, and you might start causing trouble for your analysis. This is what it looks like when we're at the OEP:
I usually like to take note of the OEP and the last address before the OEP. I like to set a hardware breakpoint on execute at one or both of those. In this case, the OEP isn't mapped to a memory segment until after the program has run some portion of the way through the packer, so I set it on the last address before the OEP, and save the database. That way, if I have trouble with the dump step, I can replay right up to that point without having to manual step it again. That works in this case (Morphine) but not in all cases. Sometimes you have to account for antidebugger tricks along the way.
Now that you're at the OEP, you need to dump the binary in memory. I've used two tools for this, Import Reconstructor (imprec) and LordPE. Before I get into the technical details on each, I should talk about the reason I ended up putting this post together.
I was having some trouble getting a good dump of upnp.exe. Specifically, I had traced it to the OEP as I have described, but I couldn't get imprec to dump it properly. The imports table wouldn't come out right. That's when I went to Jason Geffner for help. Jason is another of these guys who is better at reverse engineering than I am. I met him originally in the class I took from Nicolas Brulez. Jason was taking it too, but he didn't really need it.
Jason wanted told me to just use LordPE. He said that Morphine ended up rebuilding the original PE file in memory, and that LordPE did a perfect dump. He even made a screenshot of what settings I should use:
Sure enough, I used LordPE and it dumped perfectly. I'd had good luck with imprec before. Nicolas had shown me the tool in his class. Before that I had been doing raw memory dumps and manually naming offsets. No fun. So I've had a tendency to reach for imprec because I'm used to it.
But, there was no arguing with the fact that LordPE worked for me in this case, and imprec didn't. So part of what I planned to do with this post was to recommend LordPE. So I repeated the steps on my home machine so I could take screenshots and so on. When I got to the step where I was going to show the bad dump made by imprec... I found that it had dumped it perfectly.
Thinking back, I believe why imprec didn't work before was because I had done it on a work machine, which was Windows XP x64. When I tried to use imprec on the 64-bit Windows, I had a problem with some of the imports not being valid. That probably had to do with why it wasn't writing out the import table properly. I had removed the "bad" imports, but it probably just broke the process. I think I was able to use LordPE on the same machine, but now I'm going to have to go back and check.
Which brings me to a general point about tools. If you've got tools you use that did into the guts of a system, then those tools are probably going to quit working when you move to a newer system. This is especially true of tools for which development has ceased (which seems to be the case with imprec.) If it's not being actively maintained, then it will eventually "expire" when the OS moves on. On my home machine, which is regular XP, imprec still works fine. Further, malware and packers tend to account for popular tools by implementing countermeasures. So, if you plan to keep up on reverse engineering, you should also plan to keep looking for the latest and greatest tools.
But in any case, my thanks to Jason for encouraging me to check out LordPE and for fixing my mistake. Back to the techie bits.
I'll skip the imprec demo for now. If you're interested in me spelling out the same steps for imprec, leave me a comment, and I'll write it up. In LordPE, you basically run the tool, find the process you still have paused at the OEP in your debugger, right-click it and select dump full:
In this particular case at least, you now have a good copy of the unpacked executable, and you can load it up in your favorite analysis tool:
If you're curious, the binary is a fairly typical call-home-to-an-IRC-C&C bot.
Notes:
The sample in question was found as upnp.exe on disk. Looking at it, it was packed with Morphine. I don't personally consider knowing which packer it is ahead of time to be critical, though there are a couple of exceptions. First, if I know it is UPX packed, then I may just try using the latest UPX to unpack it. It works maybe half the time. The other half, there are UPX "corrupters" out that there will break that, and there is at least one packer designed to look somewhat like UPX. Second, there are a couple of packer out there that are probably easily beyond my skill level, and I wouldn't bother trying. The two I can think off of the top of my head are both written by Nicolas Brulez.
If you want to find out what packer was used, you can usually get an answer from PEiD, or by trying the VirusTotal service. Here is the VirusTotal analysis of upnp.exe, for example. Both of those correctly identify this as Morphine, though I got through the hard part of the unpacking without knowing that.
The basic unpacking technique is to execute the program with a debugger until the original binary (or as much as is left) is uncompressed in memory, and then you dump the copy in memory. Usually, when you dump it you also fix the imports so that your analysis tool will know which functions are being called. I'll show you an example in a moment. For a somewhat more advanced example, you can watch a video where Nicolas does an unpack on a binary that has more than one packer used on it, each with multiple antidebugging tricks. This was from a talk we gave at RECON.
First thing, the warnings: If you choose to try to unpack malware, you are taking a chance that you will make a mistake, and just run the thing. If you do this on a real production machine, you will be sad, and infected. If you're smart, you will have a sacrificial machine you can do this on, that you can restore to a known state with no place for the malware to hide. VMWare is popular, though unfortunately, a lot of malware now checks to see if it is running in a VM and shuts down.
The strictest AV guys will also tell you that it is irresponsible to do any analysis on a non-isolated machine, because there's a good chance you will spread it further. If you work on a non-isolated machine and people find out, there's a chance that some or all AV companies will never employ you. That may not seem like much of a threat, but you never know who Symantec or McAfee are going to buy next.
In other words, do as I say, not as I do. When you press the wrong button in your debugger, and run the malware all the way, you will find yourself very interested in finishing the analysis in a hurry in order to find out what you've just done to your machine. You should also know which cable to pull in a hurry to disconnect yourself from the Internet.
So, on with the debugging. Load the program in your favorite debugger. I like to use the debugger now built into IDA Pro. Another popular (and free) debugger is Ollydbg. With both, you need to set an initial breakpoint, and then run the program. Generally speaking, what you will be doing is stepping through the code until you get to the point where you think you've hit the original packed binary, then you leave it paused.
This is the easiest place to screw up. For one, in both debuggers, the step, step over, and run keys are all next to each-other. If you fat-finger the keypress, you just infected your machine. Also, you may encounter antidebugging tricks. I can't say I noticed any with Morphine, but I have certainly seen them with others. Even if you're single-stepping, if you miss accounting for an antidebugger trick, you may find that the program finishes executing without you.
One of the things that pretty much all packers do is to replace a certain portion of the OS's loader. For Windows, this almost always means replacing the portion that takes care of loading and mapping the imports. So, if you are tracking through packer code, you will see the packer calling LoadLibrary and GetProcAddress, in a loop. Packers also almost always compress and/or obfuscate the binary code, so there's also going to be some loops where it is iterating over memory segments. These memory segments are usually create by calling VirtualAlloc.
I bring this up, because you really, really want to step over these functions and not waste time stepping through them or trying to follow them into the kernel. You will also need to become adept at spotting loops. You will need to skip those most of the time, just because they will be too tedious to step through manually. Yet another place to screw up.
Here's an example of something I can spot from experience:
You see where it's pushing a bunch of bytes in the ASCII range onto the stack, and then calling something? Let me decode it to make it a little easier to read:
Read the function names backwards. This tells me I'm in the beginning stages of restoring the imports. Then it calls VirtualAlloc:
And you trace through some loops where it is importing all the libraries and fixing up pointers to the functions.
Eventually, you will arrive at something like this:
There is often a telltale "JMP EAX" or "CALL EAX", or similar. Step one more instruction, and you're at the Original Entry Point (OEP). This is when you're unpacked, or as much as you're going to be. If you trace much farther, you start initializing things, and you might start causing trouble for your analysis. This is what it looks like when we're at the OEP:
I usually like to take note of the OEP and the last address before the OEP. I like to set a hardware breakpoint on execute at one or both of those. In this case, the OEP isn't mapped to a memory segment until after the program has run some portion of the way through the packer, so I set it on the last address before the OEP, and save the database. That way, if I have trouble with the dump step, I can replay right up to that point without having to manual step it again. That works in this case (Morphine) but not in all cases. Sometimes you have to account for antidebugger tricks along the way.
Now that you're at the OEP, you need to dump the binary in memory. I've used two tools for this, Import Reconstructor (imprec) and LordPE. Before I get into the technical details on each, I should talk about the reason I ended up putting this post together.
I was having some trouble getting a good dump of upnp.exe. Specifically, I had traced it to the OEP as I have described, but I couldn't get imprec to dump it properly. The imports table wouldn't come out right. That's when I went to Jason Geffner for help. Jason is another of these guys who is better at reverse engineering than I am. I met him originally in the class I took from Nicolas Brulez. Jason was taking it too, but he didn't really need it.
Jason wanted told me to just use LordPE. He said that Morphine ended up rebuilding the original PE file in memory, and that LordPE did a perfect dump. He even made a screenshot of what settings I should use:
Sure enough, I used LordPE and it dumped perfectly. I'd had good luck with imprec before. Nicolas had shown me the tool in his class. Before that I had been doing raw memory dumps and manually naming offsets. No fun. So I've had a tendency to reach for imprec because I'm used to it.
But, there was no arguing with the fact that LordPE worked for me in this case, and imprec didn't. So part of what I planned to do with this post was to recommend LordPE. So I repeated the steps on my home machine so I could take screenshots and so on. When I got to the step where I was going to show the bad dump made by imprec... I found that it had dumped it perfectly.
Thinking back, I believe why imprec didn't work before was because I had done it on a work machine, which was Windows XP x64. When I tried to use imprec on the 64-bit Windows, I had a problem with some of the imports not being valid. That probably had to do with why it wasn't writing out the import table properly. I had removed the "bad" imports, but it probably just broke the process. I think I was able to use LordPE on the same machine, but now I'm going to have to go back and check.
Which brings me to a general point about tools. If you've got tools you use that did into the guts of a system, then those tools are probably going to quit working when you move to a newer system. This is especially true of tools for which development has ceased (which seems to be the case with imprec.) If it's not being actively maintained, then it will eventually "expire" when the OS moves on. On my home machine, which is regular XP, imprec still works fine. Further, malware and packers tend to account for popular tools by implementing countermeasures. So, if you plan to keep up on reverse engineering, you should also plan to keep looking for the latest and greatest tools.
But in any case, my thanks to Jason for encouraging me to check out LordPE and for fixing my mistake. Back to the techie bits.
I'll skip the imprec demo for now. If you're interested in me spelling out the same steps for imprec, leave me a comment, and I'll write it up. In LordPE, you basically run the tool, find the process you still have paused at the OEP in your debugger, right-click it and select dump full:
In this particular case at least, you now have a good copy of the unpacked executable, and you can load it up in your favorite analysis tool:
If you're curious, the binary is a fairly typical call-home-to-an-IRC-C&C bot.
Notes:
- Sorry about the pictures, the arrangement isn't ideal. If you click on one, you can drill down a couple of levels and see the full size so you can read it. I'll probably try tweaking the pictures to work a bit better. Any Blogger and/or Zooomr advice is welcome.
- I realize I've got a weird mix of beginner and advanced topics here. Sorry about that. Again, this is at least partially to remind myself as well. If you liked the post and want me to take the tech level up or down, let me know. It probably won't be hard to talk me into writing about it more.
- Both Nicolas and Jason teach this topic as a training attached to security conferences. Nicolas teaches it at RECON. I don't know for sure yet if Nicolas will be teaching this year. Jason has taught at Black Hat, but it doesn't look like the Black Hat training schedule for this year has been announced yet either. I'll post an update if I find out anything about either of them teaching again.
Tuesday, January 09, 2007
Voicemail from bureau of prisons
I walked into the office this morning, and glanced at my phone. It said I had 7 new callers since I left yesterday. Now, I'm not much of a phone person. I hate them. I think that comes from a brief stint I did on the help desk phones at Bechtel.
So, most people know not to call me. I scrolled through the caller-ID list, and there were 6 calls from the same number within about a hour. The number didn't look familiar. Curious, I checked my voicemail, which is something else I rarely do. A man identified himself as being from the IT department of the bureau of prisons, said he had a question for me about a request from an inmate for a book that I wrote the foreword for, and would I please call him.
Uh, sure.
Turns out that someone had put in a request for How to Own a Continent. His opening question was "This isn't fiction, is it?". I explained that it IS fiction, in that none of the events happened, but that we try to keep the technical details real. So yes, it's half fiction, and half technical book. By the time I had called him, he had already taken note of the price and where it is supposed to be shelved, and decided on his own that it didn't qualify as a novel. He made it sound like he had a copy in front of him, which I guess he wasn't planning to forward to the inmate.
I feel a little bad for the inmate who probably won't get to see it now, but I wasn't going to lie about it. I didn't try to grill the prison IT guy, or argue with him about his policies. I figure that was probably pretty futile. Maybe I'll call him back at some point and see if there's anything he is allowed to tell me about which prison this is or the name of the inmate. I assume he can't, but you never know.
If the inmate in question ever sees this: When you get out, or if you transfer somewhere where they are a little more lenient about your reading material, I'll get you a copy.
So, most people know not to call me. I scrolled through the caller-ID list, and there were 6 calls from the same number within about a hour. The number didn't look familiar. Curious, I checked my voicemail, which is something else I rarely do. A man identified himself as being from the IT department of the bureau of prisons, said he had a question for me about a request from an inmate for a book that I wrote the foreword for, and would I please call him.
Uh, sure.
Turns out that someone had put in a request for How to Own a Continent. His opening question was "This isn't fiction, is it?". I explained that it IS fiction, in that none of the events happened, but that we try to keep the technical details real. So yes, it's half fiction, and half technical book. By the time I had called him, he had already taken note of the price and where it is supposed to be shelved, and decided on his own that it didn't qualify as a novel. He made it sound like he had a copy in front of him, which I guess he wasn't planning to forward to the inmate.
I feel a little bad for the inmate who probably won't get to see it now, but I wasn't going to lie about it. I didn't try to grill the prison IT guy, or argue with him about his policies. I figure that was probably pretty futile. Maybe I'll call him back at some point and see if there's anything he is allowed to tell me about which prison this is or the name of the inmate. I assume he can't, but you never know.
If the inmate in question ever sees this: When you get out, or if you transfer somewhere where they are a little more lenient about your reading material, I'll get you a copy.
Monday, January 08, 2007
Eight year old ActiveX control with vulnerability
Tan Chew Keong recently found an ActiveX control on his Acer laptop that allows for arbitrary file execution. I had read this a month or so go, but was reminded again by today's Slashdot story. I haven't looked into the technical details, but they seem pretty plain.
If this is in fact from 1998, then I am amazed by how long this thing has gone unnoticed.
I'd love to know how many copies of this thing are out in the world. I would hope not a lot for escaping notice for so many years.
I can't decide if this is evidence against many eyes, or evidence for the idea that less popular software doesn't get any attention.
If this is in fact from 1998, then I am amazed by how long this thing has gone unnoticed.
I'd love to know how many copies of this thing are out in the world. I would hope not a lot for escaping notice for so many years.
I can't decide if this is evidence against many eyes, or evidence for the idea that less popular software doesn't get any attention.
AACS Cracked?
It seems that AACS has been reported to be "cracked". Someone by the name of muslix64 claims to have created a program that:
What I find interesting is some of the reactions.
Freedom to Tinker:
Slashdot (comments):
Now, the Freedom to Tinker guys certainly know the score, and I hope I'm not making it look otherwise by quoting them out of context. But the general feeling from some portion of the people reading about this is that it isn't a proper crack; it doesn't come with keys. They can't use it.
They're missing the point, and what the guy is up to.
The people who complain that they can't use it without keys are also likely going to need a GUI app that rips HD DVDs to MPEG files with a single big green button. As near as I can tell without trying it myself, this program looks something like a GUI with a button. Just add keys.
So, where do you get keys? You get them from existing players, either hardware, firmware, or software. Who knows how to do that? Well, I could probably figure it out, if I had enough time. Please note that I'm not offering to find keys for you, I'm just saying that there are lots of us who do reverse engineering, who could probably figure it out.
So, the programmer attempts to keep the most controversial piece of his code modular and updatable. Other people can supply the keys. Maybe he even hopes that he can escape some trouble by not having it be fully functional out of the box. I wish him luck with that, though it's not without precedent. There are a number of MP3 rippers that don't directly include the patented MP3 codec, and they require you to go find a copy of the LAME libraries which do. The CD ripper programs say they don't include the codec, and the LAME project says you may need a license for your ripper. I tend to think that the MP3 patent holders have just decided to be nice about it.
A few points to make:
Is it in any way surprising that AACS is cracked/decodable/implemented in a program that doesn't play the MPAA's way? Not, not at all. It's inevitable. That's the basic problem with DRM. They give you a file that you're not supposed to be able to decode or decrypt. And then they hand you a decoder. Sure, they are hoping you won't look inside. But people are curious, and they like to be able to store their files on their own terms.
Is this a "crack" in the proper sense of the word? Well, when I was a kid, "cracking" meant removing copy protection from floppy disks. So in that sense, yes, this is a proper crack. It's working around the little trick that is supposed to keep you from doing things the easy way. Now, if you're talking about something like cracking the security of a program (finding a vulnerability) or "cracking" a crypto algorithm (better term is "break"), then no, this is not that kind of crack.
But that's not how you break DRM. You break DRM exactly like this guy did, by replicating the algorithm and/or keys. Sure, if there is ALSO a software vulnerability or bad crypto, that's interesting too. That happened with CSS, for example (crypto weakness.) but you don't need that to get around DRM. You just need to replicate the function of the player.
Frankly, when I simultaneous learned about this AACS crack and that there are a couple of existing Windows HD DVD players, it was obvious what happened. If you want to keep a secret, do not stick it in a Windows program. Reverse engineers LOVE to take apart Windows programs. If you're going to try and simultaneously keep a secret, and distribute it to every household in the world, then at least stick it in a secret ROM chip so that the likes of a Bunnie Huang are needed to get it out.
So why is this different than PGP? because you don't encrypt something with PGP, and then give a copy of the decryption key to everyone in the world, and ask them not to look. It wouldn't matter if every HD DVD came encrypted to your personal key either, since you have no incentive at all to keep the movie encrypted. What do you care if you give out the plaintext version of a movie?
So, what happens now? Well, the AACS designers aren't all that stupid, they were aware this would happen. So there is a key revocation feature out there. This is where my ignorance kicks in. I don't know exactly how this feature works, but I'm going to make some educated guesses.
There must be some set of keys in a Windows HD DVD player or physical device. I'm sure the AACS people issue a set to every vendor or manufacturer. The goal of the evil hax0r here is to swipe those keys, and probably give them to their buddies or post them on the Internet. So the AACS people figure out which keys have been leaked, and they revoke them. I'm guessing that on the next Disney DVD is a revocation list which the players will obey.
Now, does that mean if the evil hax0rs stole the keys from a Panasonic HD DVD player, that the AACS people have to disable that player? Is it all Panasonic devices, or just that model, or just North American versions of that model, or what? The exact details probably aren't important. I think what it means is that yes, some legitimate Panasonic owner buys a legitimate DVD, and next thing they know, their player is bricked.
Can they seriously be planning to do that? I can't see any plan where they can simultaneous cause the bad guys any significant trouble, and avoid screwing innocent customers.
And that's why DRM sucks.
is a tool to decrypt a AACS protected movie that you own, so you can play it back later using an HDDVD player software.He also says right up front that it's not complete as-is:
This software don't provide any cryptographic keys, so you have to add your own keys.There used to be a video on YouTube that showed it being used, I imagine. I haven't seen the video. The link to the YouTube now shows:
This video has been removed at the request of copyright owner Warner Bros. Entertainment Inc. because its content was used without permissionIf it's not clear, I haven't looked at this too hard. While it's interesting on some levels, I'm not interested in digging into the tech details just yet.
What I find interesting is some of the reactions.
Freedom to Tinker:
Typical users can’t extract title keys on their own, so BackupHDDVD won’t be useful to them as it currently stands — hence the claims that BackupHDDVD is a non-event.
Slashdot (comments):
the very clever fellow just implemented that publicly available decryption routine, and also discovered an (as of yet unreleased) method for obtaining decryption keys.and
Yes, and the Engadget article that is TFA is mistaken... He didn't supply any keys, just disc IDs (to map to human readable names of the discs). The place where the keys would have been were all stubbed out with all nulls.For the record, there was some confusion about whether the program shipped with any decryption keys or not. The Freedom to Tinker guys say no, I'll take their word for it.
If this is a crack for the DRM, then GPG is a crack for PGP.
Now, the Freedom to Tinker guys certainly know the score, and I hope I'm not making it look otherwise by quoting them out of context. But the general feeling from some portion of the people reading about this is that it isn't a proper crack; it doesn't come with keys. They can't use it.
They're missing the point, and what the guy is up to.
The people who complain that they can't use it without keys are also likely going to need a GUI app that rips HD DVDs to MPEG files with a single big green button. As near as I can tell without trying it myself, this program looks something like a GUI with a button. Just add keys.
So, where do you get keys? You get them from existing players, either hardware, firmware, or software. Who knows how to do that? Well, I could probably figure it out, if I had enough time. Please note that I'm not offering to find keys for you, I'm just saying that there are lots of us who do reverse engineering, who could probably figure it out.
So, the programmer attempts to keep the most controversial piece of his code modular and updatable. Other people can supply the keys. Maybe he even hopes that he can escape some trouble by not having it be fully functional out of the box. I wish him luck with that, though it's not without precedent. There are a number of MP3 rippers that don't directly include the patented MP3 codec, and they require you to go find a copy of the LAME libraries which do. The CD ripper programs say they don't include the codec, and the LAME project says you may need a license for your ripper. I tend to think that the MP3 patent holders have just decided to be nice about it.
A few points to make:
Is it in any way surprising that AACS is cracked/decodable/implemented in a program that doesn't play the MPAA's way? Not, not at all. It's inevitable. That's the basic problem with DRM. They give you a file that you're not supposed to be able to decode or decrypt. And then they hand you a decoder. Sure, they are hoping you won't look inside. But people are curious, and they like to be able to store their files on their own terms.
Is this a "crack" in the proper sense of the word? Well, when I was a kid, "cracking" meant removing copy protection from floppy disks. So in that sense, yes, this is a proper crack. It's working around the little trick that is supposed to keep you from doing things the easy way. Now, if you're talking about something like cracking the security of a program (finding a vulnerability) or "cracking" a crypto algorithm (better term is "break"), then no, this is not that kind of crack.
But that's not how you break DRM. You break DRM exactly like this guy did, by replicating the algorithm and/or keys. Sure, if there is ALSO a software vulnerability or bad crypto, that's interesting too. That happened with CSS, for example (crypto weakness.) but you don't need that to get around DRM. You just need to replicate the function of the player.
Frankly, when I simultaneous learned about this AACS crack and that there are a couple of existing Windows HD DVD players, it was obvious what happened. If you want to keep a secret, do not stick it in a Windows program. Reverse engineers LOVE to take apart Windows programs. If you're going to try and simultaneously keep a secret, and distribute it to every household in the world, then at least stick it in a secret ROM chip so that the likes of a Bunnie Huang are needed to get it out.
So why is this different than PGP? because you don't encrypt something with PGP, and then give a copy of the decryption key to everyone in the world, and ask them not to look. It wouldn't matter if every HD DVD came encrypted to your personal key either, since you have no incentive at all to keep the movie encrypted. What do you care if you give out the plaintext version of a movie?
So, what happens now? Well, the AACS designers aren't all that stupid, they were aware this would happen. So there is a key revocation feature out there. This is where my ignorance kicks in. I don't know exactly how this feature works, but I'm going to make some educated guesses.
There must be some set of keys in a Windows HD DVD player or physical device. I'm sure the AACS people issue a set to every vendor or manufacturer. The goal of the evil hax0r here is to swipe those keys, and probably give them to their buddies or post them on the Internet. So the AACS people figure out which keys have been leaked, and they revoke them. I'm guessing that on the next Disney DVD is a revocation list which the players will obey.
Now, does that mean if the evil hax0rs stole the keys from a Panasonic HD DVD player, that the AACS people have to disable that player? Is it all Panasonic devices, or just that model, or just North American versions of that model, or what? The exact details probably aren't important. I think what it means is that yes, some legitimate Panasonic owner buys a legitimate DVD, and next thing they know, their player is bricked.
Can they seriously be planning to do that? I can't see any plan where they can simultaneous cause the bad guys any significant trouble, and avoid screwing innocent customers.
And that's why DRM sucks.
Wednesday, January 03, 2007
Vulnerability Pimps
Marcus Ranum has written a very interesting article about code review, secure coding, Fortify, and vulnerability pimps. The meat of his article is about code review, and there are some real lessons to be learned there. You should take his comments to heart, and implement the review processes he recommends. I know I'm going to look into Fortify now.
There are also some interesting minor insights into Marcus' history. Love him or hate him, you should always pay attention to what Marcus has to say. He graciously added an RSS feed to his site at my request, so please use it.
That said, what I can't let go is "vulnerability pimps". I know, story of his life. He tries to tell people things, and they can only pay attention to his politics. Sorry about that, Marcus.
So, yeah, vulnerability pimps. That's awesome. I'm sure he means for it to be pejorative, but for the folks he is describing, I can't see them taking too much offense. I can see the rise of the purple hat hackers even now.
It's the first time I've heard the term, though maybe he didn't coin it. Google says that Rodney Thayer (at least) used it in 2005. I see Marcus using it in February. Of course, Google doesn't know everything, so I'm happy to take corrections. I can't help but think of this as a Ranumism, though.
As for my politics, I could be accused of encouraging, facilitation, and participating in vulnerability research. Though, not with as much skill as most other vulnerability pimps.
I'll keep my counterpoint brief. Marcus throws out the "many eyes" catchphrase, specifically calling it a failure in the face of his findings. If one does not like independent vulnerability research taking place, then where do you think the checks that Fortify performs come from? If the developers and companies aren't going to look, who else will? If you expect the few eyes to be able to see, where are those eyes going to train?
To be fair to Marcus, he just did the same thing himself. In fact, if I wanted to be extremely ungenerous, I could put him in the same category as the kid who just got a new fuzzer and went looking for problems. But he doesn't deserve that.
The difference for him, as he points out, is that he thinks there's no benefit to touting his findings, (presumably) not even after the patch is out. He reports that everyone was cool, and they are going to get the fix out Real Soon Now. So he can get the problem fixed without the fanfare.
I invite Marcus to finish the experiment, and give us a update later about the following:
There are also some interesting minor insights into Marcus' history. Love him or hate him, you should always pay attention to what Marcus has to say. He graciously added an RSS feed to his site at my request, so please use it.
That said, what I can't let go is "vulnerability pimps". I know, story of his life. He tries to tell people things, and they can only pay attention to his politics. Sorry about that, Marcus.
So, yeah, vulnerability pimps. That's awesome. I'm sure he means for it to be pejorative, but for the folks he is describing, I can't see them taking too much offense. I can see the rise of the purple hat hackers even now.
It's the first time I've heard the term, though maybe he didn't coin it. Google says that Rodney Thayer (at least) used it in 2005. I see Marcus using it in February. Of course, Google doesn't know everything, so I'm happy to take corrections. I can't help but think of this as a Ranumism, though.
As for my politics, I could be accused of encouraging, facilitation, and participating in vulnerability research. Though, not with as much skill as most other vulnerability pimps.
I'll keep my counterpoint brief. Marcus throws out the "many eyes" catchphrase, specifically calling it a failure in the face of his findings. If one does not like independent vulnerability research taking place, then where do you think the checks that Fortify performs come from? If the developers and companies aren't going to look, who else will? If you expect the few eyes to be able to see, where are those eyes going to train?
To be fair to Marcus, he just did the same thing himself. In fact, if I wanted to be extremely ungenerous, I could put him in the same category as the kid who just got a new fuzzer and went looking for problems. But he doesn't deserve that.
The difference for him, as he points out, is that he thinks there's no benefit to touting his findings, (presumably) not even after the patch is out. He reports that everyone was cool, and they are going to get the fix out Real Soon Now. So he can get the problem fixed without the fanfare.
I invite Marcus to finish the experiment, and give us a update later about the following:
- Let us know if you will be taking credit for the finds.
- Explain how pimping Fortify by searching for vulns in other people's software is different than eEye doing it to pimp Blink.
- Tell us how long it takes the programmers to release the patch
- Tell us whether the programmers properly acknowledge that this update fixes a security problem, and that people should update right away
- Tell us if you spend the extra time to check that the patch correctly fixes the problem you identified
Full RSS Feed