You don't need to emulate the hardware to see a program's output, you can just look at your screen. There is little point in hiding the output of a program from the user who's running it so I don't see that as the point (if one cannot observe the output of a program, it is of little utility).
Which instructions a given program executes depends on the inputs to said program. For any given input, most programs only execute a tiny portion of their code. Therefore, in order to completely reverse engineer a program, you would have to observe the output for all possible inputs. This is almost certainly intractable for any sufficiently complex program. Suppose you wrote a program to iterate over all possible inputs observing the output of each input; things get interesting if you liken this to the halting problem.
I'm not saying torrent sites shouldn't be moderated, just that the site's owners should shy away from doing it themselves. Any site of sufficient size can be reasonably moderated by its users and there are plenty of ways to allow users to flag bad torrents. Also, I don't see any problem with having generic "top 20" lists for specific categories (preferably user generated); you just shouldn't (effectively) call them "Top 20 Copyrighted Hollywood Blockbusters" as you are acknowledging and condoning their existence.
... it seems like Fung's downfall was his own arrogance. The judgment states that Fung's failure to filter out copyright content alone would not have been sufficient grounds for contributory infringement. Contributory infringement was established because, in addition to this, Fung made forum posts detailing how to rip specific copyrighted works for his site and suggesting search terms to help find specific copyrighted works on his site. He also bragged about having certain copyrighted works available on his site and facilitated access to such content via top 20 lists.
Seems like other torrent sites should take note. Never acknowledge the existence of copyrighted content on your site or specifically facilitate access to it (e.g. "top 20" lists) or use copyright suggestive terminology (e.g. "blockbuster") or profit from your site, and you might just escape unscathed. You want to offer about as much assistance as google does when searching for torrent files. Do this and the 5% legitimate content might just save you.
You just awoke a sleeping giant. As we speak thousands of once idle keyboards are feverishly trying away to unravel the mystery of just who you are and what you did - you even told them where to look. How fond were you of your name?
...they're interested in gross profit. The problem with PC games is you have a shorter window in which to make a profit before piracy takes hold. If you don't believe that initial sales will be high enough, you either don't release a PC version or you delay it. It's about risk management. There is still a market for PG games, the games you see being released are the games that are expected to have strong initial sales (or that have some other mechanism to thwart piracy (be it DRM, online accounts or what have you)).
I'd say: "If they have nothing to hide, they have nothing to fear".
Tell that to the Jews pre-Nazi Germany. Even innocent looking information, in the hands of the wrong person, can be used for harm. It's not hard to imagine how it may be used against undercover cops.
I've summarized the technical reasons given by the three videos.
Executive Summary:
Seems like their peer-to-peer architecture exasperated otherwise common matchmaking and NAT transversal problems that should be expected and thoroughly tested when developing networked games.
Video 1:
Summary: The game is peer-to-peer.
Video 2:
Quote: "We're trying to figure out why users are being removed from the database, which keeps them from being connected, but their not really disconnected, but the server thinks they're disconnected."
Quote: "...and if you put a return to just ignore the disconnect message it works fine".
Video 3:
Quote: We're working on a problem in which something, for some reason, keeps telling the database that manages people's records that they're disconnected and we don't know why.
Quote: So you're putting in the the debug messages?
Quote: Yep. Just putting in some debug messages to figure out where these... what is, like... wh what... first of who is sending what, um these disconnects.
Quote: Right, okay, we'll be back.
Quote: "One of the fields in the database are backwards, or something, on IP addresses because there are so many IP addresses and ports and sockets and stuff that I don't know anything about."
Observation: They test a fix and it seems to work on several office PCs.
Summary: The description of the fix includes faster lobby connection time and visual changes to each players ping in the game lobby.
Paraphrase: How about in terms of the robustness of it, like, how much will people be able to connect?
Paraphrase: Their games are significantly more intelligent now. Um, there were are lot of crazy things that were going on before and we've been able to simplify a lot of them.
Paraphrase: What about proxy servers, do you think we need proxy servers now?
Paraphrase: No I don't think we need proxy servers. It might be good for backup; we were tossing around the thought, I think you brought this up, with routing some traffic if we can thorough the host. That may or may not be possible.
Paraphrase: Though we had to take care of the case if the host leaves the game we don't want the whole thing to fall apart.
Paraphrase: Right, right. But it might be a solution for players with low ping times who, you know, can't seem to connect to anybody, but, you know, want to get in the game.
Paraphrase: Right, that's true. Of course as a backup plan; so if the host left it would take out those people who have really bad connections. But based on what we're seeing, we think, this should handle symmetrical NATs now?
Paraphrase: What's that?
Paraphrase: Asymmetrical NATs; this should handle that now?
Paraphrase: Uh, it's going to handle it better, yeah.
Paraphrase: Well before it didn't handle it at all, so...
Paraphrase: Right before it didn't handle it at all, before...
Paraphrase: I mean if I have two IP addresses, will this work with it now?
Paraphrase: I don't know that if you have two IP addresses this will work. Uh, this is going to help alot with firewalls and nats, however, um, it does a better job of piercing through the firewall.
Paraphrase: Of course if you port forward to the right IP, then, from your router, then you're just set.
Paraphrase: Yeah, that's not an issue.
Paraphrase: So anyone who's technical will be fine, pretty much for sure, no matter on what kind of crazy connection they've got.
Paraphrase: And since we've spent more time improving the base systems in the program instead of doing one of the thing
After about 13 minutes of sitting in the stall, the police officer observed Craig lingering outside and frequently peeking through the crack of the door on the stall.
No doubt wondering WTF was taking the officer so long...
At 1216 hours, Craig tapped his right foot. I recognized this as a signal used by persons wishing to engage in lewd conduct. Craig tapped his toes several times and moves his foot closer to my foot.... The presence of others did not seem to deter Craig as he moved his right foot so that it touched the side of my left foot which was within my stall area. Craig then proceeded to swipe his left hand under the stall divider several times, with the palm of his hand facing upward.
More like a signal that he was out of toilet paper (which explains why he was "lingering outside" prior to the foot tapping).
The first question that came to my mind after reading the article was are these laser generated random numbers suitable for cryptography? The article just states that random numbers are "vital" to cryptography, not that this method generates cryptographic grade random numbers. Certainly the brief explanation on how it works leaves a lot of room for question.
BTW, CryptMT is a simple stream cipher based on the Mersenne Twister. Sadly, the last time I looked at it it lacked any solid proofs. Nonetheless, Mersenne Twister is an excellent pseudorandom number generator.
The point of using a server for validation is that the server can know something the client doesn't. When the client knows everything, it becomes easier to crack because the necessary information is available, just obfuscated.
If I were implementing this, I might do something like:
Client sends server a unique id.
Server encrypts a license by hashing the id along with an expiration date 10 days in the future and signing it with an RSA signature.
Client verifies the license by decrypting it with the RSA public key and comparing it to its own hash of its id along with the expiration date. If the two do not match, or the current date is after the expiration date, the client exits.
No amount of packet sniffing will break this scheme unless you can break RSA signatures. The only three ways to circumvent it are:
Crack the.exe.
Change the date on your computer before playing.
Obtain the public key. (Maybe an employee will leak it.)
Of course, that's only in my example. A more complex scheme may be used.
All and all, if the client can play the game without an active internet connection, you should be able to crack the DRM. It's when an active internet connection is required during gameplay that we're really going to be in trouble.
I thought for a minute there that the Prince of Sweden had teamed up with a random Swedish village to sue The Pirate Bay.
My train of thought went from anger at the demeaning and archaic reference to the Swedish populous as "village people", to puzzlement about what possible copyrights the prince and villagers could hold in common, to loss of what little respect I have left for those groups.
In my final year in CS, I wrote a lengthy paper researching various DRBGs. To my surprise, there were very few good candidates for cryptographic DRBGs, but of the 7 I looked at, Dual_EC_DRBG rated the worst. I was unable to find any theoretic proofs for Dual_EC_DRBG, but I did find a few papers exposing serious flaws in Dual_EC_DRBG including this one which describes a tractable distinguisher so efficient it can run on a modest desktop.
The other three DRBGs recommended by NIST were all reliant on the security of various other cryptographic primitives such as SHA (Hash_DRBG), HMAC (HMAC_DRBG - which is often based on SHA) and AES or 3DES (CRT_DRBG). They were all reasonably obvious, and only really tried to set out some sort of standard for jumbling the output of their respective primitives enough that they would be resilient to any unknown vulnerabilities in said primitives (though certain paths also failed to do this). This was mostly accomplished by calling the primitives several times (HMAC_DRBG with the NIST HMAC implementation called for 6 SHA hashes per SHA sized output) which isn't very efficient.
I suspect they only included Dual_EC_DRBG because it wouldn't have looked too good if they were unable to come up with a single number theoretic or otherwise novel DRBG. They shouldn't be too disappointed, however, as the only one I was able to find was Blum Blum Shub which is terribly inefficient. CryptMT (Cryptanalysis) also deserves a mention as it looks like a promising pseudo-number theoretic DRBG, at least a better candidate than Dual_EC_DRBG.
I'm not sure how fast this "force" thing moves, but no one seems to have felt a great disturbance in it yet...
Re:Why Does Encryption Need to "Scramble" Informat
on
A Mighty Number Falls
·
· Score: 1
You simply could not crack it unless you already knew the information being sent.
Perfectly secure methods (one time pad) are perfectly secure because even if you have the cryptotext and the plaintext, the probably that the cryptotext is the plaintext is the same for all plaintexts if you don't know the key (e.g. if you knew the cryptotext is one of two plaintexts, the probability that it was one or the other is 0.5 regardless of what you know about the algorithm).
Slashdot Mirror
You don't need to emulate the hardware to see a program's output, you can just look at your screen. There is little point in hiding the output of a program from the user who's running it so I don't see that as the point (if one cannot observe the output of a program, it is of little utility).
Which instructions a given program executes depends on the inputs to said program. For any given input, most programs only execute a tiny portion of their code. Therefore, in order to completely reverse engineer a program, you would have to observe the output for all possible inputs. This is almost certainly intractable for any sufficiently complex program. Suppose you wrote a program to iterate over all possible inputs observing the output of each input; things get interesting if you liken this to the halting problem.
I'm not saying torrent sites shouldn't be moderated, just that the site's owners should shy away from doing it themselves. Any site of sufficient size can be reasonably moderated by its users and there are plenty of ways to allow users to flag bad torrents. Also, I don't see any problem with having generic "top 20" lists for specific categories (preferably user generated); you just shouldn't (effectively) call them "Top 20 Copyrighted Hollywood Blockbusters" as you are acknowledging and condoning their existence.
... it seems like Fung's downfall was his own arrogance. The judgment states that Fung's failure to filter out copyright content alone would not have been sufficient grounds for contributory infringement. Contributory infringement was established because, in addition to this, Fung made forum posts detailing how to rip specific copyrighted works for his site and suggesting search terms to help find specific copyrighted works on his site. He also bragged about having certain copyrighted works available on his site and facilitated access to such content via top 20 lists.
Seems like other torrent sites should take note. Never acknowledge the existence of copyrighted content on your site or specifically facilitate access to it (e.g. "top 20" lists) or use copyright suggestive terminology (e.g. "blockbuster") or profit from your site, and you might just escape unscathed. You want to offer about as much assistance as google does when searching for torrent files. Do this and the 5% legitimate content might just save you.
You just awoke a sleeping giant. As we speak thousands of once idle keyboards are feverishly trying away to unravel the mystery of just who you are and what you did - you even told them where to look. How fond were you of your name?
...they're interested in gross profit. The problem with PC games is you have a shorter window in which to make a profit before piracy takes hold. If you don't believe that initial sales will be high enough, you either don't release a PC version or you delay it. It's about risk management. There is still a market for PG games, the games you see being released are the games that are expected to have strong initial sales (or that have some other mechanism to thwart piracy (be it DRM, online accounts or what have you)).
I'd say: "If they have nothing to hide, they have nothing to fear".
Tell that to the Jews pre-Nazi Germany. Even innocent looking information, in the hands of the wrong person, can be used for harm. It's not hard to imagine how it may be used against undercover cops.
It was so awesome it pegged a whole core on my E8400. I expect to web to fuel larger hard drives, but faster CPUs? That's gettinga little out of hand.
I've summarized the technical reasons given by the three videos.
Executive Summary:
Seems like their peer-to-peer architecture exasperated otherwise common matchmaking and NAT transversal problems that should be expected and thoroughly tested when developing networked games.
Video 1:
Video 2:
Video 3:
After about 13 minutes of sitting in the stall, the police officer observed Craig lingering outside and frequently peeking through the crack of the door on the stall.
No doubt wondering WTF was taking the officer so long...
At 1216 hours, Craig tapped his right foot. I recognized this as a signal used by persons wishing to engage in lewd conduct. Craig tapped his toes several times and moves his foot closer to my foot. ... The presence of others did not seem to deter Craig as he moved his right foot so that it touched the side of my left foot which was within my stall area. Craig then proceeded to swipe his left hand under the stall divider several times, with the palm of his hand facing upward.
More like a signal that he was out of toilet paper (which explains why he was "lingering outside" prior to the foot tapping).
A lot of us here on /. are IT workers, why not just ask us?
How has the current economic landscape affected your employer?
It might actually provide some useful insight. #6 applies to me.
I'm using my 1984 Atari Touch Tablet you insensitive clod; one 535 x 383 resolution picture per page is a lot to ask for.
The first question that came to my mind after reading the article was are these laser generated random numbers suitable for cryptography? The article just states that random numbers are "vital" to cryptography, not that this method generates cryptographic grade random numbers. Certainly the brief explanation on how it works leaves a lot of room for question.
BTW, CryptMT is a simple stream cipher based on the Mersenne Twister. Sadly, the last time I looked at it it lacked any solid proofs. Nonetheless, Mersenne Twister is an excellent pseudorandom number generator.
Not only that, but he's going to have troubles wearing all that armor and wielding a lance. Ba-dum-ch!
How about some nice Bill Gates pics?
I guess Atomic Bomb kinda covers it, but still, hardly a respectable list.
The point of using a server for validation is that the server can know something the client doesn't. When the client knows everything, it becomes easier to crack because the necessary information is available, just obfuscated.
If I were implementing this, I might do something like:
No amount of packet sniffing will break this scheme unless you can break RSA signatures. The only three ways to circumvent it are:
Of course, that's only in my example. A more complex scheme may be used.
All and all, if the client can play the game without an active internet connection, you should be able to crack the DRM. It's when an active internet connection is required during gameplay that we're really going to be in trouble.
I thought for a minute there that the Prince of Sweden had teamed up with a random Swedish village to sue The Pirate Bay.
My train of thought went from anger at the demeaning and archaic reference to the Swedish populous as "village people", to puzzlement about what possible copyrights the prince and villagers could hold in common, to loss of what little respect I have left for those groups.
In my final year in CS, I wrote a lengthy paper researching various DRBGs. To my surprise, there were very few good candidates for cryptographic DRBGs, but of the 7 I looked at, Dual_EC_DRBG rated the worst. I was unable to find any theoretic proofs for Dual_EC_DRBG, but I did find a few papers exposing serious flaws in Dual_EC_DRBG including this one which describes a tractable distinguisher so efficient it can run on a modest desktop.
The other three DRBGs recommended by NIST were all reliant on the security of various other cryptographic primitives such as SHA (Hash_DRBG), HMAC (HMAC_DRBG - which is often based on SHA) and AES or 3DES (CRT_DRBG). They were all reasonably obvious, and only really tried to set out some sort of standard for jumbling the output of their respective primitives enough that they would be resilient to any unknown vulnerabilities in said primitives (though certain paths also failed to do this). This was mostly accomplished by calling the primitives several times (HMAC_DRBG with the NIST HMAC implementation called for 6 SHA hashes per SHA sized output) which isn't very efficient.
I suspect they only included Dual_EC_DRBG because it wouldn't have looked too good if they were unable to come up with a single number theoretic or otherwise novel DRBG. They shouldn't be too disappointed, however, as the only one I was able to find was Blum Blum Shub which is terribly inefficient. CryptMT (Cryptanalysis) also deserves a mention as it looks like a promising pseudo-number theoretic DRBG, at least a better candidate than Dual_EC_DRBG.
I think the data version of Parkinson's Law applies here: "Data expands to fill the space available for storage".
EM64T?
I'm attempting to repeat your experiment as we speak, I'll gkjnet bac kto youu w ith teh reuslt in...
...uuggggggh.
A favorite story for stat teachers, I believe this is what you're thinking about.
I'm not sure how fast this "force" thing moves, but no one seems to have felt a great disturbance in it yet...
Perfectly secure methods (one time pad) are perfectly secure because even if you have the cryptotext and the plaintext, the probably that the cryptotext is the plaintext is the same for all plaintexts if you don't know the key (e.g. if you knew the cryptotext is one of two plaintexts, the probability that it was one or the other is 0.5 regardless of what you know about the algorithm).
The Navajo language is an example of security through obscurity, it's not comparable to one time pad. The Navajo language is susceptible to many attacks, e.g. frequencly analysis.
I do wonder whatever became of this