There is no conspiracy, if you want to buy a DVD player that supports CDs, YOU READ THE BOX FIRST. It wasn't a bean counter's decision. It's a question of whether or not the design specs required support for CDR or not. This one didn't, so they didn't put the extra laser in it to read the CDR.
Very few DVD players support CDRs. Sony didn't remove a feature that wasn't even there in the first place.
That's why the Apex was so compelling (besides, of course, the region code and macrovision hack). The Apex was a good, cheap DVD player that could play CDRs. Apex had to put support for both the DVD laser and the CDr laser (probably because supporting MP3 without supporting CDR would have seriously limited its market appeal)
Hasn't anyone seen "The Spanish Prisoner"
on
What is 'IT'?
·
· Score: 1
The Spanish Prisoner was a David Mamet film staring Campbell Scott and Steve Martin. The premise was that a scientist invents a unnamed formulat that will control the world's economy for the next 3 years.
It's all top secret, nobody gets to see it. and the viewer never finds out what it is or what it does. I don't want to give away the movie
But I think that Jobs and Bezos are trying to lure in Gates with IT. They will attempt to control the world's economy to drive Gates crazy.:>) Then again, Gates probably IS driving a good chunk of the world's economy himself.
First of all, using PGP is not a smart idea. How would you do it? If you encrypt the entire ROM with PGP, then at runtime you would have to decrypt the entire ROM. At that point you just apply +5V and ground and read out the entire contents of the ram buffer, and CPS2 would have been broken only days after it came out.
Let's say that we made it more difficult, let's only encrypt/decrypt portions of ROMS at a time. If you do this you have to force the programmers to know what part of the ROM they were going to use at what time, or otherwise face some massive slowdowns as it decrypted it realtime upon access. If we made it so each instruction was ecnrypted at a time, then PGP would have been a massive failure. Thinking about how PGP works... generate a random symmetric key, encrypting the data, then applying the asymetric encryption for key exchange. Far too much work to do on a per instruction basis. Remember this was 1993, we were still using 20mhz 386sx's then. Technology could not have kept up with decrypting per instruction.
Besides, if you used PGP in 1993, you probasbly still wouldn't have had a RTU in a commerical application, and you certainly wouldn't have had the right to export out of the US.
From what I've read about CPS2, it's quite an smart system. No matter what system you use, PGP or CPS2's encryption, you have to store the keys somewhere. Without a cryptographic smart card, it has to be placed in RAM or ROM somewhere. So Capcom put it in some extremely volatile ram, making any sort of tampering very difficult to do, much like disabling a bomb. Once the board detected tampering, then it would lose the keys and render the board brain dead.
Next they made it so the encryption worked in real time. It didn't have to be extremely strong, but it had to be fast. They relyed on the keys being protected by the suicide circuit.
From what I understand, the CPS2Shock first started watching the instructions as they were being loaded on the data bus. They never could have got all the data off the roms in this manner, unless every code branch was executed. But they learned what the CPU sees... and they were able to inject their own code into the running system. From that point they were able to develop a brute force system to look at memory, and later they refined their technique to eliminate certain possibilites.
So CPS2Shock rocked the world by releasing the first translation table that made the encrypted ROMS useable. Next up, if they break the encryption, then they could simply attack the ROMS instead of having to use this process of finding the final value vs the value stored on the ROM.
It's sort of an security by obscurity, but I think that holding up for 8 years as well as it did, the CPS2 protection is still quite a formidable opponent. It may be even more difficult to break than the DVD code, since the keys for that hack were simply copied out of the code from a poorly implemented DVD player.
WIth CPS2, you don't have easy access to the keys, and the team broke the code through analysis, brute force, and key elmination. Next up they're going after the encryption itself since they now know both the decrypted info and the encrypted info.
First of all, using PGP is not a smart idea. How would you do it? If you encrypt the entire ROM with PGP, then at runtime you would have to decrypt the entire ROM. At that point you just apply +5V and ground and read out the entire contents of the ram buffer, and CPS2 would have been broken only days after it came out.
Let's say that we made it more difficult, let's only encrypt/decrypt portions of ROMS at a time. If you do this you have to force the programmers to know what part of the ROM they were going to use at what time, or otherwise face some massive slowdowns as it decrypted it realtime upon access.
If we made it so each instruction was ecnrypted at a time, then PGP would have been a massive failure. Thinking about how PGP works... generate a random symmetric key, encrypting the data, then applying the asymetric encryption for key exchange. Far too much work to do on a per instruction basis. Remember this was 1993, we were still using 20mhz 386sx's then. Technology could not have kept up with decrypting per instruction.
Besides, if you used PGP in 1993, you probasbly still wouldn't have had a RTU in a commerical application, and you certainly wouldn't have had the right to export out of the US.
From what I've read about CPS2, it's quite an smart system. No matter what system you use, PGP or CPS2's encryption, you have to store the keys somewhere. Without a cryptographic smart card, it has to be placed in RAM or ROM somewhere. So Capcom put it in some extremely volatile ram, making any sort of tampering very difficult to do, much like disabling a bomb. Once the board detected tampering, then it would lose the keys and render the board brain dead.
Next they made it so the encryption worked in real time. It didn't have to be extremely strong, but it had to be fast. They relyed on the keys being protected by the suicide circuit.
From what I understand, the CPS2Shock first started watching the instructions as they were being loaded on the data bus. They never could have got all the data off the roms in this manner, unless every code branch was executed. But they learned what the CPU sees... and they were able to inject their own code into the running system. From that point they were able to develop a brute force system to look at memory, and later they refined their technique to eliminate certain possibilites.
So CPS2Shock rocked the world by releasing the first translation table that made the encrypted ROMS useable. Next up, if they break the encryption, then they could simply attack the ROMS instead of having to use this process of finding the final value vs the value stored on the ROM.
It's sort of an security by obscurity, but I think that holding up for 8 years as well as it did, the CPS2 protection is still quite a formidable opponent. It may be even more difficult to break than the DVD code, since the keys for that hack were simply copied out of the code from a poorly implemented DVD player. WIth CPS2, you don't have easy access to the keys, and the team broke the code through analysis, brute force, and key elmination. Next up they're going after the encryption itself since they now know both the decrypted info and the encrypted info.
Even if this product ONLY suppported print clients on the XXXYYYYZZZ 2000 operating system, it is a good thing to see Linux being chosen as the development platform REGARDLESS OF WHETHER OR NOT LINUX CLIENTS ARE SUPPORTED. This tells me that Linux has now broken through the glass ceiling, and it is being chosen as the cost-effective, reliable development platform that is suitable for running an enterprise.
I think that's sending the wrong message to state that Linux needs to be supported as platform in such development environments. I'm more enthusiastic about the fact that we're now seeing Linux used in areas where Linux was not used before.
I do understand the counterpoint, I can tell that in a service such a print server, Linux should be supported (and based on the threads below, it is), but I want to preach Linux EVERYWHERE. Linux embedded, Linux for cross-platform development, Linux in heterogenous server environments, as well as Linux for Linux clients.
Slashdot Mirror
There is no conspiracy, if you want to buy a DVD player that supports CDs, YOU READ THE BOX FIRST. It wasn't a bean counter's decision. It's a question of whether or not the design specs required support for CDR or not. This one didn't, so they didn't put the extra laser in it to read the CDR.
Very few DVD players support CDRs. Sony didn't remove a feature that wasn't even there in the first place.
That's why the Apex was so compelling (besides, of course, the region code and macrovision hack). The Apex was a good, cheap DVD player that could play CDRs. Apex had to put support for both the DVD laser and the CDr laser (probably because supporting MP3 without supporting CDR would have seriously limited its market appeal)
The Spanish Prisoner was a David Mamet film staring Campbell Scott and Steve Martin. The premise was that a scientist invents a unnamed formulat that will control the world's economy for the next 3 years.
It's all top secret, nobody gets to see it. and the viewer never finds out what it is or what it does. I don't want to give away the movie
But I think that Jobs and Bezos are trying to lure in Gates with IT. They will attempt to control the world's economy to drive Gates crazy. :>) Then again, Gates probably IS driving a good chunk of the world's economy himself.
that once it's decrypted in RAM, then it's just a matter of dumping the RAM buffers to get the unencrypted rom.
Let's say that we made it more difficult, let's only encrypt/decrypt portions of ROMS at a time. If you do this you have to force the programmers to know what part of the ROM they were going to use at what time, or otherwise face some massive slowdowns as it decrypted it realtime upon access. If we made it so each instruction was ecnrypted at a time, then PGP would have been a massive failure. Thinking about how PGP works ... generate a random symmetric key, encrypting the data, then applying the asymetric encryption for key exchange. Far too much work to do on a per instruction basis. Remember this was 1993, we were still using 20mhz 386sx's then. Technology could not have kept up with decrypting per instruction.
Besides, if you used PGP in 1993, you probasbly still wouldn't have had a RTU in a commerical application, and you certainly wouldn't have had the right to export out of the US.
From what I've read about CPS2, it's quite an smart system. No matter what system you use, PGP or CPS2's encryption, you have to store the keys somewhere. Without a cryptographic smart card, it has to be placed in RAM or ROM somewhere. So Capcom put it in some extremely volatile ram, making any sort of tampering very difficult to do, much like disabling a bomb. Once the board detected tampering, then it would lose the keys and render the board brain dead.
Next they made it so the encryption worked in real time. It didn't have to be extremely strong, but it had to be fast. They relyed on the keys being protected by the suicide circuit.
From what I understand, the CPS2Shock first started watching the instructions as they were being loaded on the data bus. They never could have got all the data off the roms in this manner, unless every code branch was executed. But they learned what the CPU sees ... and they were able to inject their own code into the running system. From that point they were able to develop a brute force system to look at memory, and later they refined their technique to eliminate certain possibilites.
So CPS2Shock rocked the world by releasing the first translation table that made the encrypted ROMS useable. Next up, if they break the encryption, then they could simply attack the ROMS instead of having to use this process of finding the final value vs the value stored on the ROM.
It's sort of an security by obscurity, but I think that holding up for 8 years as well as it did, the CPS2 protection is still quite a formidable opponent. It may be even more difficult to break than the DVD code, since the keys for that hack were simply copied out of the code from a poorly implemented DVD player.
WIth CPS2, you don't have easy access to the keys, and the team broke the code through analysis, brute force, and key elmination. Next up they're going after the encryption itself since they now know both the decrypted info and the encrypted info.
that was SFZ for the Capcom changer system, not the CPS2 system.
First of all, using PGP is not a smart idea. How would you do it? If you encrypt the entire ROM with PGP, then at runtime you would have to decrypt the entire ROM. At that point you just apply +5V and ground and read out the entire contents of the ram buffer, and CPS2 would have been broken only days after it came out. Let's say that we made it more difficult, let's only encrypt/decrypt portions of ROMS at a time. If you do this you have to force the programmers to know what part of the ROM they were going to use at what time, or otherwise face some massive slowdowns as it decrypted it realtime upon access. If we made it so each instruction was ecnrypted at a time, then PGP would have been a massive failure. Thinking about how PGP works ... generate a random symmetric key, encrypting the data, then applying the asymetric encryption for key exchange. Far too much work to do on a per instruction basis. Remember this was 1993, we were still using 20mhz 386sx's then. Technology could not have kept up with decrypting per instruction.
Besides, if you used PGP in 1993, you probasbly still wouldn't have had a RTU in a commerical application, and you certainly wouldn't have had the right to export out of the US.
From what I've read about CPS2, it's quite an smart system. No matter what system you use, PGP or CPS2's encryption, you have to store the keys somewhere. Without a cryptographic smart card, it has to be placed in RAM or ROM somewhere. So Capcom put it in some extremely volatile ram, making any sort of tampering very difficult to do, much like disabling a bomb. Once the board detected tampering, then it would lose the keys and render the board brain dead.
Next they made it so the encryption worked in real time. It didn't have to be extremely strong, but it had to be fast. They relyed on the keys being protected by the suicide circuit.
From what I understand, the CPS2Shock first started watching the instructions as they were being loaded on the data bus. They never could have got all the data off the roms in this manner, unless every code branch was executed. But they learned what the CPU sees ... and they were able to inject their own code into the running system. From that point they were able to develop a brute force system to look at memory, and later they refined their technique to eliminate certain possibilites.
So CPS2Shock rocked the world by releasing the first translation table that made the encrypted ROMS useable. Next up, if they break the encryption, then they could simply attack the ROMS instead of having to use this process of finding the final value vs the value stored on the ROM.
It's sort of an security by obscurity, but I think that holding up for 8 years as well as it did, the CPS2 protection is still quite a formidable opponent. It may be even more difficult to break than the DVD code, since the keys for that hack were simply copied out of the code from a poorly implemented DVD player. WIth CPS2, you don't have easy access to the keys, and the team broke the code through analysis, brute force, and key elmination. Next up they're going after the encryption itself since they now know both the decrypted info and the encrypted info.
Even if this product ONLY suppported print clients on the XXXYYYYZZZ 2000 operating system, it is a good thing to see Linux being chosen as the development platform REGARDLESS OF WHETHER OR NOT LINUX CLIENTS ARE SUPPORTED. This tells me that Linux has now broken through the glass ceiling, and it is being chosen as the cost-effective, reliable development platform that is suitable for running an enterprise. I think that's sending the wrong message to state that Linux needs to be supported as platform in such development environments. I'm more enthusiastic about the fact that we're now seeing Linux used in areas where Linux was not used before. I do understand the counterpoint, I can tell that in a service such a print server, Linux should be supported (and based on the threads below, it is), but I want to preach Linux EVERYWHERE. Linux embedded, Linux for cross-platform development, Linux in heterogenous server environments, as well as Linux for Linux clients.
This will certainly be one of the few events where the line to the men's bathroom will be longer than the line to the women's bathroom!