Malware that even an anti virus provider cant deal with

[Jarhyn]

Jarhyn, I am not following your nonsense, sorry.
I suspect that you have no clue what you are talking about.

Hard drives have an actual CPU inside which runs firmware code.
Firmware code is in flash chip which is much bigger than the code it contains. You can hide a lot there.

I sure hope you're wrong, or the last year I spent designing, flashing, and debugging firmware for embedded systems is a pretty colossal waste of money for my emoloyer!

Firmware have only so much real estate on their flash banks, and everything else is volitile. If I put nothing on the drive but enough linear branch instructions to occupy the entire firmware, with well minimal and well buried kernel code, the virus has no way of knowing where on the flash the functional code of the kernel is; it can't relocate; if it overwrites anything on the drive, it ruins chain of branch instructions that execute the kernel, ruins the kernel, or ruins the flash instruction set, especially if the code that runs those doesn't live exactly and entirely at its entry point.

The trick is to engineer a firmware which if modified would either not flash back, or would not perform its reporting functions, if modified in any nieve way.

 

[barbos]

Jarhyn, I am not following your nonsense, sorry.
I suspect that you have no clue what you are talking about.

Hard drives have an actual CPU inside which runs firmware code.
Firmware code is in flash chip which is much bigger than the code it contains. You can hide a lot there.

I sure hope you're wrong, or the last year I spent designing, flashing, and debugging firmware for embedded systems is a pretty colossal waste of money for my emoloyer!

Firmware have only so much real estate on their flash banks, and everything else is volitile. If I put nothing on the drive but enough linear branch instructions to occupy the entire firmware, with well minimal and well buried kernel code, the virus has no way of knowing where on the flash the functional code of the kernel is; it can't relocate; if it overwrites anything on the drive, it ruins chain of branch instructions that execute the kernel, ruins the kernel, or ruins the flash instruction set, especially if the code that runs those doesn't live exactly and entirely at its entry point.

The trick is to engineer a firmware which if modified would either not flash back, or would not perform its reporting functions, if modified in any nieve way.

Sorry, I can not parse it.
Once again, Hard Drive has flash for firmware which contain code itself. Flash chips have standard sizes but code itself is not. So at the very least you have flash chip which is 50% bigger than your code, that's a plenty of space.
That's a a firmware which need to have a code which activate the virus that's probably no more than 100 bytes.
Payload itself can be on hard drive platters themselves and you can easily have 10-20MB payload hidden there in reserve sectors or in sectors mapped as bad.

 

[Jarhyn]

I sure hope you're wrong, or the last year I spent designing, flashing, and debugging firmware for embedded systems is a pretty colossal waste of money for my emoloyer!

Firmware have only so much real estate on their flash banks, and everything else is volitile. If I put nothing on the drive but enough linear branch instructions to occupy the entire firmware, with well minimal and well buried kernel code, the virus has no way of knowing where on the flash the functional code of the kernel is; it can't relocate; if it overwrites anything on the drive, it ruins chain of branch instructions that execute the kernel, ruins the kernel, or ruins the flash instruction set, especially if the code that runs those doesn't live exactly and entirely at its entry point.

The trick is to engineer a firmware which if modified would either not flash back, or would not perform its reporting functions, if modified in any nieve way.

Sorry, I can not parse it.
Once again, Hard Drive has flash for firmware which contain code itself. Flash chips have standard sizes but code itself is not. So at the very least you have flash chip which is 50% bigger than your code, that's a plenty of space.
That's a a firmware which need to have a code which activate the virus that's probably no more than 100 bytes.
Payload itself can be on hard drive platters themselves and you can easily have 10-20MB payload hidden there in reserve sectors or in sectors mapped as bad.

Let's say the flash bank is 20kb. I write a 1kb kernel that contains an interpreter for the signals that normally operate the drive that reads the input and if it is not 'flash the drive' it does nothing but spin the platters. I locate this code at a random address, we'll call it address K. I write a second piece of code sized 1k that is The flash function. I place this piece of code at a random address F, also with distinct pre-flash reporting using the physical mechanism of the drive, and link it to the kernel. The entire remaining 18k I have to work with gets occupied with a long series of randomly meandering auto-generated branch instructions that begin at 0x0 and at the very end call address K, at compile time.

If any part of the 20k is overwritten by virus code, the daisy chain of branches gets broken. Entering at 0x0 will no longer execute any of the actual kernel code, nor any of the test-enabled flash code. Since there is, in this scenario, only 20k to house the firmware, if I flash it with my test image and reset the drive, if it doesn't report both as having reached my kernel and before running the flash, the drive is evil.

The point is to ensure that 100% of the flash memory has been destructively tested.

 

[barbos]

Jarhyn, it would really help if you state your claims before going in full stream of words mode.

My claims was pretty simple, I will repeat it again: It's not impossible to write a virus which survives standard flash procedure. The reason for this claim is the fact that flash routine is in flash itself and therefore can be compromised by the virus as well.

 

[repoman]

This goes further back to the StuxNet virus itself, but why doesn't Iran make a fully analog system to enrich uranium? It was done during the Manhattan Project. I am sure that they could find a way to do it now even more efficiently.

 

[Jarhyn]

Jarhyn, it would really help if you state your claims before going in full stream of words mode.

My claims was pretty simple, I will repeat it again: It's not impossible to write a virus which survives standard flash procedure. The reason for this claim is the fact that flash routine is in flash itself and therefore can be compromised by the virus as well.

no. I stated them. You just did not read them. My point has always been that, given the words I have written, that this virus can be scoured off the face of the earth, either through detection or through the application of removal tools or detection tools. It is sad that it would require a manufacturer-specific removal tool.

The point I was making is that this virus has always been detectable, and is probably removable.

 

[Jayjay]

It will flash and perform the task fine, But virus would still be copied on a new version as well.
I doubt NSA bugs were flashproof but it can be done.

No, it wouldn't. Viruses aren't magic; there needs to be somewhere for a virus to be copied to, and drive firmware doesn't execute on the main CPU. It can proffer itself if requested by the boot loader, but if the drive isn't loaded by the boot loader, it's SOL. All it takes in flashing the firmware is putting a firmware that has a Goldberg machine of code on it. No nsa virus can possibly analyze code, and replicate an action whose intent is unknown and unknowable, without stepping on the mass of code that it's trying to inject to. Once the firmware is flashed, you just nuke the contents of the drive. the beauty of all this is that it can be accomplished entirely from other media, or even a portable image like a bootable CD. There's literally nothing the drive can do to keep itself from getting douched out, save block firmware flashes, and that isn't an option.

NSA virus does not have to analyze the code. But if NSA can get access to the code, it could program the evil firmware to duplicate the same output. It's not feasible to write a completely different Rube Goldberg machine for every drive you want to certify, so there is a risk.

Sure it adds some security as opposed to not doing anything, but it's not fool proof.

 

[barbos]

Jarhyn, it would really help if you state your claims before going in full stream of words mode.

My claims was pretty simple, I will repeat it again: It's not impossible to write a virus which survives standard flash procedure. The reason for this claim is the fact that flash routine is in flash itself and therefore can be compromised by the virus as well.

no. I stated them. You just did not read them. My point has always been that, given the words I have written, that this virus can be scoured off the face of the earth, either through detection or through the application of removal tools or detection tools. It is sad that it would require a manufacturer-specific removal tool.

The point I was making is that this virus has always been detectable, and is probably removable.

manufacturer-specific removal tool? what is that exactly? some kind of un-solderer?
Clean room and stuff?

 

[barbos]

There's literally nothing the drive can do to keep itself from getting douched out,

I explained how this is wrong, go and read it.

 

[Jarhyn]

no. I stated them. You just did not read them. My point has always been that, given the words I have written, that this virus can be scoured off the face of the earth, either through detection or through the application of removal tools or detection tools. It is sad that it would require a manufacturer-specific removal tool.

The point I was making is that this virus has always been detectable, and is probably removable.

manufacturer-specific removal tool? what is that exactly? some kind of un-solderer?
Clean room and stuff?

It's my attempt at saying 'a tool designed for the hardware of the specific drive model in question, made by the manufacturer is someone who has the specs to that drive'. You don't even need to target every drive, just the drives a specific organization uses. And as a bo us, most hardware is substantially similar within the bounds of a given manufacturer's products. After all, the goal is to have to deal with as few kinds of parts as they can get away with.

And the beauty of the rube goldberg machine is that they can be randomly generated with arbitrary reports to an arbitrary target size. As long as you know what processor and size of firmware you are targeting, there's nothing much to be concerned about in terms of failure. If it passes validation, hooray, if it doesn't, dump the drive to non-vulnerable media, remove the untrustworthy OS, and quarantine any infected files.

It just means that hard drive manufacturers will have to generate detection and/or removal tools for their drives in the short term and reorganize their hardware to require a jumper for firmware flashes in the future.

 

[barbos]

You are really a Rube Goldberg of posting, aren't you?

 

[Jimmy Higgins]

My prediction: Some will claim this is a conspiracy theory to distract attention from Putin's misdeeds and NSA would never do something so sinister because of the dire consequences if it were discovered they engaged it this type of activity.

*sigh*

 

[Jarhyn]

There's literally nothing the drive can do to keep itself from getting douched out,

I explained how this is wrong, go and read it.

Either it gets douched out and reports a validation signal, or it doesn't get douched out and it doesn't report a validation signal. Given the arbitrary nature of the validation signal, it cannot be produced by the virus because it is decided after the virus has ended up on the drive. In the case that it doesn't report a validation signal, the drive is evil, and can't not be evil, and you pull the data off and sequester any OS or executable/virus code and take your loss on that unit. The goal wouldn't be to recover every drive, or even recover any drive, just to prove that the drive isn't trustworthy and recover as much uncorrupted data as possible

 

[tupac chopra]

Has the NSA Planted Hidden Spying Files on Your PC?

Apparently, the NSA would have needed access to “the proprietary source code that directs the actions of the hard drives”—information only the hard drives’ producers should have. For the moment, it remains unclear how the spy agency obtained that code.

 

[Jimmy Higgins]

Has the NSA Planted Hidden Spying Files on Your PC?

Apparently, the NSA would have needed access to “the proprietary source code that directs the actions of the hard drives”—information only the hard drives’ producers should have. For the moment, it remains unclear how the spy agency obtained that code.

Probably stole it through espionage.

Also, is this grounds for prison? This is pretty damn invasive stuff. I know we don't like charging people for crimes against the Constitution, unless it involves some sort of health care legislation, but Jesus Fucking Christ! This is unacceptable.

 

[Loren Pechtel]

And how do you propose it lie dormant for a few months? The closest thing it has to the ability to tell time is the time-used information in the SMART status--it has no perception of time turned off and no means of obtaining the actual time.

Actually it does have such perception, OS tells it time.
But it does not really need that, it can simply wait for 2 months of ON time or 100 Power_Cycle_Counts Then infect your OS and then switch off completely by flashing itself an original and legitimate firmware That way nobody will find a trace, unless of course you were specifically waiting for virus act up.

And where does the OS tell the HD the time???

 

[Loren Pechtel]

You are really a Rube Goldberg of posting, aren't you?

I think the problem is that you are arguing with someone with enough more knowledge of the field that they're using domain words that you aren't understanding.

 

[arkirk]

http://www.dailykos.com/story/2015/...-Hacking-of-Virtually-All-Hard-Drive-Firmware

Prediction: most of the "small government" proponents on this forum will defend this action by the government. Why? Because they trust the government more than we "big government socialists" do.

Amen! There is so much underhandedness in our government it is revolting. The problem is that there is no protection possible against sneakiness in general. Sure, you can scrub a simple virus from your hard drive. Sure you deal with spam. But these rich corporations flush with money and expertise can always beat you and pretty much spy at will. It is probably a good idea not to joke too much about terrorism or post anything tongue in cheek. Guantanamo or similar awaits anybody who gets viral about changing anything in our government. It is no longer about bombs and dastardly plots. It is about thought crimes writ large on your hard drive or even worse...in the cloud.

 

[barbos]

Has the NSA Planted Hidden Spying Files on Your PC?

Probably stole it through espionage.

most likely.
speaking of which here is the latest:
https://firstlook.org/theintercept/2015/02/19/great-sim-heist/

AMERICAN AND BRITISH spies hacked into the internal computer network of the largest manufacturer of SIM cards in the world, stealing encryption keys used to protect the privacy of cellphone communications across the globe

All your SIM are belong to us!

 

[barbos]

You are really a Rube Goldberg of posting, aren't you?

I think the problem is that you are arguing with someone with enough more knowledge of the field that they're using domain words that you aren't understanding.

Well, maybe, but he is clearly incapable to communicate his knowledge coherently. Yeah and some words are very annoying I have to say.