Wipe out hiiden malware non HDD with Linux

[Geek-9pm]

Last year an data specialist publicly reported that malware can reside in the hidden service area of a hard disk  drive.
Now Linux users have a new tool. A program that gets into the deep dark  secrects of any hard drive and  really wipes it clean.
Here is the link:
http://superuser.com/questions/642637/harddrive-wipe-out-hidden-areas-like-hpa-and-dco-also-after-malware-infectio

Malware in windows (yes), possibly rootkit/bootkit. Don't want to take any chances. So, wiped drive with DBAN foolishly (PRNG, 8 pass). Later came to know that DBAN does not kill HPA (host protected area) and DCO (Drive configuration overlay) which are "hidden areas" (if present) in a hard drive. Saw that HDDErase made by CMRR can remove DCO and HPA, if present. ...

Myself, I just don't have the time and every to try this.
So my  question is has anybody done this?
Does it  really work?

[BC_Programmer]

Last year an data specialist publicly reported that malware can reside in the hidden service area of a hard disk  drive.

Yes. Anything can. it requires that the software issue a SET MAX ADDRESS ATA command followed by read/write operations within that area. Fundamentally the IDENTIFY DEVICE retrieves the max address but for drives with an HPA that max address excludes it. I do wonder how you figured the poster was a "data specialist". I found that at odds with their statement of "Me - Average computer user with little bash skill, i.e I don't really know what I am doing."





The HPA was used with those old Disk Overlay programs/drivers. you'd set a Jumper on the drive to make it report 4096 cylinders to prevent an older BIOS from hanging at boot up, then the Driver overlay/boot program installed by the overlay would use the SET MAX ADDRESS after bootup to reset the ATA size register so the system could use the full size of the drive.


However it isn't particularly useful from the standpoint of writing malicious software. That is, while it can be used to store data that survives a format/install, that "surviving data" is not somehow executable. That is, if you- as in the case of the linked post- run DBAN on the drive, it won't clear the HPA. However, that data in the HPA is now basically orphaned because you won't have software on the system that is accessing it.

That is, a Rootkit cannot hide exclusively within the HPA, and would need something to execute to "activate" and use the contents.

[Geek-9pm]

Don't want to start a fight with  you BC.
Still, there is a way of malware using the 'hidden' area to do bad things. It is not a one-stick process. People who write malware must have evil minds. They will do something that others think is impossible. The malware makers gatherer a set of tools and write a symphony of deception and destruction.
But I will decline to explain how it is done because:
A) Showing the proof-of-concept will just encourage more to do it.
and..
B ) Actually writing such code and turning it loose just to prove a point would make me a criminal.

My intent was to warn others that such things are real threats. To date the equipment makers have not made computer technology as secure as it should be.

[BC_Programmer]

They will do something that others think is impossible.

Alright, let's hear of one example of something that malicious software authors did that was generally thought to be literally impossible?

[Geek-9pm]

Sure. Off the top of my head with no further research. This one  is about network servers, not windows desktops. But it did cause trouble for a large number of users.

It had been documented that there was a soft spot in the way servers did the DNS lockup.  For a very sort period of time a hostile program could fool the server into using the wrong address during a DNS lockup. Many administrators just ignored it because it sounded so absurd that anybody would attempt to trick the server in the very short period of time. They thought it was near impossible. So the took no action. Later on a lot of harm was done.

[BC_Programmer]

Sure. Off the top of my head with no further research. This one  is about network servers, not windows desktops. But it did cause trouble for a large number of users.

It had been documented that there was a soft spot in the way servers did the DNS lockup.  For a very sort period of time a hostile program could fool the server into using the wrong address during a DNS lockup. Many administrators just ignored it because it sounded so absurd that anybody would attempt to trick the server in the very short period of time. They thought it was near impossible. So the took no action. Later on a lot of harm was done.

At no point was that considered impossible. In fact it was brought up as a issue with the DNS heirarchy while it was in it's infancy. administrators being ignorant is not evidence of hackers doing the impossible.

[Geek-9pm]

So are you saying that if you think it is impossible, it is really n impossible?

We all know about Trojan houses. But before that, many could not believe what happened. But it did happen.

And worms. Before worm ware came on the stage, it was unthinkable that a small program could do so much damage. Impossible? No, but nit was incomprehensible.
And when people do do understand a threat , they imagine it is impossible.

What about the printer that sent military documents to the Russians?  Did the the military people who used the printer think it was impossible?

[BC_Programmer]

So are you saying that if you think it is impossible, it is really n impossible?

The HPA is only used if software is written that uses it. If software does not issue the ATA command specifically for the purpose of making the HPA Readable, and if software does not copy from the HPA area and execute it, than  malware cannot "hide" in the HPA without a piece of malicious code that is designed for those two functions.

What I am saying is that it is impossible for a piece of malware to hide exclusively within the HPA without malware being installed outside of the HPA designed to use it:

Premise 1: In order to access the HPA, the ATA Command to set the max Address is required. If this command is not issued, than the HPA will not be accessible for reading nor for writing.
Premise 2: You cannot execute code, malicious or otherwise, that is not accessible. If you cannot read from an area of a disk, you cannot copy that data into memory to either execute or use it.
Premise 3: No current, relevant Operating Systems include code that issues ATA command and make the HPA readable, nor do they then read from the HPA and execute code therein.
Therefore: any Malicious code resident in the HPA is going to require malicious code outside the HPA that is designed to access it.

For illustrative purposes, let us assume that a Hard Disk Drive has malicious code present in the HPA.

If we wipe that drive with DBAN, the malicious code will remain.

However, if you install an OS on the drive, that HPA is not accessed. It is outside the addressable area of the Disk and any ATA command issued against the Drive controller is going to fail the request because the appropriate command to set the max address beyond that specified in the ATA Identify command was not provided. That malicious code will continue to exist but it's existence is not of particular consequence because it cannot execute.

Any claim made that malware can reside exclusively in the HPA; for example, if you can wipe the drive and then get reinfected from the HPA- is false because there is no factual or logical basis upon which to make that claim. It is as reasonable as claiming that a PC can get infected from a floppy disk sitting on a desk across the room, because that data would be just as accessible.

Whether it might be a tool used by Malware is not a question. It already is, just as it was also the case that registry entries were hidden from registry editor by including null characters.

But Floppy disk viruses were able to exist because computers purposefully looked for and executed code on floppy disks at boot time. Systems do not look for an execute code in a hard drives HPA. So it is not an infection vector, instead it can be a location where infections store a payload.

[BC_Programmer]

We all know about Trojan houses. But before that, many could not believe what happened. But it did happen.

The possibility of misdirection in the purpose of a program was partly covered in Von Nuemann's published work on the subject; though it arguably was not covered in depth, it existed long before the commonplace appearance of Trojan horse malware. The first "Wild" Trojans appeared in 1978. Before that nobody can be quoted as having said that misdirection of software was impossible. In fact, many professionals and academics in the field can be quoted as saying precisely the opposite.

And worms. Before worm ware came on the stage, it was unthinkable that a small program could do so much damage. Impossible? No, but nit was incomprehensible.
And when people do do understand a threat , they imagine it is impossible.

Worms existed before the Morris Worm; the Morris worm was the first known worm to spread in the wild, but researchers had created numerous experimental pieces of software which would classify as worms. Additionally, if everybody thought it was impossible it is odd that it is explicitly mentioned in the United States Computer Fraud and Abuse Act of 1986 from two years previous to Morris's worm.

What about the printer that sent military documents to the Russians?  Did the the military people who used the printer think it was impossible?

I can't find any information substantiating the claim that this event ever occured.

[Geek-9pm]

I can't find any information substantiating the claim that this event ever occured.

That is what the men told me when they came to my place. 

http://search.slashdot.org/story/14/10/19/0655240/bbc-takes-a-stand-for-the-publics-right-to-remember-redacted-links