And then the next version of the hack will patch the part of the firmware that deals with the read firmware command (You didn't think the main board has a direct path to the drive firmware did you? The command goes over the SATA bus where it has to be processed by the firmware...) and return the "right" thing...
My mom is actually pretty tech savvy, but I suspect moms that would call and make that confusion would likely call Blu-ray, HD-DVD and even DVD as just "CD".
3 sounds like you had cheap controllers, or cheap switches. I forget which it is. But either way, the system I had in place (Using Switchlinc switches, and a custom script on my computer, forget which open source package I used) didn't have that problem.
I didn't have the X10 crap, I shelled out $$ for some high quality X-10 protocol light switches. In addition to all the fancy schmancy features, they would remember if they were on or off when the power failed, and would return to that state when the power came back.
But like everyone else, the flakiness of the X-10 protocol eventually got too much for me and I ditched the whole thing when I moved. Once I buy a house I may look at the current options again, like Insteon.
CRC is about detecting errors, not so much about correcting them. Error correction, on the other hand, is half science, half art form. Part of error correction is knowing the failure pattern of the media in question. Knowing how related bits will fail allows the bits for a group of correctable data to be spread out across areas that aren't linked.
Eh, I was ready to avoid them as soon as I read on that page that they redefined RAID as "Reliable and inexpensive disk". I'm not sure I'm clear on exactly how that is different than "Redundant Array of Inexpensive Disks". It doesn't sound more clever, and it says the same thing. Except by saying the same thing, it says that they don't know what they are talking about.
Random idea on how to deal with credit card applications...
I kept seeing people talking about "why should I have to deal with it when it's not my problem?"
Well... Why not make it THEIR problem. Just take the blank application, stick it into the postage paid envelope (Tear off half of any identifying information if you wish - half so they don't have it all, and when you trash it, someone who picks through it doesn't have it all) and mail it back to them? Bam, not in your trash to be recovered, it's now their problem.
Because software has bugs, and BIOS is software just like anything else. BIOS contains the CPU microcode which comes out with updates sometimes. (Microcode isn't flashed like BIOS is... A microcode update has to be loaded every poweron.)
Support for new CPUs that didn't exist but are perfectly compatible with the chipset.
The BIOS does more than just load the OS. It sets up the chipset as well. Some of it in ways that the OS can't do anything about easily. There are a number of settings in the chipset and CPU that require a reset to take effect, so your computer likely resets a couple times before you even see the BIOS screen.
All of this has to be done by the BIOS, and if theres a bug in any of it, you need to update the BIOS.
I thought of that... But it's actually even easier to detect TSC drift. Especially in dual core machines.
For single core, any reliable time source would do. The CPU clock runs at a fixed frequency. So within 1 tick of the external timesource you'd be able to easily notice the drift. Especially if you spend the entire time doing priveleged instructions.
For dual core, while the specs all say that the timestamp counter is independent on each core/CPU, in practice they run pretty much neck-and-neck. So if one CPU runs priveleged instructions while the other runs nonpriveleged instructions, compare the count between the two. To keep it independent, just compare the delta between start and finish of the test run. They should be within a fraction of a percent of each other.
The first solution could be circumvented by emulating the external clock source too. But that could have implications like the computer clock (As in the time displayed in the corner of the screen) running noticibly slow. The method of detection using SMP would be much much harder to defeat, though I'm sure it could be done. It is also harder to implement, however.
What it comes down to is an arms race, but that's true of any security work.
It's really a moot point for the reasons you point out about getting the user to reboot...
But I don't see why it shouldn't be possible to demote a host OS running on the hardware into a guest OS running in a VM in a live system. It would probably be more trouble than it's worth considering the ease of the alternatives, but theoretically all the VM has to do is get ring 0 priveleges (Easy to do if you have root/administrator level access) then hijack the thread of execution away from the OS. Then it just has to initialize the virtual machine and start it executing right where it left off. Since it doesn't have to mess with any hardware but the CPU, the state of everything else is left unmolested and doesn't realize anything changed.
That might be an interesting challenge, actually... Write something to take over ring 0 then let the OS resume as a demoted guest.
The article talks about how the prototype malware "drops a VMM (virtual machine monitor) underneath a Windows or Linux installation." In other words, the victim computer's regular OS becomes the guest OS, with the rootkit serving as the host OS with an integrated VM.
VMware is a much more complete package than would be needed. It is possible to make something much more lightweight, such that it wouldn't have a huge impact on games. Hardware access doesn't necessarily need to be virtualized, nor do IO ports/DMA/etc which would be used by the video hardware. Some would, but not all, and in many cases it could pick what to virtualize and what to let pass.
The thing that's wrong with the idea, is that the malware is presenting a virtual machine. Meaning it could very well be a virtual bootblock that looks like what you expect, rather than the bootblock that BIOS loads.
Are the chips actually socketted though? Because with the price of things these days, it's actually cheaper to have two chips soldered onto the motherboard than one socket and two socketted chips. Sockets are not cheap, as far as the price of parts go.
Besides, swapping chips in a socket isn't a fun user experience, and these are probably high end boards where money isn't an object anyway.
The rootkit IS the virtual machine, AND the host OS. It is what loads when the computer boots up. Then it sets up it's own virtual machine (Like vmware, et al., but it's own implementation) and boots the computer into that virtual machine. The OS can't detect this rootkit through normal means because the methods it would use to detect it could be emulated by the virtual machine to look correct. There is no "host OS" to detect the rootkit or not, because the rootkit IS the host OS.
Of course, there are plenty of ways to detect if you are running within a virtual machine.
The thing with emulating a "ring 0" environment is that there is a lot to emulate. Most everything that would not work in a true ring 0 environment would cause the CPU to raise an interrupt for the host OS to handle. Typically the OS handles it by smacking around the application for being bad and doing something it isn't supposed to do. But it is possible to instead do what it is trying to do, and make it look like nothing was amiss.
The trouble is there is a lot of different things to deal with. If you know your target OS, it's easier since you don't need to emulate every little thing the CPU does, just what the OS will be using. But even then there will always be telltale fingerprints that something is amiss. Theoretically you could get around some of them by scanning ahead the instructions to be executed, but at some point you seriously impact system performance, and that in itself will make people notice.
Off the top of my head, the simplest way to detect it takes advantage of the fact that emulating ring 0 operations involve a context switch and some execution. Context switches tend to be rather expensive operations compared to most everything else the CPU does. The CPU has something called a timestamp counter, which basically counts every clock cycle, always incrememting, no matter what process/thread is running. An instructions should take a deterministic number of clock cycles. So just check the timestamp counter, perform a priveleged instruction, then check the timestamp counter again. If it looks like it took too long, that means you are running under a virtual machine.
Of course detection doesn't help with removal, but it's a start.
But that doesn't really have anything to do with it. C# and VB.NET share the libraries of the.NET framework, so it's not hard to imagine someone who knows one language could understand what the other one was doing. You read through it and see words you recognize and know what they do.
But that still has nothing to do with the structure of the language. The fact that VB.NET uses CIL and that it uses the.NET API does not change the basic syntax of the language, and it is the syntax of the language that makes people say it is a bad choice for learning programming.
Just because it compiles to the same thing doesn't mean the languages can be compared. The toy language thing is not about the language interpreter, but how the language is structured. That goes doubly so for the coding habbits it promotes.
Why are you trying to compare apples to oranges? The fact that VB is now translated to CIL does not change the structure of the language significantly.
My first thought when I saw the article was "Traffic shaper". I run one at home and it really helps with latency. But that is software. I suppose I can understand the concept of not wanting to run more software... From a gamers perspective, the less running to interrupt the game, the better. But it's not like a decent traffic shaper takes a lot of processing time. And it is better done in software anyway, at the source - the network stack. It can be done after the fact, but it is more complex to do.
Slashdot Mirror
And then the next version of the hack will patch the part of the firmware that deals with the read firmware command (You didn't think the main board has a direct path to the drive firmware did you? The command goes over the SATA bus where it has to be processed by the firmware...) and return the "right" thing...
My mom is actually pretty tech savvy, but I suspect moms that would call and make that confusion would likely call Blu-ray, HD-DVD and even DVD as just "CD".
3 sounds like you had cheap controllers, or cheap switches. I forget which it is. But either way, the system I had in place (Using Switchlinc switches, and a custom script on my computer, forget which open source package I used) didn't have that problem.
I didn't have the X10 crap, I shelled out $$ for some high quality X-10 protocol light switches. In addition to all the fancy schmancy features, they would remember if they were on or off when the power failed, and would return to that state when the power came back.
But like everyone else, the flakiness of the X-10 protocol eventually got too much for me and I ditched the whole thing when I moved. Once I buy a house I may look at the current options again, like Insteon.
Maybe god is trying to file a patent infringement case to stop humans from mucking around with DNA.
If they keep putting out "failures" like the Game Cube, they will be sitting pretty.
"What are you hiding from me there?"
"Nothing."
"Don't lie to me. It's an iPOD isn't it. You have a ****ing iPOD!"
"No, it's pot! I'm doing drugs."
"Don't give me any of that. It's an iPOD. You know that we don't use iPOD in this house. And what's that on your computer? Let me see your screen."
"It's just porn, dad!"
"It better be. If I catch you looking at Google one more time, you're grounded for LIFE. Now go smoke your pot and watch the porn like a good boy."
CRC is about detecting errors, not so much about correcting them. Error correction, on the other hand, is half science, half art form. Part of error correction is knowing the failure pattern of the media in question. Knowing how related bits will fail allows the bits for a group of correctable data to be spread out across areas that aren't linked.
Eh, I was ready to avoid them as soon as I read on that page that they redefined RAID as "Reliable and inexpensive disk". I'm not sure I'm clear on exactly how that is different than "Redundant Array of Inexpensive Disks". It doesn't sound more clever, and it says the same thing. Except by saying the same thing, it says that they don't know what they are talking about.
Random idea on how to deal with credit card applications...
I kept seeing people talking about "why should I have to deal with it when it's not my problem?"
Well... Why not make it THEIR problem. Just take the blank application, stick it into the postage paid envelope (Tear off half of any identifying information if you wish - half so they don't have it all, and when you trash it, someone who picks through it doesn't have it all) and mail it back to them? Bam, not in your trash to be recovered, it's now their problem.
But I would counter with Oracle does not just run on x86. You can run Oracle on Solaris, AIX, HP-UX, and so on.
Because software has bugs, and BIOS is software just like anything else. BIOS contains the CPU microcode which comes out with updates sometimes. (Microcode isn't flashed like BIOS is... A microcode update has to be loaded every poweron.)
Support for new CPUs that didn't exist but are perfectly compatible with the chipset.
The BIOS does more than just load the OS. It sets up the chipset as well. Some of it in ways that the OS can't do anything about easily. There are a number of settings in the chipset and CPU that require a reset to take effect, so your computer likely resets a couple times before you even see the BIOS screen.
All of this has to be done by the BIOS, and if theres a bug in any of it, you need to update the BIOS.
I thought of that... But it's actually even easier to detect TSC drift. Especially in dual core machines.
For single core, any reliable time source would do. The CPU clock runs at a fixed frequency. So within 1 tick of the external timesource you'd be able to easily notice the drift. Especially if you spend the entire time doing priveleged instructions.
For dual core, while the specs all say that the timestamp counter is independent on each core/CPU, in practice they run pretty much neck-and-neck. So if one CPU runs priveleged instructions while the other runs nonpriveleged instructions, compare the count between the two. To keep it independent, just compare the delta between start and finish of the test run. They should be within a fraction of a percent of each other.
The first solution could be circumvented by emulating the external clock source too. But that could have implications like the computer clock (As in the time displayed in the corner of the screen) running noticibly slow. The method of detection using SMP would be much much harder to defeat, though I'm sure it could be done. It is also harder to implement, however.
What it comes down to is an arms race, but that's true of any security work.
It's really a moot point for the reasons you point out about getting the user to reboot...
But I don't see why it shouldn't be possible to demote a host OS running on the hardware into a guest OS running in a VM in a live system. It would probably be more trouble than it's worth considering the ease of the alternatives, but theoretically all the VM has to do is get ring 0 priveleges (Easy to do if you have root/administrator level access) then hijack the thread of execution away from the OS. Then it just has to initialize the virtual machine and start it executing right where it left off. Since it doesn't have to mess with any hardware but the CPU, the state of everything else is left unmolested and doesn't realize anything changed.
That might be an interesting challenge, actually... Write something to take over ring 0 then let the OS resume as a demoted guest.
The article talks about how the prototype malware "drops a VMM (virtual machine monitor) underneath a Windows or Linux installation." In other words, the victim computer's regular OS becomes the guest OS, with the rootkit serving as the host OS with an integrated VM.
VMware is a much more complete package than would be needed. It is possible to make something much more lightweight, such that it wouldn't have a huge impact on games. Hardware access doesn't necessarily need to be virtualized, nor do IO ports/DMA/etc which would be used by the video hardware. Some would, but not all, and in many cases it could pick what to virtualize and what to let pass.
The thing that's wrong with the idea, is that the malware is presenting a virtual machine. Meaning it could very well be a virtual bootblock that looks like what you expect, rather than the bootblock that BIOS loads.
Are the chips actually socketted though? Because with the price of things these days, it's actually cheaper to have two chips soldered onto the motherboard than one socket and two socketted chips. Sockets are not cheap, as far as the price of parts go.
Besides, swapping chips in a socket isn't a fun user experience, and these are probably high end boards where money isn't an object anyway.
Close but not quite...
The rootkit IS the virtual machine, AND the host OS. It is what loads when the computer boots up. Then it sets up it's own virtual machine (Like vmware, et al., but it's own implementation) and boots the computer into that virtual machine. The OS can't detect this rootkit through normal means because the methods it would use to detect it could be emulated by the virtual machine to look correct. There is no "host OS" to detect the rootkit or not, because the rootkit IS the host OS.
Of course, there are plenty of ways to detect if you are running within a virtual machine.
Speaking just of the x86 architecture...
The thing with emulating a "ring 0" environment is that there is a lot to emulate. Most everything that would not work in a true ring 0 environment would cause the CPU to raise an interrupt for the host OS to handle. Typically the OS handles it by smacking around the application for being bad and doing something it isn't supposed to do. But it is possible to instead do what it is trying to do, and make it look like nothing was amiss.
The trouble is there is a lot of different things to deal with. If you know your target OS, it's easier since you don't need to emulate every little thing the CPU does, just what the OS will be using. But even then there will always be telltale fingerprints that something is amiss. Theoretically you could get around some of them by scanning ahead the instructions to be executed, but at some point you seriously impact system performance, and that in itself will make people notice.
Off the top of my head, the simplest way to detect it takes advantage of the fact that emulating ring 0 operations involve a context switch and some execution. Context switches tend to be rather expensive operations compared to most everything else the CPU does. The CPU has something called a timestamp counter, which basically counts every clock cycle, always incrememting, no matter what process/thread is running. An instructions should take a deterministic number of clock cycles. So just check the timestamp counter, perform a priveleged instruction, then check the timestamp counter again. If it looks like it took too long, that means you are running under a virtual machine.
Of course detection doesn't help with removal, but it's a start.
But that doesn't really have anything to do with it. C# and VB.NET share the libraries of the .NET framework, so it's not hard to imagine someone who knows one language could understand what the other one was doing. You read through it and see words you recognize and know what they do.
.NET API does not change the basic syntax of the language, and it is the syntax of the language that makes people say it is a bad choice for learning programming.
But that still has nothing to do with the structure of the language. The fact that VB.NET uses CIL and that it uses the
Or the "web accelerators" that made your "dialup as fast as DSL", when really all they were is a precacher for links in web pages.
Just because it compiles to the same thing doesn't mean the languages can be compared. The toy language thing is not about the language interpreter, but how the language is structured. That goes doubly so for the coding habbits it promotes.
Why are you trying to compare apples to oranges? The fact that VB is now translated to CIL does not change the structure of the language significantly.
My first thought when I saw the article was "Traffic shaper". I run one at home and it really helps with latency. But that is software. I suppose I can understand the concept of not wanting to run more software... From a gamers perspective, the less running to interrupt the game, the better. But it's not like a decent traffic shaper takes a lot of processing time. And it is better done in software anyway, at the source - the network stack. It can be done after the fact, but it is more complex to do.
You could say they exist in a state of being both right and wrong.