[QUOTE=retina;395714]All these buzz-terms like "military-grade disk wiping" are disappointing. Proper "military-grade disk wiping" would not use the firmware to wipe the surface. Does the word "degauss" mean anything to those authors?[/QUOTE]More to the point, does the word "thermite" mean anything. Ernst has explained why.

[QUOTE=ewmayer;395723]So how are you measuring the capacity? You got some magic way to do that which bypasses the HD firmware?[/QUOTE]One approach might be to wipe the disk as thoroughly as possible. Don't bother putting a file system or anything like that on it. Then write reproducible but incompressible data sector by sector until the disk reports it is full. Needless to say you do this on a system unlikely to be compromised --- a Raspberry pi say. See how many sectors are written and check against the spec for the disk. If the reported capacity is less than the notional capacity, the disk is suspect. If they do match, read back and check all the sectors to ensure that one or more haven't been overwritten to leave space for hidden information. If you can't get all the data back the disk is definitely dodgy.

Of course, this is still far from perfect (the firmware can use bad-block reserves for example) but it picks up the amateurs.

Capacity loss should be evident. If it was falsely reported as the original size as stated on the cover then you would have the OS trying to put more data on there than is actually available. And if you are stealing just 100MB and reducing the reported capacity to show what is remaining then the user may wonder why.

I still stand by my comment about the "military-grade bullshit". For a home user I would agree that degaussing would be unlikely, but that is not military-grade. It doesn't make sense. For a reporter to use such buzz-terms is poor form IMO.

A key logger from an HDD interface? The ATA spec I read doesn't mention anything about uploading driver data to the host for execution. Unless you are talking about some sort of malware already in the host driver code? But that would have to come from a different vector. Perhaps if this is part of a larger package it might make sense, but on its own from an HDD it doesn't seem plausible. It is certainly possible to capture the truecrypt keys from memory but that also requires associated code running on the host in kernel mode. The HDD firmware could encrypt whatever data it wanted to before sending it off to the host for decryption but that would require pre-knowledge of the keys and algorithms used.

On SSDs, you have [URL="http://www.samsung.com/global/business/semiconductor/minisite/SSD/global/html/whitepaper/whitepaper05.html"]over-provisioning[/URL] to think about. Sometimes this over-provisioning is transparent to the user and even the interface.

<conspiracy-theory>Maybe "military-grade" erase techniques are purposely designed to stop most people from retrieving data but not all people. IOW, the obvious solution (physical destruction) is not desirable because then the NSA (?) wouldn't have any chance to read the drive.</conspiracy-theory>

[underlines mine]
[QUOTE=retina;395726]A key logger from an HDD interface? The ATA spec I read doesn't mention anything about uploading driver data to the host for execution. Unless you are talking about some sort of malware already in the host driver code? But that would have to come from a different vector. [u]Perhaps if this is part of a larger package it might make sense[/u], but on its own from an HDD it doesn't seem plausible. It is certainly possible to capture the truecrypt keys from memory but that also requires associated code running on the host in kernel mode. The HDD firmware could encrypt whatever data it wanted to before sending it off to the host for decryption but that would require pre-knowledge of the keys and algorithms used.[/QUOTE]

Which it is, as the AT piece lays out - we are discussing a fully-featured malware platform. The hidden HD storage for the keylogger would be just the storage-until-next-chance-to-upload-to-the-mother-ship component of such an exploit.

Here's a question for the HD wonks - is there any excess memory associated with the HD firmware which someone sophisticated enough to rewrite said firmware could use as a storage locker? If the targeting is highly specific and the upload opportunities reasonably frequent, one might only need a few kB of such off-disk storage to be useful for snooping purposes. Since the firmware needs to reside somewhere (e.g. in an EPROM) and needs to be updatable, I'm guessing there is such memory, I'm curious as to the rough amount and whether one can transfer data from the system to it dynamically. (The 'ROM' aspect would seem to indicate not, but since there is the 'P' preceding it such memory is in fact writable, the question is how the write interface works. Again, assume we are dealing with folks who in many cases seem to know as much or more about the HD programming as the manufacturers themselves, or at least who are capable of using said programming in ways the manufacturers probably never even considered.)

[QUOTE=ewmayer;395784]Again, assume we are dealing with folks who in many cases seem to know as much or more about the HD programming as the manufacturers themselves, or at least who are capable of using said programming in ways the manufacturers probably never even considered.)[/QUOTE]That sounds like valuable IP. Step 5, profit.

[QUOTE=only_human;395786]That sounds like valuable IP. Step 5, profit.[/QUOTE]

I like the way you think, my dear [i]Unterwäschenzwerg[/i] friend.

[QUOTE=ewmayer;395784]Here's a question for the HD wonks - is there any excess memory associated with the HD firmware which someone sophisticated enough to rewrite said firmware could use as a storage locker?[/QUOTE]I'm not an HDD person but I do know about the common forms of FLASH memories used. Their re-programmability is limited to only a few cycles (1000 in many cases). And erasure is usually only possible for the entire array at a time. It is possible to make it partitioned with each section independent but since this costs more it is not usually done for something that is expected to only need reprogramming a few times at most in its expected lifetime.

Stealing sectors from the over provisioning portion is still going to be noticeable because the host software can allocate and query from that region. At some point you would see the difference. However it may be more feasible to mark a few sectors as bad and use the spare sectors to replace them. This way everyone sees the entire capacity and unless the host deliberately tries to read the bad sectors no one would get suspicious. Although having too many bad sectors is also a sign of problems and the user may not be happy. But I guess it all comes down to vigilance. Perhaps most users never care to look at the numbers.

[QUOTE=kladner;395141]Is that ever depressing. :sad:[/QUOTE]

I'm afraid I have another depressing Ames piece to share, detailing the role of the "Vichy privacy advocates" at ACLU and EFF in passing another truly spectacular anti-privacy law:

[url=pando.com/2015/02/15/meet-the-serial-failures-in-charge-of-protecting-americas-online-privacy/]Meet the serial failures in charge of protecting America’s online privacy[/url]
[quote]Earlier this week, McClatchey published an article reminding readers of something that can’t be repeated enough: Thanks to the 1986 Electronic Communications Privacy Act, the government can read all your emails over 180 days old without a warrant. That’s what the law says — and yet it remains obscure enough that every time some national media reminds us, it still shocks the senses.[/quote]

[QUOTE=ewmayer;395810]I'm afraid I have another depressing Ames piece to share, detailing the role of the "Vichy privacy advocates" at ACLU and EFF in passing another truly spectacular anti-privacy law:[URL="http://pando.com/2015/02/15/meet-the-serial-failures-in-charge-of-protecting-americas-online-privacy/"].....[/URL][/QUOTE]

The author even calls it depressing. As an antidote, here is a Dilbert strip which isn't really on topic, but did come from a side link to the story. :smile:

[CENTER][URL="https://firstlook.org/theintercept/2015/02/19/great-sim-heist/"]"THE GREAT SIM HEIST[/URL]
HOW SPIES STOLE THE KEYS TO THE ENCRYPTION CASTLE"[/CENTER]