Post by Igor Sviridovhi Thad,
I've started to write this reply more than a month ago, expressing
my doubts in virus writers ability to hide in low-level defects, but
never finished it.
Hi Igor,
Professional malware and virus "authors" are not dummies vs. all the
proverbial script kiddies simply running scripts spreading malware
far and wide.
Who are such "authors"? My guess includes the CIA, NSA, China, Russia,
North Korea and possibly even some folks involved in the anti-malware/
-virus community of companies. I can't prove anything that but a lot
of circumstantial evidence can be found doing some searching.
Such "authors" cobble-up things like StuxNET:
http://en.wikipedia.org/wiki/Stuxnet
which are extremely complex suites of programs. Hiding code in falsely
marked "bad" blocks could/would be trivially implemented.
Back when I worked at Tymshare in Cupertino there was a one-week period
I was charged with the responsibility of assuring Xerox's Sigma 7 would
not pass its acceptance tests because Tymshare's technical founders were
favoring DEC's PDP-10 systems and wanted Xerox to fail.
For one week I'd come in and do "something" that caused the Sigma to go
belly up and then go home for the day.
I exploited every bug I could find in the system and hid several of my
"crash" programs which ran in the machine's registers in page 0 of real
memory whose first 16 location could not be easily examined because the
hardware mapped addresses 0x0 to 0xF to the machine's registers -- so I
swapped the system's map between pages 0 and 1 to be able to write the
code to memory in page 1, then flip the hardware map again exchanging
pages 0 and 1.
One day I completely wiped the system RADs (Rapid Access Disks fixed-head
drums made by Bryant), another day I wiped the entire OS from disk, etc.
I made all these "incidents" appear to be hardware failures and the CEs
simply could NOT figure out what I had done even after spending hours
with all their test gear (oscilloscopes, etc.).
The key to being able to perform the above required "god" status on the
machine. There was a bit in the PSW (Program Status Doubleword, 64 bits)
that, if set to 1, granted a process "god" status much like being root
on a Linux or UNIX system.
The user-level command interface (the "exec") of the Xerox UTS (Universal
Timesharing System) had a "dump" that saved all of the process' memory,
16 registers, and a copy of the PSW. It was trivial to set the "god" bit
in the PSW on the saved dump file. The "restore" command then restored the
environment: memory, registers, and the PSW with the "god" bit set in the
program's process PSW.
Each day I wrote a new program to do something different: clear the RADs,
wipe the OS, play bird calls through the console speaker then halt the
system, etc. The bird call trick was hilarious -- I had actually been
given a single punch card by one of the CEs that when read in the card
reader would play continuous bird calls through the console speaker when
the system was in diagnostic/maintenance mode and I used the same bird
call code in one of my daily programs. It was a fun week. :-)
Post by Igor Sviridov[...]
Recent NSA disclosures (specifically IRATEMONK implant described in URL
below) prove that's it's possible to infect wide variety of drive firmware;
http://leaksource.wordpress.com/2013/12/30/nsas-ant-division-catalog-of-exploits-for-nearly-every-major-software-hardware-firmware/
Drive firmware modification isn't the same thing as putting malware in the
falsely-marked bad blocks but it is something that could also be done. For
every disk I low-level formatted (only 3 so far) there was no evidence the
drive's firmware had been altered. Once a low-level format completed, the
drives operated fine the same as when they left the factories and were
installed in the PCs after reloading the OS.
Post by Igor SviridovWe do know that drive firmware programming is possible online. So your
scenario is now confirmed to be fully plausible; i guess only amount of
effort is preventing (for now?) it's wide adoption by virus writers.
Drive firmware and falsely-marked bad blocks are two different vectors
for malware. I suppose some new and upcoming malware could use both
vectors to be really nasty.
It's been commonly known that drive firmware can be easily "updated"
because the vendors often issue firmware upgrades to be downloaded
and applied in the field by "end users" (e.g., consumers); I did that
for many Seagate drives over the years.
I haven't ever seen, AFAIK, a malware firmware update on a disk but it
was very clear that using falsely-marked-as-bad good blocks to store
malware isn't that rare. I have had several clients' systems infected
by malware which clearly existed in the falsely-marked blocks because
absolutely NO anti-malware checker could find them and the only solution
was to do the low-level format using the HDDGURU's program which cleared
the bad block list and rebuilt it by laboriously re-analyzing the entire
disk sector-by-sector.
Several months back here David Kaye also reported one client's disk had
no malware that could be found using a long list of tools and yet it was
still infected. My suspicion was the malware resided in the falsely-marked
sectors which is why I posted the URL to the HDDGURU's program. Dave never
reported back the disposition of that disk and whether he did a low-level
format to clear the malware or not because David also wrote the customer
was extremely distraught and wanted simply to buy a new system and abandon
the old system with the presumed infected disk.
Here's the website URL again for those who didn't save it previously because
it should be THE tool of last resort when fighting a malware infection:
http://hddguru.com/
Post by Igor SviridovPost by Thad Floryan[...]
Awhile back I had factory-internal manuals for a number of SCSI disks and it
would have been trivial to alter/read/write those HD's bad block lists, too.
Thad
It's not conceptually impossible, but would require support for
varying firmware versions and drive vendors.
I'm also not convinced that there are ATA commands for defect list
manipulation; but i guess you can rewrite firmware or directly update host
protected area.
The very fact the HDDGURU's program exists and works is prima facie evidence
the bad-block list can be altered by other than the HD's own internal firmware.
I haven't seen the HDDGURU's source code but he's obviously using internal
documentation to perform the identical task(s) the HD manufacturers do when
testing any given disk and building the initial bad-block list before the HD
is shipped (or rejected if the bad-block list is too large -- stuff happens).
I also assume any/all hard disk recovery companies have similar programs.
Thad