BD+ isn't an algorithm so there's no global crack unless the designers made a serious mistake in their implementation. A movie protected by BD+ is partly damaged... elements of the video stream are deliberately corrupted, making it unwatchable. The BD+ program runs and checks out the environment it's in. If it's happy it spits out a patch table, which tells the player how to repair the movie. Note that the patch table can alter the movie in arbitrary ways - theoretically, things could change depending on what player you use. This allows the developers to discover which player is leaking video.
Early BluRay discs weren't protected by BD+ at all, and the first titles that were barely used the features BD+ provides. They existed only to detect a buggy software player but otherwise didn't do much. This was deliberate - the BD+ people are playing a long game, and don't want to play all their cards at once. The idea is to reveal their tricks slowly, such that it takes a few months to unravel each time. Because most sales of the movies are soon after they come out, it doesn't matter if a 6-12 month old program is broken.
In theory every title could have a unique BD+ program that takes time to crack, but that's pretty expensive, so they seem to come in waves. Probably there are only a few people in the world who know how to write BD+ programs and then their work is used on lots of discs.
The first round in this game was easy - the BD+ titles simply relied on obscurity to protect them. If they ran at all, they spat out the patch table. After SlySoft and later the doom9 guys figured out how BD+ worked, there were confident predictions that the system was broken, but of course that was never the case. The second round is the one we're on now and it's apparently quite the smackdown... nobody knows what they've done, but making the new programs think they're in a licensed player is tough.
FWIW I don't buy nor download BluRay movies, I just find BD+ a fascinating battle of wits. I'm sure there'll be a lot of back and forth over the lifetime of the system.
If you had read the linked articles, you would have seen that SlySoft ran into problems at the start of November, that was actually before the open source VM was released. Just because I didn't spell out everything for you in the summary doesn't mean you have to be sarcastic.
Wow, the denial on this thread is amazing. The test hasn't even started yet, and people are already writing it off on the grounds that it can't be a "real" test, or that they're doing it wrong, or whatever.
I think it's safe to assume it won't make much difference, because modern PC DRM doesn't seem very strong, but to make blanket statements about DRM is pretty absurd - it clearly does work in other implementations, like the consoles.
Let's wait and see what the numbers say. I know most Slashdotters made up their mind a long time ago, but at least Ubisoft is open to other ideas.
I suspect a part of that system is because in those times, communication was very poor, and messages took a long time to traverse a place as large as the USA. I'm not sure multiple levels of indirection are necessary or good any more.
Paying people more doesn't make them suddenly skilled. All it does is suck talent away from your competitors, it's zero sum. It might also encourage more people to enter the field, but if education is poor, why would they be any more skilled than previously?
I'd agree with Stroustroup. The number of people out there who truly understand computers and software development is too small, because new developers have to re-learn the lessons all over again due to poor or non-existant teaching.
A blur filter implemented in JavaScript is unusably slow.
Yes, JavaScript engines are getting better. But they started so slow they were useless for anything beyond trivial control logic, so that's hardly a ringing endorsement. Even if JavaScript were to somehow achieve native speeds, its memory footprint would be awful compared to C++, which is a large part of the reason Java sucks for desktop work.
Well maybe you should watch this presentation and then you'd understand why Dalvik was created. Hint: it has nothing to do with licensing, and everything to do with the performance characteristics of mobile phones.
Did you get past page 3? Unmasked jumps are forbidden by static analysis, so you can't create new code and jump into it. Existing code is verified against whitelisted opcode sets. Segmentation it used to prevent self-modifying code. Tricks that prevent accurate dissasembly are also forbidden by the verifier.
Even if we assume that the system will only allow a small subset of x86 code, there is still the very real possibility that it will be impossible to protect against the full ISA when executing code natively. Just off the top of my head, I'm already thinking of carefully crafting instructions so that they seem correct when the verifier passes over them in sequence, but actually execute as different instructions when the jump is executed into what appears to be the middle of an instruction. Oops.
You're making the same mistake I made when I first started working at Google. I tended to assume I was smarter than average, and there, it just isn't true. Google engineers aren't perfect but 99% of the time, when I've looked at some colleagues work and thought "that looks really stupid", it turned out to have a really good reason.
Case in point, why does Android use a custom Java ISA instead of native code? I thought that was so dumb! On a mobile device performance is at a premium and interpreting code just seemed like a massive battery and performance sink. And it is. But I forgot something crucial - RAM is expensive on mobile device, and the Dalvik VM is extremely compact and optimized for minimal memory usage.
In this case, you haven't read the paper. Jumping into the middle of instructions is forbidden by the alignment rules, which are enforced by a small but extremely fast static verifier.
What's more, any other attacks you can think of have likely been considered already. The NativeClient team ran extensive fuzz tests against their implementation, fuzz tests sophisticated enough to detect several CPU bugs (!) and all of them have been sealed. The people behind this have extensive track records in the security community and speak the x86 ISA fluently.
That doesn't mean there won't be faults or mistakes. It does mean you should not underestimate this software.
I used to think Jazelle meant actual Java bytecode execution on the chip, until I talked to an Android developer about it. It turns out that Jazelle is quite incomplete and traps out to native code quite frequently... for instance, to call a method.
That said, so what? You already have to write special web pages for mobile devices if you want a truly great user experience. The performance/power profiles of mobile devices are so radically differen to desktops that being unable to run x86 code natively isn't a big deal... even if there was some kind of hardware neutral IL you still wouldn't want to use it on mobiles, for the same reason mobile browsers don't download and run WebStart applets.
Holy crap. AKAImBatman I usually enjoy your posts, but it's painfully clear nobody on this thread - including you - has actually read the paper.
If you had, you'd see that this system is secure. It's simple yet clever at the same time. By using a combination of x86 segmentation (which ironically you say is never used anymore!), alignment rules, static analysis and - crucially - masked jumps, it's possible to ensure that native code cannot synthesize unverified code in memory and then jump into it. If you can prevent arbitrary code synthesis, you can control what the program does. It's as simple as that.
Even though the verifier for this system is microscopic (compared to, say, a JVM), and so much more likely to be correct, NativeClient also includes a ptrace sandbox to provide an additional redundant level of protection.
One must be VERY careful with native code because there is no way to prove that it is safe to execute natively.
I don't blame you, because until I read the paper I also believed this. Once you read it you'll slap your forehead and say, my god, it's so simple. Why didn't I think of that?
For what it's worth, nearly any large, professionally written high performance codebase is done in C++ these days. Consider programs like the Unreal Engine, the Google search engine, Firefox, any 3D video game... all written in object-oriented modern C++.
If you want to work on interesting codebases in a job, I'd definitely master C++. It covers a few different ways of programming, but if you know C++, one scripting language (eg Python) and one functional language (no need for lots of depth), you've got a good foundation as a programmer. I'd note that if you learn C++ Java is simply a matter of getting familiar with the libraries - it's largely a subset of C++.
I love this game. I like the approach they took here as well - I guess it'd have been too expensive to produce fully textured city levels like in the game, so they just went ahead and produced textureless levels, but lots of them. Looking forward to tryint it out.
Do you have any data to back that up? It's not for SecuRom but the data UbiSoft published about StarForce strongly suggests that the level of DRM related problems, even with very aggressive implementations, is low. As in sub-1% low. I'm really sceptical that even 1% of this 1 million+ figure is people downloading it "because they had to" after buying it. Occams Razor says the simplest explanation wins - those people are pirates.
That's a pretty strong assertion. Last time I looked, you had to mod your xbox, which required - in the best case - special equipment and an Xbox of the right generation. And then you risk getting your console banned from Live if you ever let it connect again.
In modern processors, there is no penalty for using virtual memory, all translation from virtual to physical address space is done internal to the processor and you won't notice the difference.
That's not quite true actually. Microsoft measured the overhead of doing page table translations and kernel mode switching at about 30%. Running things in isolated address spaces is quite expensive, it turns out, even with dedicated hardware support.
The problem is the phrasing. I can easily pull down 1Mbps for several hours at a time every so often and not run anywhere close to my cap, but I know if I did that 24/7 I would hit it. So what does "constant" mean? And why is it clearer to explain it that way than just state peak bandwidth and total cap?
Consider doing such a transfer trans-Atlantic when there's a temporary loss of capacity due to (say) a ships anchor cutting a fibre route. Suddenly your connection is congested although your ISP has not been overselling you - there's just been a loss of capacity on the network and now the backoff features no longer work. So instead of stuff just getting slower the whole system starts to break. That's what the author of TFA is afraid of - whether the actual implementation in uTorrent will do this, I can't say, but it sounds plausible.
The big numbers aren't imaginary, they're what you can use at burst speeds. Unless you consider any use of overcommit to result in "imaginary numbers" in which case water, gas, electricity, also sell you imaginary things.
Eh? It's BitTorrent that abuses the internet and Sandvine that tries to stop that abuse! Really BitTorrent is the most inefficient way of distributing files you could possibly design. It has one, and only one, reason for existance - it lets its users externalize bandwidth costs that they should be paying onto everybody else. There are no legitimate uses of this technology, anybody who legitimately needs to distribute huge files to lots of people can use CDNs like the mirror network or Akamai, and then set their cache headers correctly. Otherwise every time somebody distributes a big file with BitTorrent, they effectively make everyone on the internet pay for that bandwidth instead of themselves.
Your argument is sort of like a factory saying, hey, we're only dumping our toxic waste onto the roads because when we dumped it into the rivers the rivers authority got on our backs.
If an ISP is actually lying about what they sell, take them to court for contract violation. But I doubt you can actually do that because I doubt any ISP is stupid enough to actually sell unlimited internet. Always, in the contract you sign there will be fine print. In which case it's not lying, is it?
Slashdot Mirror
Or until somebody writes and sells a licensed BluRay player for Linux. Y'know ... like any other platform.
BD+ isn't an algorithm so there's no global crack unless the designers made a serious mistake in their implementation. A movie protected by BD+ is partly damaged ... elements of the video stream are deliberately corrupted, making it unwatchable. The BD+ program runs and checks out the environment it's in. If it's happy it spits out a patch table, which tells the player how to repair the movie. Note that the patch table can alter the movie in arbitrary ways - theoretically, things could change depending on what player you use. This allows the developers to discover which player is leaking video.
Early BluRay discs weren't protected by BD+ at all, and the first titles that were barely used the features BD+ provides. They existed only to detect a buggy software player but otherwise didn't do much. This was deliberate - the BD+ people are playing a long game, and don't want to play all their cards at once. The idea is to reveal their tricks slowly, such that it takes a few months to unravel each time. Because most sales of the movies are soon after they come out, it doesn't matter if a 6-12 month old program is broken.
In theory every title could have a unique BD+ program that takes time to crack, but that's pretty expensive, so they seem to come in waves. Probably there are only a few people in the world who know how to write BD+ programs and then their work is used on lots of discs.
The first round in this game was easy - the BD+ titles simply relied on obscurity to protect them. If they ran at all, they spat out the patch table. After SlySoft and later the doom9 guys figured out how BD+ worked, there were confident predictions that the system was broken, but of course that was never the case. The second round is the one we're on now and it's apparently quite the smackdown ... nobody knows what they've done, but making the new programs think they're in a licensed player is tough.
FWIW I don't buy nor download BluRay movies, I just find BD+ a fascinating battle of wits. I'm sure there'll be a lot of back and forth over the lifetime of the system.
If you had read the linked articles, you would have seen that SlySoft ran into problems at the start of November, that was actually before the open source VM was released. Just because I didn't spell out everything for you in the summary doesn't mean you have to be sarcastic.
The unrunnable BD+ programs started appearing at the start of November, so that's Nov/Dec/Jan/Feb -> 4 months, longer than their worst case scenario.
Wow, the denial on this thread is amazing. The test hasn't even started yet, and people are already writing it off on the grounds that it can't be a "real" test, or that they're doing it wrong, or whatever.
I think it's safe to assume it won't make much difference, because modern PC DRM doesn't seem very strong, but to make blanket statements about DRM is pretty absurd - it clearly does work in other implementations, like the consoles.
Let's wait and see what the numbers say. I know most Slashdotters made up their mind a long time ago, but at least Ubisoft is open to other ideas.
I suspect a part of that system is because in those times, communication was very poor, and messages took a long time to traverse a place as large as the USA. I'm not sure multiple levels of indirection are necessary or good any more.
The paper compares NativeClient to Xax. It sounds quite different.
Paying people more doesn't make them suddenly skilled. All it does is suck talent away from your competitors, it's zero sum. It might also encourage more people to enter the field, but if education is poor, why would they be any more skilled than previously?
I'd agree with Stroustroup. The number of people out there who truly understand computers and software development is too small, because new developers have to re-learn the lessons all over again due to poor or non-existant teaching.
A blur filter implemented in JavaScript is unusably slow.
Yes, JavaScript engines are getting better. But they started so slow they were useless for anything beyond trivial control logic, so that's hardly a ringing endorsement. Even if JavaScript were to somehow achieve native speeds, its memory footprint would be awful compared to C++, which is a large part of the reason Java sucks for desktop work.
Well maybe you should watch this presentation and then you'd understand why Dalvik was created. Hint: it has nothing to do with licensing, and everything to do with the performance characteristics of mobile phones.
Did you get past page 3? Unmasked jumps are forbidden by static analysis, so you can't create new code and jump into it. Existing code is verified against whitelisted opcode sets. Segmentation it used to prevent self-modifying code. Tricks that prevent accurate dissasembly are also forbidden by the verifier.
You're making the same mistake I made when I first started working at Google. I tended to assume I was smarter than average, and there, it just isn't true. Google engineers aren't perfect but 99% of the time, when I've looked at some colleagues work and thought "that looks really stupid", it turned out to have a really good reason.
Case in point, why does Android use a custom Java ISA instead of native code? I thought that was so dumb! On a mobile device performance is at a premium and interpreting code just seemed like a massive battery and performance sink. And it is. But I forgot something crucial - RAM is expensive on mobile device, and the Dalvik VM is extremely compact and optimized for minimal memory usage.
In this case, you haven't read the paper. Jumping into the middle of instructions is forbidden by the alignment rules, which are enforced by a small but extremely fast static verifier.
What's more, any other attacks you can think of have likely been considered already. The NativeClient team ran extensive fuzz tests against their implementation, fuzz tests sophisticated enough to detect several CPU bugs (!) and all of them have been sealed. The people behind this have extensive track records in the security community and speak the x86 ISA fluently.
That doesn't mean there won't be faults or mistakes. It does mean you should not underestimate this software.
I used to think Jazelle meant actual Java bytecode execution on the chip, until I talked to an Android developer about it. It turns out that Jazelle is quite incomplete and traps out to native code quite frequently ... for instance, to call a method.
That said, so what? You already have to write special web pages for mobile devices if you want a truly great user experience. The performance/power profiles of mobile devices are so radically differen to desktops that being unable to run x86 code natively isn't a big deal ... even if there was some kind of hardware neutral IL you still wouldn't want to use it on mobiles, for the same reason mobile browsers don't download and run WebStart applets.
Holy crap. AKAImBatman I usually enjoy your posts, but it's painfully clear nobody on this thread - including you - has actually read the paper.
If you had, you'd see that this system is secure. It's simple yet clever at the same time. By using a combination of x86 segmentation (which ironically you say is never used anymore!), alignment rules, static analysis and - crucially - masked jumps, it's possible to ensure that native code cannot synthesize unverified code in memory and then jump into it. If you can prevent arbitrary code synthesis, you can control what the program does. It's as simple as that.
Even though the verifier for this system is microscopic (compared to, say, a JVM), and so much more likely to be correct, NativeClient also includes a ptrace sandbox to provide an additional redundant level of protection.
I don't blame you, because until I read the paper I also believed this. Once you read it you'll slap your forehead and say, my god, it's so simple. Why didn't I think of that?
For what it's worth, nearly any large, professionally written high performance codebase is done in C++ these days. Consider programs like the Unreal Engine, the Google search engine, Firefox, any 3D video game ... all written in object-oriented modern C++.
If you want to work on interesting codebases in a job, I'd definitely master C++. It covers a few different ways of programming, but if you know C++, one scripting language (eg Python) and one functional language (no need for lots of depth), you've got a good foundation as a programmer. I'd note that if you learn C++ Java is simply a matter of getting familiar with the libraries - it's largely a subset of C++.
I love this game. I like the approach they took here as well - I guess it'd have been too expensive to produce fully textured city levels like in the game, so they just went ahead and produced textureless levels, but lots of them. Looking forward to tryint it out.
Do you have any data to back that up? It's not for SecuRom but the data UbiSoft published about StarForce strongly suggests that the level of DRM related problems, even with very aggressive implementations, is low. As in sub-1% low. I'm really sceptical that even 1% of this 1 million+ figure is people downloading it "because they had to" after buying it. Occams Razor says the simplest explanation wins - those people are pirates.
That's a pretty strong assertion. Last time I looked, you had to mod your xbox, which required - in the best case - special equipment and an Xbox of the right generation. And then you risk getting your console banned from Live if you ever let it connect again.
That's not quite true actually. Microsoft measured the overhead of doing page table translations and kernel mode switching at about 30%. Running things in isolated address spaces is quite expensive, it turns out, even with dedicated hardware support.
I think you lost a lot of credibility when you called a contributor to the WiFi and Ethernet specs an "industry mouthpiece".
The problem is the phrasing. I can easily pull down 1Mbps for several hours at a time every so often and not run anywhere close to my cap, but I know if I did that 24/7 I would hit it. So what does "constant" mean? And why is it clearer to explain it that way than just state peak bandwidth and total cap?
Consider doing such a transfer trans-Atlantic when there's a temporary loss of capacity due to (say) a ships anchor cutting a fibre route. Suddenly your connection is congested although your ISP has not been overselling you - there's just been a loss of capacity on the network and now the backoff features no longer work. So instead of stuff just getting slower the whole system starts to break. That's what the author of TFA is afraid of - whether the actual implementation in uTorrent will do this, I can't say, but it sounds plausible.
The big numbers aren't imaginary, they're what you can use at burst speeds. Unless you consider any use of overcommit to result in "imaginary numbers" in which case water, gas, electricity, also sell you imaginary things.
Eh? It's BitTorrent that abuses the internet and Sandvine that tries to stop that abuse! Really BitTorrent is the most inefficient way of distributing files you could possibly design. It has one, and only one, reason for existance - it lets its users externalize bandwidth costs that they should be paying onto everybody else. There are no legitimate uses of this technology, anybody who legitimately needs to distribute huge files to lots of people can use CDNs like the mirror network or Akamai, and then set their cache headers correctly. Otherwise every time somebody distributes a big file with BitTorrent, they effectively make everyone on the internet pay for that bandwidth instead of themselves.
Your argument is sort of like a factory saying, hey, we're only dumping our toxic waste onto the roads because when we dumped it into the rivers the rivers authority got on our backs.
If an ISP is actually lying about what they sell, take them to court for contract violation. But I doubt you can actually do that because I doubt any ISP is stupid enough to actually sell unlimited internet. Always, in the contract you sign there will be fine print. In which case it's not lying, is it?