Sorry I can't help, but I can comment that your issue is one of the reasons I like doing side games judy for fun. Whether it be a missile command clone, a scrolling shoot'em'up, or a lunar lander game, it's just simple and straight-forward fun. When my kids ask if they can play the game that Daddy created, I have no qualms about letting them have at-it. In fact, they're my little Beta-testers. I watch how they play and make adjustments where they have troubles.
The buggers get pretty good at it, too. I once left my 6 yr. old son playing my lunar lander game (one of the harder games I'd devised) while I took care of business elsewhere in the house. When I left him, he was having a lot of trouble getting past the third level. Obviously, he had slammed headlong into the difficulty curve. I come back an hour later to find that he'd made it to the 8th and final level! (A *really* hard level that was intended to give players a conniption fit.) If we didn't have to go then, I have little doubt he would have found a way to beat it! Impressive little bugger.
That's great. When you graduate beyond armchair reading, perhaps you might consider getting out of your chair and learning about actually designing an Operating System? It's a very rewarding experience and teaches one about all the wonderful spagetti and legacy problems inherent in designs like Unix. It even shows how the greater resources present in modern computers can be utilized to reduce or eliminate the problems exhibited by previous OSes.
develop your own operating system based on Linux and get it over with.
No offense to Linux, but I think that would offend Google's sense of style. Unix-style OSes are great when you need low-level access to the hardware (e.g. GoogleFS), but don't infer any sort of inherent advantage in the desktop arena. In fact, the classic Unix design is very desktop unfriendly, which is why all kinds of user-friendly packages like automounter have been created.
Given the number of Ph.D. brainiacs Google has their hands on, I would expect them to create a new OS from the ground up that is more focused on the issues of dealing with the web and network in general. e.g. If it can be coded to avoid buffer overflow situations, that would be a great start. Greater focus on caching services and integrated URL handling might also be things you would see more of. Unicode everything rather than dealing with different text formats. (Incoming formats would need to be converted before they could be used.) Overall minimalist design. i.e. Don't include anything that isn't absolutely necessary to getting the job done. (Compare: The number of features on Google homepage to the number of features on the average Linux desktop.)
I will happily eat crow if Google ever produces a Linux desktop, but gut instinct says that they won't. So don't get your hopes up.
Sorry, "The UCC specifically extends copyright law" should read "The UCC specifically extends contract law". Wasn't minding my P's and Q's like I should.;-)
I'm sure something as important as the validation of shrinkwrap licenses would have made it to Slashdot by now...
I'm quite sure you meant to say "clickwrap" licenses, which have never been validated by a court. (But are generally held to be enforceable because of shrinkwrap licenses.) Shrinkwrap and Boxwrap licenses are covered by the Uniform Commercial Code laws and were validated by the ProCD v. Zeidenberg case.
The UCC specifically extends copyright law to allow agreements to be made quickly in cases where signing a physical contract would be prohibitive to the transaction. Originally conceived for markets like retail (you may occasionally find license agreements as a separate slip or in the manuals of retail products), the concept was extended to the computer market where shrinkwrapped software is sold like any other retail product.
Legally, a backup is different from a space-shifted copy. A backup for "archival purposes" as defined by copyright law is to protect against media failure. In the Atari v. JS&A case, the court referred to the original report that Congress used to draft the archival exception. The report had focused on the volatility of magnetic media as a key concern, and pointed out that copying of software could be done for nearly no cost in comparison to the huge cost of developing the software. Since cartridges could not be cheaply copied, nor were they at risk of failure, the court decided that a backup was unnecessary.
The court *might* have found JS&A's cartridge copier legal if there was a substantial use for it beyond piracy. JS&A tried to publish 9 of its own carts that were free for copying, but the judge didn't buy it. The decision was that there was no fair use argument for the device.
Now copying your cartridges for emulation is a different ball of wax. Just as you can legally space shift your music into MP3s, you should be able to space shift your ROMs into images for emulators. The roots of this definition of fair use come from the Sony Corp. of America v. Universal City Studios, Inc. case, also known as the "Betamax case". The Supreme Court later held that the betamax case applied to space shifting of MP3 players, CD burners, and other new technologies in the MGM v. Grokster case. (In applying the test, they found that Grokster was NOT a party to that standard and was intentionally trying to circumvent copyright law.)
These cases should pave the way for emulation to be legal. However, there is a catch 22. In order to space-shift your legally-owned games, you must rip the image yourself. If you download the games from a ROM site, you are in violation of copyright law. Ergo, 95%+ of people who use emulators to play games they own are actually violating the law.
And now you know... the rest of the story. Good day! </Paul-Harvey>
Making a copy for use and keeping the original as a backup is legal.
This is not strictly true. The decision in the Atari v. JS&A case was that cartridges were not susceptible to accidental damage in the same way that magnetic media was. As a result, there was no need for an archival copy of the software.
A modern judge might see things different given the age of many cartridges, but you should be aware that they are currently NOT covered under the "archival" clause. (Now if only Nintendo would figure out that CDs/DVDs *are* volatile media and stop printing that stupid "backups are not authorized" warning in their manuals.)
This is because the Nintendo titles have greater mass appeal than the Genesis/TurboGrafx titles. That does NOT mean that the Genesis/TurboGrafx titles are doing poorly. In fact, Hudson originally announced only 5 TG-16 titles destined for the Virtual Console. Since then they've expanded the list to some of the best titles ever made for the system. This includes: Bomberman '93, R-Type, Military Madness, Bonk's Adventure, Bonk's Revenge, and Blazing Lazers.
While Nintendo and their partners have been keeping hush-hush on a lot of the VC sales data, Hudson's strong support for the VC certainly suggests that they've been having good success with the service. Sega seems to be becoming similarly infatuated with the service.
It's also interesting to note that there hasn't been a strong Nintendo title released for the VC since Starfox 64.
I bet the top ten are as well.
I'm not sure I would be so quick to say that. Nintendo's games will always dominate simply because they dominated back in the day. (e.g. 3 of my 6 VC games are Nintendo titles.) But that doesn't mean that the third parties aren't doing exceptionally well. Sonic, for example, was exceptionally popular back in the day. I would be surprised if it wasn't on a top 10 list.
When 3rd party titles dominate the top 5, THEN we can say they have good 3rd party support.
That, I'm afraid, will never happen. The customers are Nintendo players downloading titles on a Nintendo system, and have fond memories of playing Nintendo games. Combined with the timeless reputation of some of their games, Nintendo's classics library cannot be beat. As I said, though, this does not mean that third parties aren't seeing wonderful sales through the VC.
Anecdotally, I have heard a lot of excitement from friends/acquaintances over TG16 and Genesis titles. (Though the 600 points for TMNT got a big 'WTF?') The only catch is that there's more of a spread between which titles they're interested in. Some like shooters, some like beat'em'ups, and some like platformers. Nintendo's appeal tends to be more universal.
I'm one of those morons who ditched their old consoles with the advent of each new one. Now, Nintendo, Sega and the rest get to sell me nostalgia at top dollar.
I have 8 to 10 classic game consoles at home, and yet I have purchased about 6 games from the Virtual Console. There are a variety of reasons for this:
Convenience - It's a lot easier to boot the Wii and play a quick NES title than it is to pull out the classic console (which you lovingly repaired the pins), snake the cables behind the furniture, and hook it up to the television.
Availability - I never had a Sega Genesis, nor have I ever felt the need to own one. The system didn't have much in the way of lasting appeal, but it did have Sonic. Now that I can purchase Sonic from the Virtual Console, I have even less reason to own a Genesis.
Price - Believe it or not, TurboGrafix systems and games are not that cheap in the wild. $8 a pop is a pretty good deal for many of these games. Especially uncommon cult classics like Military Madness and Blazing Lasers. If the rumors of Nintendo adding Neo-Geo games turn out to be true, the value of the Virtual Console games will go through the roof! (Neo-Geo carts still cost upwards of $30 used.)
Storage - I try to keep my games and systems neatly organized. Playing games on the VC allows me to do less to disturb that order, and can even save me storage space for titles that I don't necessarily want to invest in physical copies of.
Authenticity - Playing games on the Virtual Console feels much closer to playing them on the original system than playing them on an emulator does. Nintendo seems to make an effort to replicate the experience as closely as possible. The NES-style controls of the Wii Remote and SuperNES/Playstation feel of the Classic Controller help heighten that sense of authenticity.
Nintendo may not have the most original idea with their VC service, but they've struck gold in terms of its implementation.:)
The only way they're going to get more of that is if the third party games actually sell.
What are you talking about? Some of the biggest VC sellers are for the Sega Genesis and the TurboGrafx. Are you seriously suggesting that Nintendo produced those titles?
Mac OS X also has Java bundled into the OS, and the Opera download provided an option to include Java until recently. So Sun still has fairly good market penetration. Adobe has a nice chart showing both Flash and Java penetration here: http://www.adobe.com/products/player_census/flashp layer/
There's so much more to whether it works or not that your statement is absurd. There's difficulty, feasibility, detectibility, reproducibility...
True. However, these are not particularly sophisiticated attacks. They assume that a privledge elevation exploit already exists. If one exists, then reflashing the BIOS and/or executing PCI-BIOS commands are straightforward and well-documented. Anyone who has done system-level coding could pull it off without needing to question if it's even possible. Reading through the attacks, they ring true with my experience in system-level coding. There's nothing that would cause me to question how feasible it is. The only issue is how much space is available on the ROM chips. Particularly the main BIOS chip. More on how that can be circumvented below.
Also, without trying to be pedantic, this is the first time you've referenced anyone besides the guy who wrote the papers, yet you claimed that security researchers consider it a real threat.
A fair point. I did reference the specific document in my first post, but looking back I only attributed the methods of attack.
Some malware dynamically patches the kernel at runtime. So if you access settings on the hard disk or flash drive at all (and how could you not?) the malware can simply install itself after you boot. I inferred that you meant that simply having a hard disk in the machine was all that was required. In fact, you said as much: "Just" having the hard drive available will do nicely.
That is all that's needed. I was providing a straightforward example in line with my original assertion of "if the computer stores settings on the disk". There are quite a few more scenarios:
Scenario 1: Disk is mounted, but only settings for user applications (e.g. Firefox) are stored. Exploit: Firefox allows for user extensions to be installed into the settings directory. An attacker could install an extension that runs the kernel-patching exploit each time Firefox is started.
Scenario 2: Disk is mounted, but no settings are stored. Only self-contained files (e.g. documents, photos, music, etc.) are stored on the disk. Live CD has features which allow it to pull extra programs from disk, but they are not used. Exploit: Install the directory structure that the Live CD expects. Make the rootkit one of the packages that gets loaded and executed on startup.
Scenario 3: Hard drive is mounted, but no settings are stored. Only self-contained files (e.g. documents, photos, music, etc.) are stored on the disk. Live CD is locked down to prevent disk loads. Exploit: The attacking rootkit saves a copy of the malicious code to the disk and installs a small bootloader into the BIOS. This bootloader loads a hypervisor or rootkit from disk and begins execution. The malicious code then loads the kernel from CDROM as if nothing was wrong, but takes pains to modify the kernel before executing it.
Scenario 4:Hard drive is mounted, but no settings are stored. Only self-contained files (e.g. documents, photos, music, etc.) are stored on the disk. BIOS is jumpered to prevent undesirable reflashing. Exploit: The attacking rootkit saves a copy of the malicious code to the disk and installs a small piece of code into a PCI ROM Chip. For this example, let's say that it's a video card. When the system loads the video BIOS, it also loads the malicious program. Once executed through a video vector (e.g. Protected mode VESA) the program attempts to load the kernel patch from disk and execute it.
Obviously, these attacks grow in sophisitication with each layer of security added. The greater the sophistication, the more likely it is to only be targetable to a small cross-section of users. However, the original concern I raised was that these rootkits are being installed through vectors that cannot be protected against. (e.g. rogue employee, stolen passw
Nor does the consumer sign any contract with regard to use of GPL software.
First off, "wrap" agreements have been legally accepted by courts for a long time. So including a license with your software is technically binding if the software is used.
That being said, you are not bound by the GPL. Read it sometime. It explicitly says you're not bound by it. The only time you're bound by it is if you want the redistrubtion rights that copyright law does not offer. Without the GPL, you cannot redistribute the software. So redistribution is either an implicit agreement to the terms or a violation of copyright law. Take your pick.
Maybe MLB is just informing its viewers of the law (so they can't claim ignorance), or perhaps they are stretching the law through a questionable interpretation.
Courts have already thrown out arguments against time shifting and space shifting. This is just another form of space shifting. Plus the FCC provides that anything sent over the airwaves cannot be restricted. If it's on the airwaves, it's public property. That doesn't mean that you can redistribute the material (that's where copyright law kicks in), but the airwaves are a single instance of a free distribution to all.
Long story short: MLB doesn't have a legal leg to stand on.
One person is concerned with these exploits, and he has an agenda (getting published).
If the exploit works, it works. Pure and simple. His papers are referenced by other security researchers (which is how I found out about them) who mention BIOS exploits. By your logic, all researchers are "just looking to get published" whether they advance their field or not.
Can you give an example of how the data in your settings which is set by an executable shell script is going to compromise my machine unless there is a vulnerability in the shell script?
The simplest example is a.bashrc file. Login with your username, and it executes out of your home directory. If that directory is mounted as a persistent data storage, the exploit will be able to add itself to the resource file and get executed. Same thing with the X Resource file, and dozens of other user-modifiable files. If a/etc directory is saved to disk then combined at runtime (there's a special Linux FS for that who's name I forget), then the exploit can use that to add itself to the startup scripts.
Obviously, these items are more detectable than a persistent patched kernel, but not so detectable as to be obvious.
Also, I made another post right below this one that contained a link to a paper he did on storing extra code in the PCI cards themselves.
storing settings, which are data isn't going to recompromise the system unless there is a vulnerability in the software which reads and uses that data.
Q: How are settings loaded under Unix systems? A: Executable Shell Scripts.
"Just" having the hard drive available will do nicely.
Major League Baseball is going against the grain by saying that Slingbox owners who stream home games while traveling are breaking the law because it allows consumers to circumvent geographical boundaries written in to broadcast deals.
Why should consumers abide by or even care about an agreement between the MLB and the broadcaster? The consumer didn't sign any contracts to "only watch baseball in approved geographical regions." And in any case, the user obviously has a presence in the necessary region in order to use SlingBox in the first place.
If the system has no hard disk, explain me where your hypothetical, urban legendary, hypervisor rootkit would reside? I seriously hope you're not implying the BIOS hold enough room to contain an hypervisor rootkit (come take a look at an hypervisor like Xen to see what I'm talking about).
I just spent a few minutes reading this paper from the same fellow who introduced BIOS rootkits. It's quite interesting:
Many PCI cards contain an expansion ROM that holds additional code required to initialise the card during execution of the system BIOS. This code is also responsible for carrying out the device-specific self-test and hooking required interrupts. The presence of an expansion ROM is determined via the Expansion ROM Base Address Register within the PCI function's Configuration Header.
It is worth noting that the expansion ROM does not necessarily hold x86 code nor does it have to contain a single ROM image. The code type field within the ROM data structure within the image specifies the presence of x86 code or OpenBoot interpretive code (documented in the Open Firmware standard).
The expansion ROM is stored on either an EPROM, or more commonly on an EEPROM. EPROMs require that the chip is removed from the card and erased via exposing it to strong ultraviolet light before it can be reprogrammed. EEPROMs, however, can be erased electrically, in-circuit, thus the card need not be removed from the system and can be re-flashed from the operating system.
In order to perform this, the user must have the SeTcbPrivilege and call the undocumented Native API function, NtSetInformationProcess with a process information class of ProcessUserModeIOPL. Once the user can perform unrestricted I/O, they can potentially re-flash the card without having to load a driver.
This raises the possibility of (1) a remote attack that yields LocalSystem privilege (such as the server service vulnerability patched in update MS06-040) being used to deploy a malicious expansion ROM, (2) a browser exploit, that, if the user is running under the administrative context, obtains SeTcbPrivilege and re-flashes a card.
The paper goes on to explain the *exact* steps necessary to implement such a rootkit. Ouch.
Last time I checked I could pass some "toram" parameter to a lot of Live CDs, making the system run perfectly fine, entirely in memory, on my old P4 / 1 GB of ram.
This is a possibility, but you're assuming that the system contains enough RAM to store all the necessary applications and datasets for the operation of the computer. Your anecdote does not prove that every machine can afford to load a complete OS into memory.
I seriously doubt that, today, a BIOS malware could be sufficiently advanced to act as a real root-kit.
Like it or not, security researchers consider it a real threat.
And you explain me how you remotely install a BIOS on a system that requires changing a jumper before you can flash the BIOS.
If you have a physical block in place, then one would think that you should be safe. Not all systems have this jumper, or have it set to prevent flashing by default. Also, an attacker with physical access could change the jumper setting. (See my original post above.)
Remember that you were replying to someone talking about running a system of a live CD. If the system has no hard disk, explain me where your hypothetical, urban legendary, hypervisor rootkit would reside?
If you were paying attention, I addressed that issue. If the computer stores settings anywhere (either a hard drive OR removable flash drive), then it is vulnerable. And let's be honest. How many users are going to create a new system layout and reburn it every time they want to change their system? Unless we're talking about an appliance device, not many.
Maybe a rootkit author could bypass all of these, but I doubt - seriously doubt - that it would be a trivial weekend exercise to bypass Trusted Computing or strong authentication/validation mechanisms.
Step 1: Analyze NVidia or ATI graphics driver for buffer overflows or similar security issues.
Step 2: Construct an OpenGL call to exploit the issue and create an easy access point into the kernel.
Step 3: Use new access point to patch the kernel or BIOS code.
Step 4: Close the doors and clean up the mess so that there is no evidence of tampering. Just a regular kernel running regular modules and processes. No one knows that the kernel has actually been modified.
Step 5: ??? (Contact foreign terrorists? Skim partial pennies into a swiss bank account? Use for DDoS operations?)
Step 6: Profit!
Note that this potentially works for modules other than graphics modules. It's just that they're the most complex and therefore easier to exploit.
Have the compiler randomize the kernel's ABI. Totally. Absolutely zero predictability in how parameters are passed. The compiler just needs to make sure ALL calls to a specific function call that function the same way, whether the object is linked in or compiled as a module.
Two problems:
1. This would make binary modules impossible.
2. The current ABI must be documented in a machine-readable form somewhere on the system. The rootkit installer can modify the patch before installing it. Worst case, it can compile source code into a pristine binary that is compatible. (Since you'd be required to have a compiler on your system.)
And what do you do if you need your CD-ROM drive back? Also, some forms of malware install at the BIOS/hypervisor level. You can't even *detect* that from inside the OS! Some malware dynamically patches the kernel at runtime. So if you access settings on the hard disk or flash drive at all (and how could you not?) the malware can simply install itself after you boot.
The big question is how this malware gets there in the first place. The "towards verifiable systems" presentation linked to from the article listed such options as users who run attachments (merde), malicious employees who intentionally install kits (!), and use of a stolen password. These are all problems that can't be stopped, only mitigated. A malicious employee with physical access to a machine has everything they need, and you can't stop them. You can mitigate the problem by checking for things like tampering with the case and BIOS resets (to clear the password), but these are not foolproof solutions. Same with a stolen password. If you don't know its stolen, a window will always exist in which it can be used.
It *is* possible to build technology that does not suffer from trivial problems like buffer overflows, but you can't stop someone who has clear access to a machine. Authority is authority, and there will always be methods to steal and/or abuse that authority over a machine.
Having actually read the article, it's more like this: Video portrays latest hotshot in the classic gaming scene as a hero who's being put down by the old guard. In the process, it portrays the older gamers as being petty in an attempt to suppress the rightful crowning of the new hotshot. The old guard replies that they did nothing to suppress the young hotshot, and that his problems stem from a failure to adhere to the rules of gaming championships. (e.g. His Donkey Kong machine was a later twin-board system for playing both DK and DKjr rather than an original DK machine that the rules call for.) Young hotshot thinks that the real case is that the judges and other gamers want to protect the scores of the older gamer. Media circus ensues.
If you read my link, it says, "Additionally, the team is working on supporting Safari on Mac OS X in a future release."
So support for Safari is promised, though on what a timetable is unknown. And while the Javascript might currently support Safari (which is good defensive programming:)), it needs an actual browser plugin to make this work.
No word on Opera, though someone else in the thread posted a link that says "Opera is receptive". Which may mean that Opera will have to support the API itself if it wants to see its browser supported. (Nothing new there.)
Slashdot Mirror
Sorry I can't help, but I can comment that your issue is one of the reasons I like doing side games judy for fun. Whether it be a missile command clone, a scrolling shoot'em'up, or a lunar lander game, it's just simple and straight-forward fun. When my kids ask if they can play the game that Daddy created, I have no qualms about letting them have at-it. In fact, they're my little Beta-testers. I watch how they play and make adjustments where they have troubles.
The buggers get pretty good at it, too. I once left my 6 yr. old son playing my lunar lander game (one of the harder games I'd devised) while I took care of business elsewhere in the house. When I left him, he was having a lot of trouble getting past the third level. Obviously, he had slammed headlong into the difficulty curve. I come back an hour later to find that he'd made it to the 8th and final level! (A *really* hard level that was intended to give players a conniption fit.) If we didn't have to go then, I have little doubt he would have found a way to beat it! Impressive little bugger.
That's great. When you graduate beyond armchair reading, perhaps you might consider getting out of your chair and learning about actually designing an Operating System? It's a very rewarding experience and teaches one about all the wonderful spagetti and legacy problems inherent in designs like Unix. It even shows how the greater resources present in modern computers can be utilized to reduce or eliminate the problems exhibited by previous OSes.
No offense to Linux, but I think that would offend Google's sense of style. Unix-style OSes are great when you need low-level access to the hardware (e.g. GoogleFS), but don't infer any sort of inherent advantage in the desktop arena. In fact, the classic Unix design is very desktop unfriendly, which is why all kinds of user-friendly packages like automounter have been created.
Given the number of Ph.D. brainiacs Google has their hands on, I would expect them to create a new OS from the ground up that is more focused on the issues of dealing with the web and network in general. e.g. If it can be coded to avoid buffer overflow situations, that would be a great start. Greater focus on caching services and integrated URL handling might also be things you would see more of. Unicode everything rather than dealing with different text formats. (Incoming formats would need to be converted before they could be used.) Overall minimalist design. i.e. Don't include anything that isn't absolutely necessary to getting the job done. (Compare: The number of features on Google homepage to the number of features on the average Linux desktop.)
I will happily eat crow if Google ever produces a Linux desktop, but gut instinct says that they won't. So don't get your hopes up.
Sorry, "The UCC specifically extends copyright law" should read "The UCC specifically extends contract law". Wasn't minding my P's and Q's like I should. ;-)
I'm quite sure you meant to say "clickwrap" licenses, which have never been validated by a court. (But are generally held to be enforceable because of shrinkwrap licenses.) Shrinkwrap and Boxwrap licenses are covered by the Uniform Commercial Code laws and were validated by the ProCD v. Zeidenberg case.
The UCC specifically extends copyright law to allow agreements to be made quickly in cases where signing a physical contract would be prohibitive to the transaction. Originally conceived for markets like retail (you may occasionally find license agreements as a separate slip or in the manuals of retail products), the concept was extended to the computer market where shrinkwrapped software is sold like any other retail product.
Legally, a backup is different from a space-shifted copy. A backup for "archival purposes" as defined by copyright law is to protect against media failure. In the Atari v. JS&A case, the court referred to the original report that Congress used to draft the archival exception. The report had focused on the volatility of magnetic media as a key concern, and pointed out that copying of software could be done for nearly no cost in comparison to the huge cost of developing the software. Since cartridges could not be cheaply copied, nor were they at risk of failure, the court decided that a backup was unnecessary.
The court *might* have found JS&A's cartridge copier legal if there was a substantial use for it beyond piracy. JS&A tried to publish 9 of its own carts that were free for copying, but the judge didn't buy it. The decision was that there was no fair use argument for the device.
Now copying your cartridges for emulation is a different ball of wax. Just as you can legally space shift your music into MP3s, you should be able to space shift your ROMs into images for emulators. The roots of this definition of fair use come from the Sony Corp. of America v. Universal City Studios, Inc. case, also known as the "Betamax case". The Supreme Court later held that the betamax case applied to space shifting of MP3 players, CD burners, and other new technologies in the MGM v. Grokster case. (In applying the test, they found that Grokster was NOT a party to that standard and was intentionally trying to circumvent copyright law.)
These cases should pave the way for emulation to be legal. However, there is a catch 22. In order to space-shift your legally-owned games, you must rip the image yourself. If you download the games from a ROM site, you are in violation of copyright law. Ergo, 95%+ of people who use emulators to play games they own are actually violating the law.
And now you know... the rest of the story. Good day! </Paul-Harvey>
Let me sum up my disagreement in a single line:
"Go Microsoft! Rah, rah, rah! If you can't beat them no one can!"
Ugh. I feel dirty now.
This is not strictly true. The decision in the Atari v. JS&A case was that cartridges were not susceptible to accidental damage in the same way that magnetic media was. As a result, there was no need for an archival copy of the software.
A modern judge might see things different given the age of many cartridges, but you should be aware that they are currently NOT covered under the "archival" clause. (Now if only Nintendo would figure out that CDs/DVDs *are* volatile media and stop printing that stupid "backups are not authorized" warning in their manuals.)
This is because the Nintendo titles have greater mass appeal than the Genesis/TurboGrafx titles. That does NOT mean that the Genesis/TurboGrafx titles are doing poorly. In fact, Hudson originally announced only 5 TG-16 titles destined for the Virtual Console. Since then they've expanded the list to some of the best titles ever made for the system. This includes: Bomberman '93, R-Type, Military Madness, Bonk's Adventure, Bonk's Revenge, and Blazing Lazers.
While Nintendo and their partners have been keeping hush-hush on a lot of the VC sales data, Hudson's strong support for the VC certainly suggests that they've been having good success with the service. Sega seems to be becoming similarly infatuated with the service.
It's also interesting to note that there hasn't been a strong Nintendo title released for the VC since Starfox 64.
I'm not sure I would be so quick to say that. Nintendo's games will always dominate simply because they dominated back in the day. (e.g. 3 of my 6 VC games are Nintendo titles.) But that doesn't mean that the third parties aren't doing exceptionally well. Sonic, for example, was exceptionally popular back in the day. I would be surprised if it wasn't on a top 10 list.
That, I'm afraid, will never happen. The customers are Nintendo players downloading titles on a Nintendo system, and have fond memories of playing Nintendo games. Combined with the timeless reputation of some of their games, Nintendo's classics library cannot be beat. As I said, though, this does not mean that third parties aren't seeing wonderful sales through the VC.
Anecdotally, I have heard a lot of excitement from friends/acquaintances over TG16 and Genesis titles. (Though the 600 points for TMNT got a big 'WTF?') The only catch is that there's more of a spread between which titles they're interested in. Some like shooters, some like beat'em'ups, and some like platformers. Nintendo's appeal tends to be more universal.
I have 8 to 10 classic game consoles at home, and yet I have purchased about 6 games from the Virtual Console. There are a variety of reasons for this:
Nintendo may not have the most original idea with their VC service, but they've struck gold in terms of its implementation.
What are you talking about? Some of the biggest VC sellers are for the Sega Genesis and the TurboGrafx. Are you seriously suggesting that Nintendo produced those titles?
And thank you for keeping it civil and on topic. :-)
OEMs started shipping Java around the time that Microsoft stopped:
p layer/
http://news.zdnet.com/2100-3513_22-1015723.html
So it does show up on a lot of PCs.
Mac OS X also has Java bundled into the OS, and the Opera download provided an option to include Java until recently. So Sun still has fairly good market penetration. Adobe has a nice chart showing both Flash and Java penetration here: http://www.adobe.com/products/player_census/flash
True. However, these are not particularly sophisiticated attacks. They assume that a privledge elevation exploit already exists. If one exists, then reflashing the BIOS and/or executing PCI-BIOS commands are straightforward and well-documented. Anyone who has done system-level coding could pull it off without needing to question if it's even possible. Reading through the attacks, they ring true with my experience in system-level coding. There's nothing that would cause me to question how feasible it is. The only issue is how much space is available on the ROM chips. Particularly the main BIOS chip. More on how that can be circumvented below.
A fair point. I did reference the specific document in my first post, but looking back I only attributed the methods of attack.
That is all that's needed. I was providing a straightforward example in line with my original assertion of "if the computer stores settings on the disk". There are quite a few more scenarios:
Scenario 1: Disk is mounted, but only settings for user applications (e.g. Firefox) are stored.
Exploit: Firefox allows for user extensions to be installed into the settings directory. An attacker could install an extension that runs the kernel-patching exploit each time Firefox is started.
Scenario 2: Disk is mounted, but no settings are stored. Only self-contained files (e.g. documents, photos, music, etc.) are stored on the disk. Live CD has features which allow it to pull extra programs from disk, but they are not used.
Exploit: Install the directory structure that the Live CD expects. Make the rootkit one of the packages that gets loaded and executed on startup.
Scenario 3: Hard drive is mounted, but no settings are stored. Only self-contained files (e.g. documents, photos, music, etc.) are stored on the disk. Live CD is locked down to prevent disk loads.
Exploit: The attacking rootkit saves a copy of the malicious code to the disk and installs a small bootloader into the BIOS. This bootloader loads a hypervisor or rootkit from disk and begins execution. The malicious code then loads the kernel from CDROM as if nothing was wrong, but takes pains to modify the kernel before executing it.
Scenario 4:Hard drive is mounted, but no settings are stored. Only self-contained files (e.g. documents, photos, music, etc.) are stored on the disk. BIOS is jumpered to prevent undesirable reflashing.
Exploit: The attacking rootkit saves a copy of the malicious code to the disk and installs a small piece of code into a PCI ROM Chip. For this example, let's say that it's a video card. When the system loads the video BIOS, it also loads the malicious program. Once executed through a video vector (e.g. Protected mode VESA) the program attempts to load the kernel patch from disk and execute it.
Obviously, these attacks grow in sophisitication with each layer of security added. The greater the sophistication, the more likely it is to only be targetable to a small cross-section of users. However, the original concern I raised was that these rootkits are being installed through vectors that cannot be protected against. (e.g. rogue employee, stolen passw
First off, "wrap" agreements have been legally accepted by courts for a long time. So including a license with your software is technically binding if the software is used.
That being said, you are not bound by the GPL. Read it sometime. It explicitly says you're not bound by it. The only time you're bound by it is if you want the redistrubtion rights that copyright law does not offer. Without the GPL, you cannot redistribute the software. So redistribution is either an implicit agreement to the terms or a violation of copyright law. Take your pick.
Courts have already thrown out arguments against time shifting and space shifting. This is just another form of space shifting. Plus the FCC provides that anything sent over the airwaves cannot be restricted. If it's on the airwaves, it's public property. That doesn't mean that you can redistribute the material (that's where copyright law kicks in), but the airwaves are a single instance of a free distribution to all.
Long story short: MLB doesn't have a legal leg to stand on.
If the exploit works, it works. Pure and simple. His papers are referenced by other security researchers (which is how I found out about them) who mention BIOS exploits. By your logic, all researchers are "just looking to get published" whether they advance their field or not.
The simplest example is a
Obviously, these items are more detectable than a persistent patched kernel, but not so detectable as to be obvious.
His full paper on the matter is here: https://www.blackhat.com/presentations/bh-federal
Also, I made another post right below this one that contained a link to a paper he did on storing extra code in the PCI cards themselves.
Q: How are settings loaded under Unix systems?
A: Executable Shell Scripts.
"Just" having the hard drive available will do nicely.
Why should consumers abide by or even care about an agreement between the MLB and the broadcaster? The consumer didn't sign any contracts to "only watch baseball in approved geographical regions." And in any case, the user obviously has a presence in the necessary region in order to use SlingBox in the first place.
I just spent a few minutes reading this paper from the same fellow who introduced BIOS rootkits. It's quite interesting:
The paper goes on to explain the *exact* steps necessary to implement such a rootkit. Ouch.
This is a possibility, but you're assuming that the system contains enough RAM to store all the necessary applications and datasets for the operation of the computer. Your anecdote does not prove that every machine can afford to load a complete OS into memory.
Like it or not, security researchers consider it a real threat.
If you have a physical block in place, then one would think that you should be safe. Not all systems have this jumper, or have it set to prevent flashing by default. Also, an attacker with physical access could change the jumper setting. (See my original post above.)
If you were paying attention, I addressed that issue. If the computer stores settings anywhere (either a hard drive OR removable flash drive), then it is vulnerable. And let's be honest. How many users are going to create a new system layout and reburn it every time they want to change their system? Unless we're talking about an appliance device, not many.
Step 1: Analyze NVidia or ATI graphics driver for buffer overflows or similar security issues.
Step 2: Construct an OpenGL call to exploit the issue and create an easy access point into the kernel.
Step 3: Use new access point to patch the kernel or BIOS code.
Step 4: Close the doors and clean up the mess so that there is no evidence of tampering. Just a regular kernel running regular modules and processes. No one knows that the kernel has actually been modified.
Step 5: ??? (Contact foreign terrorists? Skim partial pennies into a swiss bank account? Use for DDoS operations?)
Step 6: Profit!
Note that this potentially works for modules other than graphics modules. It's just that they're the most complex and therefore easier to exploit.
Two problems:
1. This would make binary modules impossible.
2. The current ABI must be documented in a machine-readable form somewhere on the system. The rootkit installer can modify the patch before installing it. Worst case, it can compile source code into a pristine binary that is compatible. (Since you'd be required to have a compiler on your system.)
And what do you do if you need your CD-ROM drive back? Also, some forms of malware install at the BIOS/hypervisor level. You can't even *detect* that from inside the OS! Some malware dynamically patches the kernel at runtime. So if you access settings on the hard disk or flash drive at all (and how could you not?) the malware can simply install itself after you boot.
The big question is how this malware gets there in the first place. The "towards verifiable systems" presentation linked to from the article listed such options as users who run attachments (merde), malicious employees who intentionally install kits (!), and use of a stolen password. These are all problems that can't be stopped, only mitigated. A malicious employee with physical access to a machine has everything they need, and you can't stop them. You can mitigate the problem by checking for things like tampering with the case and BIOS resets (to clear the password), but these are not foolproof solutions. Same with a stolen password. If you don't know its stolen, a window will always exist in which it can be used.
It *is* possible to build technology that does not suffer from trivial problems like buffer overflows, but you can't stop someone who has clear access to a machine. Authority is authority, and there will always be methods to steal and/or abuse that authority over a machine.
Take lessons from Darth Vader:
http://www.youtube.com/watch?v=psNyK2kOvzY
Having actually read the article, it's more like this: Video portrays latest hotshot in the classic gaming scene as a hero who's being put down by the old guard. In the process, it portrays the older gamers as being petty in an attempt to suppress the rightful crowning of the new hotshot. The old guard replies that they did nothing to suppress the young hotshot, and that his problems stem from a failure to adhere to the rules of gaming championships. (e.g. His Donkey Kong machine was a later twin-board system for playing both DK and DKjr rather than an original DK machine that the rules call for.) Young hotshot thinks that the real case is that the judges and other gamers want to protect the scores of the older gamer. Media circus ensues.
If you read my link, it says, "Additionally, the team is working on supporting Safari on Mac OS X in a future release."
:)), it needs an actual browser plugin to make this work.
So support for Safari is promised, though on what a timetable is unknown. And while the Javascript might currently support Safari (which is good defensive programming
No word on Opera, though someone else in the thread posted a link that says "Opera is receptive". Which may mean that Opera will have to support the API itself if it wants to see its browser supported. (Nothing new there.)