Porting the assembly portion of a game is minor. In most cases, you write a C routine and then hand-compile it to assembly and leave the assembly in an #ifdef x86 block anyway. The bigger issue is DirectX. Game developers don't want to run their game in translation, so they port to OpenGL. It's not going to get any easier to port software.
1) The XBox used RSA2048 and I don't believe that was US-only. 2) We're talking about the entertainment industry, which has more than enough influence to legalize high-strength encryption. Of course, they'd make it only usable in DRM situations, so they screw everyone else...
I don't know how they'll secure the machine itself, but using public-key cryptography over the network connection will stop worms and the like from causing the players to self-destruct.
"No offence, but what you just described doesn't make any sense. If the public key of the device is in the firmware I would imagine that somebody will get a hold of it pretty quick.
Also it's fairly easy to implement a man in the middle attack for what you just described. Once you have the player's public key you can intercept all the traffic going to it and decrypt it. "
Yes, you can get the public key, and yes, you can decrypt the content going down the line. You, however, can't change the content, as you need to re-encrypt it to do so. (You could alter the ciphertext in hopes of getting the proper resulting plaintext, but it'd take forever)
"If you capture enough data you could figure out what messages were going to the player, and then if necessary you could just capture the (presumably encrypted) responses from the player to the server. So lets say that your player gets a "self destruct message" you just intercept it and throw it away, and then just replay a previous "ok i'm dead" message back to the server."
The problem with this is that rolling encryption or salting will completely fuck over the idea of message replaying. Yet again, it falls down to the fact that you need the private key to mount these attacks, if the systems are implemented properly. I don't think they're going to make the standard mistakes again.
"No offence, but what you just described doesn't make any sense. If the public key of the device is in the firmware I would imagine that somebody will get a hold of it pretty quick.
Also it's fairly easy to implement a man in the middle attack for what you just described. Once you have the player's public key you can intercept all the traffic going to it and decrypt it. "
Yes, you can get the public key, and yes, you can decrypt the content going down the line. You, however, can't change the content, as you need to re-encrypt it to do so. (You could alter the ciphertext in hopes of getting the proper resulting plaintext, but it'd take forever)
"If you capture enough data you could figure out what messages were going to the player, and then if necessary you could just capture the (presumably encrypted) responses from the player to the server. So lets say that your player gets a "self destruct message" you just intercept it and throw it away, and then just replay a previous "ok i'm dead" message back to the server."
The problem with this is that rolling encryption or salting will completely fuck over the idea of message replaying. Yet again, it falls down to the fact that you need the private key to mount these attacks, if the systems are implemented properly. I don't think they're going to make the standard mistakes again.
I doubt many people at all will have access to the private key. Getting the public key will be trivial, but that doesn't help you a bit unless you have a few thousand years to factor it.
I have to wonder what protection mechanisms will be in place to stop things like buffer overflows in their security code. The problem is that a break in the "chain of trust" anywhere could (and probably would) cause a security issue.
Running everything in a memory-protected VM would be a solution, but that's simply not practical on typical embedded hardware. Perhaps we'll start seeing more powerful processors being used for embedded systems soon...
This implies that the debugger can be detected. There are many ways you can implement debugger stealthing at the debugger level, and there's always the option of modifying/removing the debugger detection routines. I've done quite a bit of research in automated removal of debugger detection routines, some of which is available at http://www.datarescue.com/cgi-local/ultimatebb.cgi ?ubb=get_topic;f=4;t=000320;p=0 if you're interested.
Most of what stops normal people won't stop a good reverse engineer with a good debugger and disassembler.
"Besides, what's to prevent a hacker from filtering out this self-destruct code from the downstream content anyway?"
I'd be willing to bet a month's salary that they are going to use public-key cryptography with a bigass key to protect it. RSA2048 will keep anyone from screwing with it. Hard-code the SSL public key, and the only way you're going to launch a man-in-the-middle attack against it is by rewriting the key.
You know, I'm hearing more and more stories like this. I started with BASIC in kindergarten and picked it up no problem (of course it was on an Apple ][E, so there wasn't even QBasic-style graphics functionality, but the point remains the same). Perhaps it's just that kids have less to think about that makes it easy for them to pick up things like that.
I've been able to pick up a number of languages, syntax-wise, but I can't recall learning any language (functions and all) faster than I learned the whole (well, as much as I learned) of BASIC.
It runs in a web browser. So it isn't a separate application, which makes the phrase "supports windows, os x, and linux" sound a little like marketing fluff.
Wrong. There is a client-side application which is required for listening to the full-length previews they supply (you can listen to them 3 times IIRC)
Just buy now. Not only will the x86 machines not be ready for general consumption for quite a while, you'll have a better software base on PowerPC (when speaking strictly about Macs) for years to come anyway.
I strongly doubt it. Unless the latest standard Intel chips are dual-endian, then requiring modified chips would cause production issues I'd think. Not only that, but the ABI they described in the Universal Binaries guide described endianness pretty in-depth... no reason they'd go into that if it was capable of running in a big-endian mode, unless there's a significant performance hit in that case, which I don't really foresee.
We've been able to address more than 4GB of memory on x86 for many years. In fact, you can address up to 64GB of memory (36-bits) on modern x86 chips (P2 and up IIRC) in the kernel. A given process (or thread on certain OS's I believe) can address only 32-bits, but that's easily circumvented if you _need_ to do it.
Slashdot Mirror
This is Slashdot, where even a one-use condom is unnecessary.
Wonder what exception got thrown for that one...
It was a toy or something!
So long as the hashes aren't salted, which they most likely aren't in many cases, although they should be.
But who will be in the driver's seat?
Whoever's driving the car, duh.
Porting the assembly portion of a game is minor. In most cases, you write a C routine and then hand-compile it to assembly and leave the assembly in an #ifdef x86 block anyway. The bigger issue is DirectX. Game developers don't want to run their game in translation, so they port to OpenGL. It's not going to get any easier to port software.
1) The XBox used RSA2048 and I don't believe that was US-only.
2) We're talking about the entertainment industry, which has more than enough influence to legalize high-strength encryption. Of course, they'd make it only usable in DRM situations, so they screw everyone else...
I don't know how they'll secure the machine itself, but using public-key cryptography over the network connection will stop worms and the like from causing the players to self-destruct.
Correct... However, I wasn't talking about DRM. I was talking about the self-destruct signals.
"No offence, but what you just described doesn't make any sense. If the public key of the device is in the firmware I would imagine that somebody will get a hold of it pretty quick.
Also it's fairly easy to implement a man in the middle attack for what you just described. Once you have the player's public key you can intercept all the traffic going to it and decrypt it. "
Yes, you can get the public key, and yes, you can decrypt the content going down the line. You, however, can't change the content, as you need to re-encrypt it to do so. (You could alter the ciphertext in hopes of getting the proper resulting plaintext, but it'd take forever)
"If you capture enough data you could figure out what messages were going to the player, and then if necessary you could just capture the (presumably encrypted) responses from the player to the server. So lets say that your player gets a "self destruct message" you just intercept it and throw it away, and then just replay a previous "ok i'm dead" message back to the server."
The problem with this is that rolling encryption or salting will completely fuck over the idea of message replaying. Yet again, it falls down to the fact that you need the private key to mount these attacks, if the systems are implemented properly. I don't think they're going to make the standard mistakes again.
"No offence, but what you just described doesn't make any sense. If the public key of the device is in the firmware I would imagine that somebody will get a hold of it pretty quick. Also it's fairly easy to implement a man in the middle attack for what you just described. Once you have the player's public key you can intercept all the traffic going to it and decrypt it. " Yes, you can get the public key, and yes, you can decrypt the content going down the line. You, however, can't change the content, as you need to re-encrypt it to do so. (You could alter the ciphertext in hopes of getting the proper resulting plaintext, but it'd take forever) "If you capture enough data you could figure out what messages were going to the player, and then if necessary you could just capture the (presumably encrypted) responses from the player to the server. So lets say that your player gets a "self destruct message" you just intercept it and throw it away, and then just replay a previous "ok i'm dead" message back to the server." The problem with this is that rolling encryption or salting will completely fuck over the idea of message replaying. Yet again, it falls down to the fact that you need the private key to mount these attacks, if the systems are implemented properly. I don't think they're going to make the standard mistakes again.
I doubt many people at all will have access to the private key. Getting the public key will be trivial, but that doesn't help you a bit unless you have a few thousand years to factor it.
I have to wonder what protection mechanisms will be in place to stop things like buffer overflows in their security code. The problem is that a break in the "chain of trust" anywhere could (and probably would) cause a security issue.
Running everything in a memory-protected VM would be a solution, but that's simply not practical on typical embedded hardware. Perhaps we'll start seeing more powerful processors being used for embedded systems soon...
This implies that the debugger can be detected. There are many ways you can implement debugger stealthing at the debugger level, and there's always the option of modifying/removing the debugger detection routines. I've done quite a bit of research in automated removal of debugger detection routines, some of which is available at http://www.datarescue.com/cgi-local/ultimatebb.cgi ?ubb=get_topic;f=4;t=000320;p=0 if you're interested.
Most of what stops normal people won't stop a good reverse engineer with a good debugger and disassembler.
"Besides, what's to prevent a hacker from filtering out this self-destruct code from the downstream content anyway?"
I'd be willing to bet a month's salary that they are going to use public-key cryptography with a bigass key to protect it. RSA2048 will keep anyone from screwing with it. Hard-code the SSL public key, and the only way you're going to launch a man-in-the-middle attack against it is by rewriting the key.
You know, I'm hearing more and more stories like this. I started with BASIC in kindergarten and picked it up no problem (of course it was on an Apple ][E, so there wasn't even QBasic-style graphics functionality, but the point remains the same). Perhaps it's just that kids have less to think about that makes it easy for them to pick up things like that.
I've been able to pick up a number of languages, syntax-wise, but I can't recall learning any language (functions and all) faster than I learned the whole (well, as much as I learned) of BASIC.
Started in kindergarten, myself... on the Apple ][E in the back of the class haha.
Since programming is not merely a vocabulary, but also a method of doing things, it would be interesting to see how well young kids pick it up.
This is what the mb (multibyte) string functionality in PHP is for.
It runs in a web browser. So it isn't a separate application, which makes the phrase "supports windows, os x, and linux" sound a little like marketing fluff.
Wrong. There is a client-side application which is required for listening to the full-length previews they supply (you can listen to them 3 times IIRC)
Just buy now. Not only will the x86 machines not be ready for general consumption for quite a while, you'll have a better software base on PowerPC (when speaking strictly about Macs) for years to come anyway.
I strongly doubt it. Unless the latest standard Intel chips are dual-endian, then requiring modified chips would cause production issues I'd think. Not only that, but the ABI they described in the Universal Binaries guide described endianness pretty in-depth... no reason they'd go into that if it was capable of running in a big-endian mode, unless there's a significant performance hit in that case, which I don't really foresee.
I know that water on a fish out of water can look very shiny, but can it really be considered mirroring?
Joke status: Dead...
We've been able to address more than 4GB of memory on x86 for many years. In fact, you can address up to 64GB of memory (36-bits) on modern x86 chips (P2 and up IIRC) in the kernel. A given process (or thread on certain OS's I believe) can address only 32-bits, but that's easily circumvented if you _need_ to do it.