That's really harsh, using AOL's own search engine to prove how ludicrously overpriced their "service" is. I mean, come on... you could at least save them a little face and use MSN Search or something.
This CNN story claims that a US official suggests that the mushroom cloud might be caused by a forest fire. A little bit of physics knowledge [layman/common-sense] makes this suggestion laughable: a mushroom cloud is caused by a large amount of superheated gasses, concentrated and hot enough to rise miles into the atmosphere before dissipating enough to break the cap. Unless they have had a multi-year drought and a forest dense enough to flash to many thousand degrees C in a very short period of time, there's no possible way the mushroom cloud was created that way.
Now, it's entirely possible that it is not a mushroom cloud, as it sounds like all the indications of its presence so far are satellite shots. AFAIK very few, if any, satellites can shoot pictures at a sufficiently low angle to actually get enough outline to confirm a mushroom cloud. Basic physics again: too low and angle, you get a massively distored image because there's a) more air in the way, and b) angle of incidence causes wild refraction.
If anyone can elaborate on (or correct) these two issues, please comment. I'd be glad to be proven wrong in some way, as a verified nuclear N.Korea is not a good thing. However, what we know so far is not promising.
> The firmware that runs on the card itself is still a closed source binary.
Talk about failure to pick your battles. A bit of real-world info: every single WiFi card on the planet has closed-source firmware. No exceptions. The difference is that the Intel 2x00 cards save money on manufacturing (and thus make the cards cheaper for YOU) by not storing the firmware on an extra flash chip on the board itself.
Take a look at the board of MOST WiFi cards. You will see either 3 or 4 chips (though some new non-PC-compatible "chipsets" manage to totally integrate this into a single chip). Chip #1 is the baseband (MAC). Chip #2 (if not integrated into the MAC, which is a very recent thing) is the radio section (upconverter/downconverter). Chip #3 is the SRAM needed to store in-flight packets. Chip #4 is the flash chip containing the closed-source firmware. The Intel 2x00 cards save money by letting the host processor and infrastructure do what they're really good at: storing and moving data. Instead of loading firmware out of flash, the card waits for the host to load the firmware as the driver boots up.
No as for the desirability of open-source firmware... If you plan on telling me that you intend to take this open-source firmware and modify it so your card can do different things with its radio, pay me no mind while I laugh in your face.
I'm developing firmware for a hardware product right now, and can tell you that there is not the slightest chance that anyone outside the designers of the hardware can make firmware do anything other than what it was designed to do.
First of all you have the hardware itself, which even the software will be useless for as far as getting the slightest clue what's really going on. Second, firmware for such devices, *especially* high-speed devices like WiFi cards, is more timing-critical than you can even begin to imagine. The slightest change will make it cease to work in ways even the original author most likely will not understand (speaking from daily experience here).
Sorry, but if you want open-source firmware, you're going to have to design your own chip.
(Not-Disclaimer: I have no relationship with Intel, their product, or this driver project, except that I plan on buying a 2x00 at some point to replace the driverless/worthless BCM4306 card that came with my laptop)
I've been watching now for several years as many core GNOME developers stuck air compressors up their noses, resulting in ridiculously overinflated egos. And I've been forced to conclude that the "usability" group is the source of almost all these problems.
What has happened is that those who consider themselves usability "experts", but are demonstably *not*, are deciding that something (e.g. spatial nautilus) is cool BECAUSE IT'S DIFFERENT, and constructing a huge set of supporting claims, anecdotes, and broken analogies to support their assertion that it's the Correct(TM) way to do things.
Then again this is not the real problem. The real problem is that these same developers are so astoundingly arrogant that they have decided that they know better than some 30 years of interface evolution (not "design"). Instead of actually asking users how they prefer to work, they are instead removing one by one every normal interoperative paradigm that people have been using on their PC's for a decade, because it's "wrong".
This utterly insufferable arrogance is very visibly driving users away from GNOME. I've been a dedicated GNOME user (and developer!) since well before 1.0 days, and this kind of behavior is making me seriously consider switching to something else. This story itself is evidence, as while the comments seem roughtly balanced between the "love it" and "hate it" camps, I haven't seen a single message that says "love it, switched to it". Instead, I see many messages that say "hate it, ditched it".
If this pattern continues, I predict that a full GNOME fork will appear within a year. I personally would be happy to assist in reclaiming quite a few features that have been unilaterally decided as "wrong", if I had any time to do so.
Actually, it's my personal server, a User-mode Linux machine at PDXcolo.net, the company I co-own. The machine didn't breathe hard at all, didn't even notice the loads in the slightest.
Re:Much better picture...
on
Robosaurus
·
· Score: 1
It was a rather hot and sunny day, yeah. I specifically remember not being quite hydrated enough by the end of the evening.
Much better picture...
on
Robosaurus
·
· Score: 4, Informative
Because a 400-disc changer loaded with 400 full DVD-R's is almost 1.9 TB. That's $2000 just of drives, not including the machine to put them in. There just isn't much comparison, assuming your requirements are weighted towards huge storage capacity and not high-speed/low-latency access.
If consumer CD/DVD changers for audio/video can be made at $1/slot, there is absolutely no technical reason the read couldn't be replaced with an ATAPI drive. Someone could make a killing selling such a product.
I'm not all that old (25 tomorrow) and I clearly remember the uproar when several major hard drive manufacturers (lessee, WD, Maxtor, Connor [yes Connor]) changed from using 1k=1024 to 1k=1000. I don't remember when it was, but I could probably pull out an old PC Magazine from the era and demonstrate. The claim they've always used 1k=1000 is blatantly false, sorry.
Indeed, I'm co-owner of PDXcolo.net, using User-Mode Linux to do virtual hosting where you actually get root on the box. One of our customers has purchased the largest such system we offer, and proceeded to use it to run a chatnet.org site. Within days we were hit by 50+Mbps DDoS attacks, which actually took out our upstream provider's router at one point. He's still a customer, and we still have problems every once in a while, but we've been told by our upstream ISP that if something like this happens again, *we* are responsible for it. That's going to mean we get either disconnected (BAD) or fined (we can handle that), but it definitely means we won't be allowing that customer to run an IRC server anymore.
That said, other comments to the effect that if it isn't IRC it will be something else are entirely true. I've heard of DNS providers being DDoS'd out of existence because some pathetic 9 year old script kiddie decided to DDoS the *domain* of a site he doesn't like.
Personally, I wish backbone providers had a little more, um, backbone, when it comes to tracking bandwidth spikes through the net to actually catch the attackers. But no, they get paid for the bandwidth whether it's legitimate or not, so they couldn't care less.
In selected cases, yes. Answering the loan spams would cause all the loan vendors to start looking a lot more closely at the lead rates they get, and probably start investigating why the rates suck for certain suppliers. That assumes of course that a given lead company is predominantly spam-generated or not.
The difference is that these devices have a button on the box that lets you set up ad-hoc networks simply by setting the same channel on all the bridges. I assume there's a more complete configuration setup a la the WET-11 for infrastructure-based networks.
Besides, I have two of them. And no, they can't have them back.;-) They're the backbone of our startup company, PDXcolo.net. Sting and Narsil they're called.
A friend of mine and I are starting up a company called PDXcolo.net. We're using User-mode Linux to host virtual machines, where you get your own copy of the distro, your own RAM, etc., on a shared machine. You get full root access to the machine, and can (within reason) do anything you want with it. Our base packge (for $20/mo) includes ~64MHz of proc, 64MB of RAM, 2GB of disk (your distro is *not* part of that unless you make significant changes), and 10GB of transfer per month. Additional disk is only $1/GB/mo, and bandwidth is $1.50/GB. 'Machines' are available in power-of-two multiples of that basic config, so far up to 8 'slots', or 512/512/16/80. More can be arranged special-case.
If you're interested, email beta@pdxcolo.net and we'll get you set up soon (merchant account troubles are our main slowdown right now) on our initial machine. That box has 2x 200GB disks in a RAID-1 config. We're planning on doing something on the order of a 3x RAID-5 arrangement on all new hardware, and/or a significant SAN setup.
Our machines are located in a well-respected datacenter in downtown Portland (hence 'pdx', our airport code), and as we build up our infrastructure daily backups will be available over and above the RAID on the hosts. We've got one circuit so far that we've pushed to 25Mbps, an d will be adding more circuits as we get our first customers.
So, if what you're doing doesn't require mega processor or RAM usage, but lots of disk, you might consider using one of our virtual machines to host your app.
We're starting up a company called pdxcolo.net, which will provide
true virtual machine hosting in the form of User-mode Linux. We're
currently building up our infrastructure, and are currently seeking beta
testers.
For $20/mo (post-beta), you'll get:
Roughly 64MHz worth of an Athlon XP (peaking to a full 2x00+ proc if
no one else is using it that instant)
64MB of RAM
2GB of disk space (OS is not counted against that)
10GB of transfer per month
Install anything you want, you have true root on the box
Choice of Debain stable, testing, or unstable, soon RedHat 9.0,
Gentoo and others
Beta testers (of which there will be a limited number) will get the
first two months of service at half price, or in effect the initial
1-month beta period for free. If you're interested, email beta@pdxcolo.net and we'll take the
first N (probably 30) people.
If you don't get in on the beta, we'll send you email when we go live
and give you first crack at new hardware as we install it. You'll get
your machine fully activated and ready for you to log into and configure
usually within 30 seconds, and you can install whatever you need to from
our local distribution mirrors.
So dare I ask what the other 55% is? Here's my guess:
1% Instant messaging
1% Real email
3% SPAM
5% Web browsing
45% Windows vunlerability probes and active attacks
No, don't check. You don't want to know.
Re:binary-only is not enough
on
Open Source DRM
·
· Score: 1
Oh, of course. Binary-only just makes it harder. And once you hit the sound card, all bets are off anyway. Hence HDCP for DVI encryption. The assumption they keep making is that they can build something that's unbreakable, which is of course impossible in the face of someone willing to spend enough time and money to break it.
And of course the TCPA and friends would only create a thriving underground, where people would have to be at least a little smarter than the X-box modchip makers and actually attempt to conceal themselves.
Open Source and DRM are fundamentally incompatible
on
Open Source DRM
·
· Score: 5, Insightful
I worked for a startup that was researching DRM heavily (I was doing streaming-media stuff, others were doing DRM, and the company rightly failed promptly), and have done a lot of thinking about the issues.
Basically, OSS and DRM are mathematically incompatible. The purpose of DRM is to keep the user from being able to make a copy of the media in question. In order to do that, it must use encryption keys to hide the 'plaintext', and carefully control those keys. This is the core of what DRM is.
In order to plug the equivalent of the 'analog hole', all existing DRM implementations are binary-only, and carefully control and conceal the data path between the encrypted data and the finaly output hardware, so that it's 'impossible' for the user to get the plaintext.
As soon as you go Open Source, *anyone* can take the code appart, take the decryption routine, and get the plaintext right out of that. There is nothing 'forcing' the data directly into the hardware. At that point, the plaintext can be distributed, and the DRM has failed.
More important than that even is the fact that open-source licenses guarantee that you can redistribute your modifications. It will be a grand total of about 2.37 hours between initial release of the software and someone releasing a version that will export the plaintext. Guess how popular the original release will be?
No, I think the results of this little experiment will be mixed good and bad:
Good: it will prove that DRM is mathematically impossible
Bad: it will 'prove' that the industry *must* use binary-only distributions of such software in order to make it work
It remains to be seen which of these will take effect first.
Doing any of this without hardware compression is, of course, not even remotely viable. Given that, you have some serious limitations imposed by common hardware.
Many of the PVR cards use the KFIR encoder chip in conjunction with a Conexant bt8x8 video capture chip. The bt8x8 does the NTSC->PCM, and sends it to the KFIR encoder, which sends the MPEG data back to the bt8x8. The limitation comes from the fact that there is no hardware-assisted DMA for the data coming from the KFIR chip. That means the host process has to repeatedly poll the PCI memory address for the bt8x8 GPIO ports in order to capture the data.
Putting more than one or may be two of these cards in a single machine would swamp the machine so badly it wouldn't be able to do much else at all, let alone sending the video to disk or a network-attached storage device.
If you can find a PVR card (supported under Linux, good luck putting multiple *anything* in a Windows box) that doesn't blow the PCI bus to pieces when capturing, and you should be able to put quite a large number in a single machine, limited by PCI slots. The KFIR chip captures up to 12Mbps, which is 1.5MB/sec. PCI can peak at 132MB/sec, so as long as busmastering overhead across a dozen cards isn't fatal, you could put them all in a PCI expansion cage on a single machine.
With all the foaming at the mouth about how this is probably a hoax, etc., etc., no one seems to have bothered to check into the presented exploit. I did, last night. I found that mpg123 is indeed vulnerable to this attack, and I'll explain how:
mpg123's stream-handling mechanisms appear to rely on readahead to the next frame in order to verify the correctness of a file. Specifically, in initial checks to see if the given file is a mp3 or a WAV, it will calculate the size of the first frame, and confirm that the next bytes after that contain another valid mp3 frame header.
The frame header is a 32-bit value starting with 13 1-bits, then other pieces of information about the format, such as layer, bitrate, sampling rate, etc. This is the key to the exploit: they create a frame header that indicates "MPEG 2.5" (low-sampling-rate enhancements), layer 2, 160Kbps, 8KHz. The code at common.c:560 determines that the frame size thus should be 2877 bytes.
The problem comes when you look at common.c:158, which creates a static, fixed-length buffer on the function's stack (bad Bad BAD!). It turns out to be 1920 bytes long (MAX_INPUT_FRAMESIZE). At common.c:240, a call is made to rds->read_frame_body, which is found in this case at readers.c:282. It loops through the buffer up to the given size (which is 2877!!) reading in from the orignal stream into the given buffer. There's a little problem with that, though: the buffer is only 1920 bytes long.
The result of this is that the stack is smashed, all the way up to the top of the function's stack and beyond, into the arguments given to the function, which includes rds. The very next operation, at common.c:243, is to once again dereference rds and call head_read(). Except now the rds pointer is overwritten, and it can call any code it wants. Game over.
To verify this, simply run mpg123 in gdb:
[omega@omicron sploit]$ gdb mpg123/mpg123 . .. (gdb) br common.c:240 Breakpoint 1 at 0x804c2b0: file common.c, line 240. (gdb) r sploit.mp3 Starting program:/tmp/sploit/mpg123/mpg123 sploit.mp3 High Performance MPEG 1.0/2.0/2.5 Audio Player for Layer 1, 2 and 3. . .. Breakpoint 1, sync_stream (rds=0x806d780, fr=0x806dbe0, flags=65535,
skipped=0xbfff9cf4) at common.c:240 240 if(!rds->read_frame_body(rds,dummybuf,frameInfo.fr amesize)) (gdb) p rds $1 = (struct reader *) 0x806d780 (gdb) c Continuing.
Program received signal SIGSEGV, Segmentation fault. 0x0804c2ed in sync_stream (rds=0x41424704, fr=0x41424704, flags=1094862596,
skipped=0x41424704) at common.c:243 243 if(!rds->head_read(rds,&nexthead)) (gdb) p rds $2 = (struct reader *) 0x41424704 (gdb)
Slashdot Mirror
That's really harsh, using AOL's own search engine to prove how ludicrously overpriced their "service" is. I mean, come on... you could at least save them a little face and use MSN Search or something.
Done, not holding my breath.
This CNN story claims that a US official suggests that the mushroom cloud might be caused by a forest fire. A little bit of physics knowledge [layman/common-sense] makes this suggestion laughable: a mushroom cloud is caused by a large amount of superheated gasses, concentrated and hot enough to rise miles into the atmosphere before dissipating enough to break the cap. Unless they have had a multi-year drought and a forest dense enough to flash to many thousand degrees C in a very short period of time, there's no possible way the mushroom cloud was created that way.
Now, it's entirely possible that it is not a mushroom cloud, as it sounds like all the indications of its presence so far are satellite shots. AFAIK very few, if any, satellites can shoot pictures at a sufficiently low angle to actually get enough outline to confirm a mushroom cloud. Basic physics again: too low and angle, you get a massively distored image because there's a) more air in the way, and b) angle of incidence causes wild refraction.
If anyone can elaborate on (or correct) these two issues, please comment. I'd be glad to be proven wrong in some way, as a verified nuclear N.Korea is not a good thing. However, what we know so far is not promising.
Only 6gig of memory? Is it me or that that seem a stupidly low amount when dealing with a amachine of this power?
That's 6GB for each of the 504 (not 512??) nodes, or 3GB per processor, almost 3TB total. Trust me, that's plenty for all but the most extreme uses.
> The firmware that runs on the card itself is still a closed source binary.
Talk about failure to pick your battles. A bit of real-world info: every single WiFi card on the planet has closed-source firmware. No exceptions. The difference is that the Intel 2x00 cards save money on manufacturing (and thus make the cards cheaper for YOU) by not storing the firmware on an extra flash chip on the board itself.
Take a look at the board of MOST WiFi cards. You will see either 3 or 4 chips (though some new non-PC-compatible "chipsets" manage to totally integrate this into a single chip). Chip #1 is the baseband (MAC). Chip #2 (if not integrated into the MAC, which is a very recent thing) is the radio section (upconverter/downconverter). Chip #3 is the SRAM needed to store in-flight packets. Chip #4 is the flash chip containing the closed-source firmware. The Intel 2x00 cards save money by letting the host processor and infrastructure do what they're really good at: storing and moving data. Instead of loading firmware out of flash, the card waits for the host to load the firmware as the driver boots up.
No as for the desirability of open-source firmware... If you plan on telling me that you intend to take this open-source firmware and modify it so your card can do different things with its radio, pay me no mind while I laugh in your face.
I'm developing firmware for a hardware product right now, and can tell you that there is not the slightest chance that anyone outside the designers of the hardware can make firmware do anything other than what it was designed to do.
First of all you have the hardware itself, which even the software will be useless for as far as getting the slightest clue what's really going on. Second, firmware for such devices, *especially* high-speed devices like WiFi cards, is more timing-critical than you can even begin to imagine. The slightest change will make it cease to work in ways even the original author most likely will not understand (speaking from daily experience here).
Sorry, but if you want open-source firmware, you're going to have to design your own chip.
(Not-Disclaimer: I have no relationship with Intel, their product, or this driver project, except that I plan on buying a 2x00 at some point to replace the driverless/worthless BCM4306 card that came with my laptop)
I've been watching now for several years as many core GNOME developers stuck air compressors up their noses, resulting in ridiculously overinflated egos. And I've been forced to conclude that the "usability" group is the source of almost all these problems.
What has happened is that those who consider themselves usability "experts", but are demonstably *not*, are deciding that something (e.g. spatial nautilus) is cool BECAUSE IT'S DIFFERENT, and constructing a huge set of supporting claims, anecdotes, and broken analogies to support their assertion that it's the Correct(TM) way to do things.
Then again this is not the real problem. The real problem is that these same developers are so astoundingly arrogant that they have decided that they know better than some 30 years of interface evolution (not "design"). Instead of actually asking users how they prefer to work, they are instead removing one by one every normal interoperative paradigm that people have been using on their PC's for a decade, because it's "wrong".
This utterly insufferable arrogance is very visibly driving users away from GNOME. I've been a dedicated GNOME user (and developer!) since well before 1.0 days, and this kind of behavior is making me seriously consider switching to something else. This story itself is evidence, as while the comments seem roughtly balanced between the "love it" and "hate it" camps, I haven't seen a single message that says "love it, switched to it". Instead, I see many messages that say "hate it, ditched it".
If this pattern continues, I predict that a full GNOME fork will appear within a year. I personally would be happy to assist in reclaiming quite a few features that have been unilaterally decided as "wrong", if I had any time to do so.
Actually, it's my personal server, a User-mode Linux machine at PDXcolo.net, the company I co-own. The machine didn't breathe hard at all, didn't even notice the loads in the slightest.
It was a rather hot and sunny day, yeah. I specifically remember not being quite hydrated enough by the end of the evening.
Much better picture from the Portland International Airshow, 1999
From August 25th, 2003
Because a 400-disc changer loaded with 400 full DVD-R's is almost 1.9 TB. That's $2000 just of drives, not including the machine to put them in. There just isn't much comparison, assuming your requirements are weighted towards huge storage capacity and not high-speed/low-latency access.
If consumer CD/DVD changers for audio/video can be made at $1/slot, there is absolutely no technical reason the read couldn't be replaced with an ATAPI drive. Someone could make a killing selling such a product.
I'm not all that old (25 tomorrow) and I clearly remember the uproar when several major hard drive manufacturers (lessee, WD, Maxtor, Connor [yes Connor]) changed from using 1k=1024 to 1k=1000. I don't remember when it was, but I could probably pull out an old PC Magazine from the era and demonstrate. The claim they've always used 1k=1000 is blatantly false, sorry.
Indeed, I'm co-owner of PDXcolo.net, using User-Mode Linux to do virtual hosting where you actually get root on the box. One of our customers has purchased the largest such system we offer, and proceeded to use it to run a chatnet.org site. Within days we were hit by 50+Mbps DDoS attacks, which actually took out our upstream provider's router at one point. He's still a customer, and we still have problems every once in a while, but we've been told by our upstream ISP that if something like this happens again, *we* are responsible for it. That's going to mean we get either disconnected (BAD) or fined (we can handle that), but it definitely means we won't be allowing that customer to run an IRC server anymore.
That said, other comments to the effect that if it isn't IRC it will be something else are entirely true. I've heard of DNS providers being DDoS'd out of existence because some pathetic 9 year old script kiddie decided to DDoS the *domain* of a site he doesn't like.
Personally, I wish backbone providers had a little more, um, backbone, when it comes to tracking bandwidth spikes through the net to actually catch the attackers. But no, they get paid for the bandwidth whether it's legitimate or not, so they couldn't care less.
In selected cases, yes. Answering the loan spams would cause all the loan vendors to start looking a lot more closely at the lead rates they get, and probably start investigating why the rates suck for certain suppliers. That assumes of course that a given lead company is predominantly spam-generated or not.
The difference is that these devices have a button on the box that lets you set up ad-hoc networks simply by setting the same channel on all the bridges. I assume there's a more complete configuration setup a la the WET-11 for infrastructure-based networks.
Besides, I have two of them. And no, they can't have them back. ;-) They're the backbone of our startup company, PDXcolo.net. Sting and Narsil they're called.
A friend of mine and I are starting up a company called PDXcolo.net. We're using User-mode Linux to host virtual machines, where you get your own copy of the distro, your own RAM, etc., on a shared machine. You get full root access to the machine, and can (within reason) do anything you want with it. Our base packge (for $20/mo) includes ~64MHz of proc, 64MB of RAM, 2GB of disk (your distro is *not* part of that unless you make significant changes), and 10GB of transfer per month. Additional disk is only $1/GB/mo, and bandwidth is $1.50/GB. 'Machines' are available in power-of-two multiples of that basic config, so far up to 8 'slots', or 512/512/16/80. More can be arranged special-case.
If you're interested, email beta@pdxcolo.net and we'll get you set up soon (merchant account troubles are our main slowdown right now) on our initial machine. That box has 2x 200GB disks in a RAID-1 config. We're planning on doing something on the order of a 3x RAID-5 arrangement on all new hardware, and/or a significant SAN setup.
Our machines are located in a well-respected datacenter in downtown Portland (hence 'pdx', our airport code), and as we build up our infrastructure daily backups will be available over and above the RAID on the hosts. We've got one circuit so far that we've pushed to 25Mbps, an d will be adding more circuits as we get our first customers.
So, if what you're doing doesn't require mega processor or RAM usage, but lots of disk, you might consider using one of our virtual machines to host your app.
Wow, that'll affect all of SCO's 3 customers...?
We're starting up a company called pdxcolo.net, which will provide true virtual machine hosting in the form of User-mode Linux. We're currently building up our infrastructure, and are currently seeking beta testers.
For $20/mo (post-beta), you'll get:
Beta testers (of which there will be a limited number) will get the first two months of service at half price, or in effect the initial 1-month beta period for free. If you're interested, email beta@pdxcolo.net and we'll take the first N (probably 30) people.
If you don't get in on the beta, we'll send you email when we go live and give you first crack at new hardware as we install it. You'll get your machine fully activated and ready for you to log into and configure usually within 30 seconds, and you can install whatever you need to from our local distribution mirrors.
So dare I ask what the other 55% is? Here's my guess:
No, don't check. You don't want to know.
Oh, of course. Binary-only just makes it harder. And once you hit the sound card, all bets are off anyway. Hence HDCP for DVI encryption. The assumption they keep making is that they can build something that's unbreakable, which is of course impossible in the face of someone willing to spend enough time and money to break it.
And of course the TCPA and friends would only create a thriving underground, where people would have to be at least a little smarter than the X-box modchip makers and actually attempt to conceal themselves.
I worked for a startup that was researching DRM heavily (I was doing streaming-media stuff, others were doing DRM, and the company rightly failed promptly), and have done a lot of thinking about the issues.
Basically, OSS and DRM are mathematically incompatible. The purpose of DRM is to keep the user from being able to make a copy of the media in question. In order to do that, it must use encryption keys to hide the 'plaintext', and carefully control those keys. This is the core of what DRM is.
In order to plug the equivalent of the 'analog hole', all existing DRM implementations are binary-only, and carefully control and conceal the data path between the encrypted data and the finaly output hardware, so that it's 'impossible' for the user to get the plaintext.
As soon as you go Open Source, *anyone* can take the code appart, take the decryption routine, and get the plaintext right out of that. There is nothing 'forcing' the data directly into the hardware. At that point, the plaintext can be distributed, and the DRM has failed.
More important than that even is the fact that open-source licenses guarantee that you can redistribute your modifications. It will be a grand total of about 2.37 hours between initial release of the software and someone releasing a version that will export the plaintext. Guess how popular the original release will be?
No, I think the results of this little experiment will be mixed good and bad:
Good: it will prove that DRM is mathematically impossible
Bad: it will 'prove' that the industry *must* use binary-only distributions of such software in order to make it work
It remains to be seen which of these will take effect first.
NoCatAuth
Doing any of this without hardware compression is, of course, not even remotely viable. Given that, you have some serious limitations imposed by common hardware.
Many of the PVR cards use the KFIR encoder chip in conjunction with a Conexant bt8x8 video capture chip. The bt8x8 does the NTSC->PCM, and sends it to the KFIR encoder, which sends the MPEG data back to the bt8x8. The limitation comes from the fact that there is no hardware-assisted DMA for the data coming from the KFIR chip. That means the host process has to repeatedly poll the PCI memory address for the bt8x8 GPIO ports in order to capture the data.
Putting more than one or may be two of these cards in a single machine would swamp the machine so badly it wouldn't be able to do much else at all, let alone sending the video to disk or a network-attached storage device.
If you can find a PVR card (supported under Linux, good luck putting multiple *anything* in a Windows box) that doesn't blow the PCI bus to pieces when capturing, and you should be able to put quite a large number in a single machine, limited by PCI slots. The KFIR chip captures up to 12Mbps, which is 1.5MB/sec. PCI can peak at 132MB/sec, so as long as busmastering overhead across a dozen cards isn't fatal, you could put them all in a PCI expansion cage on a single machine.
With all the foaming at the mouth about how this is probably a hoax, etc., etc., no one seems to have bothered to check into the presented
. /tmp/sploit/mpg123/mpg123 sploit.mp3 .r amesize))
exploit. I did, last night. I found that mpg123 is indeed vulnerable to this attack, and I'll explain how:
mpg123's stream-handling mechanisms appear to rely on readahead to the next frame in order to verify the correctness of a file. Specifically,
in initial checks to see if the given file is a mp3 or a WAV, it will calculate the size of the first frame, and confirm that the next bytes
after that contain another valid mp3 frame header.
The frame header is a 32-bit value starting with 13 1-bits, then other pieces of information about the format, such as layer, bitrate,
sampling rate, etc. This is the key to the exploit: they create a frame header that indicates "MPEG 2.5" (low-sampling-rate enhancements),
layer 2, 160Kbps, 8KHz. The code at common.c:560 determines that the frame size thus should be 2877 bytes.
The problem comes when you look at common.c:158, which creates a static, fixed-length buffer on the function's stack (bad Bad BAD!). It turns
out to be 1920 bytes long (MAX_INPUT_FRAMESIZE). At common.c:240, a call is made to rds->read_frame_body, which is found in this case at
readers.c:282. It loops through the buffer up to the given size (which is 2877!!) reading in from the orignal stream into the given buffer.
There's a little problem with that, though: the buffer is only 1920 bytes long.
The result of this is that the stack is smashed, all the way up to the top of the function's stack and beyond, into the arguments given to the
function, which includes rds. The very next operation, at common.c:243, is to once again dereference rds and call head_read(). Except now
the rds pointer is overwritten, and it can call any code it wants. Game over.
To verify this, simply run mpg123 in gdb:
[omega@omicron sploit]$ gdb mpg123/mpg123
. .
(gdb) br common.c:240
Breakpoint 1 at 0x804c2b0: file common.c, line 240.
(gdb) r sploit.mp3
Starting program:
High Performance MPEG 1.0/2.0/2.5 Audio Player for Layer 1, 2 and 3.
. .
Breakpoint 1, sync_stream (rds=0x806d780, fr=0x806dbe0, flags=65535,
skipped=0xbfff9cf4) at common.c:240
240 if(!rds->read_frame_body(rds,dummybuf,frameInfo.f
(gdb) p rds
$1 = (struct reader *) 0x806d780
(gdb) c
Continuing.
Program received signal SIGSEGV, Segmentation fault.
0x0804c2ed in sync_stream (rds=0x41424704, fr=0x41424704, flags=1094862596,
skipped=0x41424704) at common.c:243
243 if(!rds->head_read(rds,&nexthead))
(gdb) p rds
$2 = (struct reader *) 0x41424704
(gdb)