There are a lot of malware programs in the wild today, but luckily we have methods of detecting and removing them. Antivirus is an old standby, and if that fails you can always just reformat the hard drive and wipe it clean. That is unless the malware installs itself in your hard drive firmware. [MalwareTech] has written his own frightening proof of concept malware that does exactly this.
The core firmware rootkit needs to be very small in order to fit in the limited memory space on the hard drive’s memory chips. It’s only a few KB in size, but that doesn’t stop it from packing a punch. The rootkit can intercept any IO to and from the disk or the disk’s firmware. It uses this to its advantage by modifying data being sent back to the host computer. When the computer requests data from a sector on the disk, that data is first loaded into the disk’s cache. The firmware can modify the data sitting in the cache before notifying the host computer that the data is ready. This allows the firmware to trick the host system into executing arbitrary code.
[MalwareTech] uses this ability to load his own custom Windows XP bootkit called TinyXPB. All of this software is small enough to fit on the hard drive’s firmware. This means that traditional antivirus cannot detect its presence. If the owner of the system does get suspicious and completely reformats the hard drive, the malware will remain unharmed. The owner cannot even re-flash the firmware using traditional methods since the rootkit can detect this and save itself. The only way to properly re-flash the firmware would be to use an SPI programmer, which would be too technical for most users.
There are many more features and details to this project. If you are interested in malware, the PDF presentation is certainly worth a read. It goes much more in-depth into how the malware actually works and includes more details about how [MalwareTech] was able to actually reverse engineer the original firmware. If you’re worried about this malicious firmware getting out into the wild, [MalwareTech] assures us that he does not intend to release the actual code to the public.
And again: “Full Disk Encryption saves your day” .. “almost”
The rootkit is only effective if the data written or read from the hdd is in the clear.
However there is an attack on encryption, working only if there is no data integrity algorithm in place.
You would recognize missconduct of your harddrive by integrity errors
Making the day wonderfull.
And I forgot the “unencrypted” bootloader
I must boot from usb-sticks at anytime ..
And the usb-sticks can potentially have their own version of such malware (each and every usb flash controller have a 8051 core at the very least, and they are reflashable). So – can one make a hardware implementation of any boot device (without integrated CPU) and with only ROM memory?
Also – any boot mistake would be fatal (boot from such infected hard drive instead of your proper drive).
I’m looking for tools to discover the real capacity of ‘fake’ SD and micro SD cards then correct the capacity to make them usable.
There is a tool I found a while back. Meant to test i/o speed of flash drives. But it also wipes all data and fake partition tables. Photo rescue Cardwiper 1.03, before you start it you select it to use “physical drive” then let it run. Can be found as “cw103.zip” very useful and small tool to have around.
@Nova Download here http://www.datarescue.com/photorescue/freefiles/ Doesn’t show any drives until I select the Physical Drive option then it shows all the drives but sits there with the test and wipe buttons greyed out, and all the empty slots in my multi-slot reader forever stuck on determining drive size.
What I read on it while searching for it, it fixes drives incorrectly set to be *less* than their true capacity rather than incorrectly more than their true capacity. I’ve tried various full wipe/erase tools and they all just read the bogus data from the flash chip. That’s what needs reprogrammed to match the actual memory chip capacity.
@Galane Hmm sorry to hear that! I purchased a “128GB” drive from ebay and used that tool on it, it resulted in wiping the partitions and I was able to reformat it properly after, was a 4GB, got my money back also as a result! “As-is” ! = counterfeit.
Also yes I believe for logical drives it can’t go past 4GB or something silly like that. Also if it’s greyed out that means it’s either a system drive or it doesn’t see it as a proper device, I think some card readers can cause this but YMMV.
Wow, lots of utilities mentioned. Formatting a SD is *not* like formatting a hard drive. On a hard drive you can use any combination of cylinders, heads, sectors and sector lengths that multiply out to the actual number of sectors etc. It doesn’t matter as it’s all logical block addressing and as long as the data comes back from the same place it was put then all is good.
SD cards however have a limiting feature. Blocks have a specific size and can only be erased in units of that size. To write to a SD card, the CPU writes to a block that is marked as blank. It then changes an index to point to the new block and erases the old one. If you specify a block size that doesn’t match the hardware then the SD card will be slowed down quite a lot as it tries to erase enough block to support writes of the wrong block size.
If all else fails or you simply want to use a formatter that you know will work to the standards then try this on from the sd standards website –
https://www.sdcard.org/downloads/formatter_4/index.html
If by “FDE” you mean software encryption then sure.
However SEDs that use hardware encryption would be susceptible to this attack because although data is encrypted when transferred to and from the media, once the drive has been authenticated the data being cached on the PCB is in the clear.
“…he does not intend to release the actual code to the public.”
or the NSA?
Nah, they already have a copy…
I’m sure it’s straight out of the NSA’s ANT catalog.
The nsa has actually been doing this for some time. There was a very interesting article about it on arstechnica some months back.
http://arstechnica.com/information-technology/2015/02/how-hackers-could-attack-hard-drives-to-create-a-pervasive-backdoor/
The antivirus cannot detect the malware present in the firmware but it can detect the malware injected in the executable that has been altered on the fly.
That is not how it works, the firmware just acts as as a gatekeeper to keep a rootkit hidden on the drive, no matter what you do, and the root kit boots before and under your entire operating system so your antivirus software is useless.
Rootkits can be detected without problems as well. The thing is, there are many legitimate rootkit use cases (DRM, DRM bypass, security software, game hacks, reverse-engineering tools, hypervisors) so no rootkit detection toolkit will give a definite classification whether the rootkit is malicious.
Literally there hasn’t been a single method of persisting malware that hasn’t been eventually detected, either by direct or side-channel methods. Now that HDD firmware vector has gained some attention (mainly thanks to the NSA leaks), we’ll see firmware security looked at more seriously.
I dont think many people in the know would consider DRM a legitimate use case of rootkits, but at least you included DRM bypass ;)
Sprite_tm has some interesting stuff to say about this, https://spritesmods.com/?art=hddhack only he didn’t try and scare everyone with it, just did all the work and presented it last year….. Just sayin…
SUPER weird that hackaday lacked the journalist integrity to link back to that original article… they failed to search their own blog? wtf
That’s not what integrity means. English not your first language? I haven’t seen Rick’s name around much, maybe he’s only been working here since after that article, which I also remembered. The HDD in question used an ARM I think. Just like everything else.
Just a thought, should we all start criticising each other’s grammar / spelling / typos? It would give Mike Sysczczzys a break, and eventually he won’t even have to bother writing articles any more, just spell a few words wrong and the posts will roll. Make his job a lot easier.
If the computer can read the virus in order to execute it (or boot from it), then it can read it for a virus scan. Unless the virus was REALLY sneaky, and detected a virus scan and neglected to add itself to the cache when that happened. You can’t directly detect a virus search, but reading every file on the disk, in quick succession, is a pretty good hallmark. Windows and programs might do a lot of reading, but not from lots of directories one after the other.
The trick would be detecting the scan in time. Usually a boot sector scan is done first.
Still, nice to see a boot sector virus again. When we all moved away from booting from floppy drives, they disappeared and program-bound ones became the norm. According to some website, the last boot sector virus fell off the Wild List in 2006. Probably the last Atari ST user. Great pirate scene, riddled with viruses! Still it goes away when you turn the power off.
Although since this presumably doesn’t replicate, it’s a trojan, not a virus. Maybe one could alter the NSA’s equat10n-drug (that ought to confuse echel0n!) to make it self-replicating. Have every hard drive in the world emailing them nonsense, teach ’em to be careful what they wish for.
Well the thing is that once the activation code has executed there is not much the computer can do. Even though it is now storing data on the hard drive, since it is the hard drive, the cpu is never notified and if the cpu or anything else request the contents of the drive it just excludes the “secret package.” Unlike traditional rootkits and malware in general, the only party aware of the operation is the drive itself.
So the hard-drive virus sends it’s package on bootup, but a normal fake bootsector afterward? That would do it, simple and clever.
R.I.P. dejan, the work still goes on.
This is probably a great example of the tricks the NSA has in their utility belt
It is-
https://nsa.gov1.info/dni/nsa-ant-catalog/
“assures us that he does not intend to release the actual code to the public” …. Right, because he is the only one capable of creating this. Now that people know it’s possible, it will end up getting duplicated. This is why vulnerabilities get embargoed until there is a chance to fix them.
This is actually old news. It’s been ‘known about’ for 6 months or more. I saw a paper on it some time ago. I would expect that it is already in the wild, in use by the likes of NSA. Putting malware into HDD firmware is of no great gain to your average hacker as you still have to compromised the system at an OS level to get it there in the first place.
The other notable thing is that HDD manufacturers are doing nothing to prevent his, perhaps because most people can’t use a SPI interface to get rid of it so they would just have to hand money to the HDD manufacturers for a new one. Join me in frowning at HDD manufacturers. :( :( :(
If your system if properly protected at an OS level by good anti-maleare/anti-virus and safe practices then this thing won’t get to your hard drive.
All hard drive manufacturers are aware of this and have been working on counter measures since the leakage of the NSA’s ANT catalog.
or have received a lot of money (or pressure) from the [nasty words removed] NSA to still make this kind of things possible… :-(
I’d like to believe that. Where are the manufacturers in question based, anyway? And do we need to worry about the just as depressingly inevitable conscription of our hard drives into spying for the Chinese? Hard drive encryption would solve that partly, but the HDD could always serve up an .exe with extra instructions for spying on keyboard inputs or whatever, to retrieve the key from the user. It’s a very difficult problem, protecting your computer when the components themselves are spying on you.
Might be that the first manufacturer to crack it, could make some hay from advertising the fact that their competitors haven’t. Although that’s assuming the spooks don’t have the MDs family locked up in a container somewhere. Or threaten their share prices, which is even worse.
Most people might not care, under the “nothing to hide” fallacy. Ignoring the fact that that’s only safe as long as the government is morally good and agrees with you on the important things in life. And that they don’t have some vindictive dick working for them who abuses his power, whaddya think?
It’s a very difficult problem. Perhaps PGP-signed firmware would help, with the checking done by a chip with real ROM. Or just using ROM firmware, after all how often do most people flash their drives? Or at least putting a jumper on the flash’s write enable line, so you deliberately have to enable it. That would help solve a number of related problems actually.
Still so far there hasn’t been a console that wasn’t mod-chipped, given enough time. The latest ones haven’t had enough time yet, tho they’re getting better, and ever-larger-scale integration helps, even when the hackers are using electron microscopes. Atomic force microscopes are a game ahead. Although I believe somebody on .io is working on one!
Tho, as I said before, if the CIA will happily knock over democratically elected governments, in favour of insane fascists who’ll sometimes do their bidding, they’re not gonna worry about messing with a few million microchips. Probably only so much you can do, as chips get smaller and more stuff squeezed on, the stuff you can do to keep dirty fingers even out of your own design, is limited. Perhaps an open-source HDD firmware would be interesting. I know each model varies, but a framework and common features might be worth having. It would really drive interest and knowledge in the subject up too.
Just to tastelessly follow myself up, would it be feasible to attach a resistor from the flash’s write enable line, to GND or +V? To tie it up? Or cut a trace? I know microcontrollers come with flash onboard, depends if the ones in hard drives do or not. Which depends on how much code they’re running. And affects price so I suppose it’s something they’ll knock off if they can.
That said, what about fuses? Could you blow the code’s write-protect fuse over SPI, or with a full programmer? Just as a prophylactic antidote to the CIA hijinks mentioned here.
This could even be a small market for this among paranoids / extremely wise people. A little PIC chip or whatever, programmed to connect to a particular pin on a chip on an HDD, and issue the fuse-blowing code. Tie a resistor or two to a couple of pins to specify which particular type of chip the HDD uses.
been done before, http://spritesmods.com/?art=hddhack
And more recently than that, the entire “equation group” kit of software. They appear to be NSA, but the payload of the several different rootkits have proven difficult to decode.
Previously, on Hackaday:
http://hackaday.com/2013/08/02/sprite_tm-ohm2013-talk-hacking-hard-drive-controller-chips/
This has been around for years as a spying tool, implemented not just in software but also hardware. Short of creating your own processor from scratch (and veryfying the machine you instructed to burn the die didn’t add something a little extra in hoping you wouldn’t notice) you’ll probobly never know. There’s a lot of hardware between you and the comment you last posted. Imagine how fast your computer could be if every cycle was actually your own, granted most are concurrent but think of those people tapping that big optical fibre down in cornwal. If they used this sort of thing as a filter, they don’t have to sift as much data and they can have more of a real time dashboard.
What if the next post you wrote seems normal from your side of the screen but was sensored on the other.
You could use this to skip over a few megabytes of hard disk and extend the functionality. Since everything goes through the chip you’d never see it.
We had a post on here a while back about SD cards with more space than they actually display they have. How big has windows gotten these days, who has the time to check every byte.
When people know they are free they stop looking for a way out. Sometimes it’s easier to say I’m free enough. I’m happy and I don’t care if someone in an office knows I liked a video of a cat and I had toast for breakfast last week.
Personally I’m just curious.
“Nothing is true; everything is permitted”
I guess that one depends on how you want to see it.
i thought to flash the firmware you need to connect serially to the 3 pin connector on the back of the drive.
If you know the commands you can do that on many/most drives. If you don’t direct SPI access to the flash is certainly easier. Probably you can also find many readymade tools for working with SPI flash, while for the proprietary flash interface there is probably only one from the manufacturer.
Dell, HP and other OEMs often have hard drive and optical drive firmware updates for drives that originally shipped with their computers. Used to be they had to be flashed from DOS, often working only from a DOS boot floppy. I’ve run into a few that checked to make sure the boot floppy was created by the OEM’s self extracting/writing program.
More recently they’ve gone to flashers that run in Windows or if still requiring to be flashed from DOS will run from any DOS bootable device, with just about any version of MS-DOS or clone. I keep a small old USB stick for those.
Same story with motherboard BIOS flashers.
The way to make hard drives to still allow firmware updates over the regular data bus would be to use a PROM chip to store a challenge/response, the answer to which is a unique code printed on the drive’s PCB. (Could print or engrave it onto the case but that would make PCB swaps for repairs difficult or impossible.) That code would have to be typed in by a human. There are many ways to block a paste into an input field. That’s been used by companies that try to make it harder to ‘pirate’ their software using keygens. The difficulty here would be making it impossible for a malware flasher to be able to generate a valid response code to the challenge. Every drive would have to have an absolutely unique response code with no way to generate it based on the challenge. See this XKCD https://xkcd.com/936/
Stage 2 using challenge/response with that un-alterable code in PROM is to zero fill the cache then write protect it, then zero fill the EEPROM or flash chip, or design the programming system to simultaneously zero fill all writeable firmware and RAM chips on the drive while also locking out write access to the RW heads or solid state storage chips – leaving the malware nowhere to hide before the new firmware is written. Measures would also have to be taken to block the malware from moving through the data connection to hide in the host RAM then re-flashing itself back to the drive after the update is finished.
That un-alterable code could have a ‘bare bones’ firmware into which the flasher software could reset the drive – containing no code for reading and writing to the data storage. The trick there would be making it impossible for any code in the firmware chip from intercepting/blocking that reset to fool the flasher.
The ‘downside’ with such methods is it would not be possible to flash the boot drive for the operating system while the OS is running. To flash non-boot drives would be possible by un-mounting or disconnecting them before running the flashing program but that would make it harder to secure the drive against re-infection from malware running in the host OS. ‘Course a drive that cannot be flashed from an OS booted off it because it must be un-mounted *should not* be able to have its firmware infected by malware.
Problem with that is using a keylogger you can get the likely keystrokes of the password. Maybe something mouse-based, it would at least be a bit more difficult, if you make a few extra clicks outside the input icons to confuse mouse-logging. And move the icons to random parts of the screen, even have them move about between clicks. Or use letters instead of icons, same principle, just avoids the easily-tapped keyboard. Which you have access to before boot, although I dunno how big a USB keyboard driver has to be. I’d guess not big, for a minimal one.
Have it as an option in the boot menu, “unlock hard drive for re-flashing”. Sure it’s a bit complex, but if you don’t understand it you’re a menace to your own drive firmware anyway. As an extra, say, 5 power cycles later, it switches off if you forget to do it.
Secure, keylog-proof input systems is a whole area of research, sure there might be better ideas than mine.
I would assume that is not way for the malware to infect the drive, unless a new firmware is flashed.
In other words, you would not get infected like a traditional virus or malware would do (from some arbitrary code running).
Drives allow reprogramming via vendor specific commands, you do not need to connect programmer to harddrive to update firmware.
Why the HD manufacturers don’t put a physical switch that makes the flash memory write protected by default, if you want to upgrade the firmware you just unlock the HD temporally?
How many non tech savvy people really think to simply unplug the network cable.
That switch would cost money. Also, most people would never use it.
A number printed on the HDD, and stored in WOM, that is required to flash that disk firmware (and change the number).
This is the problem we have with the language used around ‘boot’ like boot-loader boot-code boot-strap boot-sector.
The FLASH chip in a HDD is on the other side of a micro-controller so the only access you have to it from the OS is through the code (also in the FLASH) running on that micro and updating the FLASH for you. Unfortunately that same code will allow you to change specificly that code to some code that wont allow you to ‘update’ the FLASH or pretend it’s being updated or whatever that new code intends to do.
Think of the code in the FLASH as being like the ‘boot-loader’ in an Arduino but with the difference that it will allow you to change the ‘boot-loader’ to something else.
Connecting directly to the FLASH with SPI bypasses the micro altogether so it can’t interfere.
So to explain ‘boot’ I will work backwards using Windows as an example.
When windows ‘boots’ (*** boot is now incorrectly used to describe everything in the boot process so I will follow this convention ***) it loads files from the hard drive via the protocols used on the hard drive like the FAT32 or NTFS file system. This is not actually anything to do with booting because something came before that.
Before an OS can load (an OS doesn’t boot – it loads) from a file system it first needs to run code that allows it to see the data as a file system. This first bit of code comes from the boot-sector of the Hard Drive and is code that *isn’t* implemented within the native file system as it is accessed prior to the system being able to read files. Sometimes this is called the boot-code.
But something happens before that because the hard drive is just a bunch of 1’s and zero’s scattered around in random hardware locations that is different for different machines made by different companies so some code has to run first for the hard drive to be seen from the CPU as a hard drive rather than random 1’s and zeros.
The BIOS (Basic Input Output Service) is a code that loads from the BIOS FLASH chip before anything above. It’s purpose is to make the hardware conform to a software standard so that we don’t need 3 billion versions of windows to suit the 3 billion different versions of hardware.
So here it is –
BIOS – the first code that runs that implements some standards so the OS can run on generic hardware. It’s made by the hardware manufacturer specificly to suite the hardware. Technically this is the ‘boot-strap’ but BIOS is most often ignored as it is not well understood.
Boot-sector – The BIOS then loads the code from the boot-sector of the hard drive. This is what, by definition makes the BIOS a ‘boot-strap’.
Boot-code – The code from the boot-sector is often called the boot-code though technically the BIOS itself is a boot-code. The convention is that code from the boot-sector is called boot-code.
Boot-strap v2 – When the code from the boot-sector is executed it performs the function of a ‘boot-strap’ for the operating system (OS). It’s purpose is to load in more code to get the OS under way. It allows the HDD to be seen as a file system and then next code that is loaded is a file. On older OS’s it was COMMAND.com that was loaded by the boot-code.
With micro-controllers there two additional boot options even before all of the above. One is a proprietary boot-loader and is normally implemented in a on-chip ROM that can be switched on (via a pin signal) and run code (a boot-loader) on the CPU.
The other is the lowest level. The most common example is JTAG. JTAG overrides the CPU so there is *no* code running. That is why most devices that don’t have a CPU (like FPGA) have a JTAG interface. There is nothing that can be done to interfere (viruses etc) with JTAG programming.
And in the case of a hard drive there is also the option to write to the FLASH directly with an SPI interface.
Most people never update their drive firmware, true. But this rootkit does. That’s what the switch is for. You could even mention it on the box, though I don’t know how you’d phrase it. Extra protection, people would buy that. A few pence for a switch or a jumper.
Next best option is just don’t allow firmware updates at all. I’ve never used one and I’m a geek. Would piss the CIA off, maybe that’s a factor.
Doesn’t have to be a switch, most HDDs already have few pins on the back, usually used as serial port. They just have to add function to make flash read-only until Tx pin is pulled low, for example.
Yep but the update function is for users, most of whom don’t know how to pull pins low, a switch is something everyone understands.
Why don’t hardware manufactures but a back up base firmware in ROM on the drive, if you think your firmware is corrupted you just push a little red physical button on the HD itself and it totally rewrites the corrupt firmware with the firmware in the ROM, sure may have to upgrade the firmware to the latest version afterwards but you sure as hell know your firmware is clean.
The little button may as well be a switch or jumper you have to set to allow updates in the first place, since “updates” are the enemy.
Or, you know, only let the HDD accept signed firmware updates. Which most of them already do, unless I’m misunderstanding the exploit.
And if someone can manually swap out your HDD then you’re already pretty screwed that someone wants to do that to you/can get at you anyway.
JTAG lets you pretty much override everything, and you can hack the firmware to either ignore the signing,. change it or even make it look valid. This is physical access, you could even just grab a batch of drives and replace the chip with the firmware as quickly as you could setup the flash (for the ones with small pin count flash devices at least)
The rootkit in question doesn’t need physical access, it can install from software (trojan) on the PC. The TLAs infected half the damn world with Stuxnet just to get to a few computers in Iran.
yeah, it doesn’t , but as they point out in the doc, the physical access via spi/jtag means alt means to infect if it was locked down
Yep but that’s a whole lot harder to do, than just releasing something to a warez site and get the whole Internet sneezing. Actually breaking in and getting hold of people’s stuff leaves lots of evidence, and needs court orders. Well it’s supposed to, y’know.
If an attacker has physical access you’re fucked in many more ways. This thing here is just a very very clever bit of virus writing.
Yeah but then the spooks just demand the key. When your own government wants to spread malware, that isn’t enough. As plenty of people including me mentioned, a little switch would fix this. But will they be allowed to do it?
99% of malware devs either don’t have the time or don’t have the skill to do this. A wealthy Russian botnet owner is going to stick to FUD crypters and published exploits. Their bottom line doesn’t change..
Business people care about economics and profit-models they don’t care about impressing security researchers and struggling to beat HIPS and signature engines just to do so..
It’s also worth reminding that different drive controllers have different internal ROMs so there is a nasty test-cycle for anyone who tries to properly do this with any device ROM..
I think I had something similar to this early last year, and it was a botnet. I wiped the drive twice over in different ways. The second time was several passes of random 1’s and 0’s. Within 30 minutes of re-installing windows after the first wipe, my CPU was maxed out, task manager was locked down (trying to stop the offending process essentially locked the computer), and there was a ton of network traffic. I tried updating the BIOS, thinking that it was possible to hide some malware there. Then wiped the drive the second time. Re-installed windows and was hijacked again. I wiped it a third time and installed Linux. Whatever it is, it doesn’t work on Linux (that I can tell.)
I haven’t seen it done outside of state malware. Again, there is no reason for the owner of a spam or financial botnet to invest in hardware persistence.. A $200.00 FUD crypter or even a self-wrote XOR stub will get you past any HIPS, signature engine, and even offline signature engines like with “rescue disks”.
Malware authors know AV vendors leave AV designs like this to support their profits via subscription services..
Whatever it is, it doesn’t work on Linux (that I can tell.)
Maybe it WAS Linux trying to install itself on your PC.
Then when you did it voluntarily, it had no more reason to do so…
B^)
The hard drive manufacturers are in cahoots with the NSA. That is why I am typing this from an Atari 800.
Oh you modern prettyboys with your color hi-rez displays. If you want REAL security you do it with core RAM and inch-wide paper tape. Once the PDP-8 prints this on my Model 33 Teletype machine I can use the printouts to heat my house, too.
I used to use an Atari 800 but I used the foil shielding from inside it to make a hat. Now I read HAD on punched cards.
Given how much shielding was in the A800 you must have some seriously strong neck muscles by now.
I just use my loom. It’s very secure and works wonderfully… except it sometimes gives execute commands instead of taking them.
Some hard drives store their firmware on the platters in an OS inaccessible section. The very bare bones code in a chip on the PCB loads the main firmware to operate the drive off the platters. Maxtor was infamous for using this method because some of their models with it had a tendency to corrupt that area.
There is special hardware and software, and supposedly a software only solution that runs on an ordinary PC – with the undocumented jumpers jumped properly, to enable re-writing the drive’s firmware to the platters. That’s assuming a firmware file is available – which it ain’t for an older 32 gig IDE Maxtor I’ve had for a while. I don’t know if there’d still be anything on the drive I’d like to get back – but that entire family of Maxtor (IIRC it ID’s itself as a MILLENNIUM) there’s nothing can be done because nobody ever pried the firmware files out of Maxtor. If it was any other platter firmware IDE family from Maxtor…
it’s actually not something new. i remember reading about this on the kaspersky pdf about “the equation”, it was one of their attack methods
and this is really scarry
So, when can we expect Arduino-based antiviruses that check firmware integrity on HDD via JTAG?
This. This should and will happen. Everything with a JTAG interface wired in.
What’s interesting here is that when snowden revealed the NSA was doing this there were people saying that would only be possible with the support of the HD manufacturers, but now if we see an amateur do it it means that might not be true.
Which is depressing news in a way since you can’t for instance buy a non-US company HD and hope that helps against the NSA :/
Sprite_tm did this a while ago, so that’s two individuals not associated with HD manufacturers.
Considering the state of disassembly tools, and that most HDs use known micro controllers, attaching to JTAG and pulling the firmware out to take apart shouldn’t be that difficult for a large state agency. A few specialists working 8 hour days to figure out all the commands that need to be in the firmware, and a few others adding new commands into what ever space is left over . . . I guess it would be nice if there were a good way to destroy that leftover space after the initial firmware, but that would prohibit upgrades.
I guess it’s good that there are hackers that do it, that at least encourages the HD makers to think of a solution like you started to do.
I guess they could fill the leftover empty space with a pattern of bytes and have a checksum in the firmware to check the ’empty’ space is empty, as in still corresponding with the checksum for the pattern.
That way when a new official firmware is put in you just have a new pattern and a new checksum. But you’d have to protect the firmware from tampering so they can’t defeat that check. But then you are looking at us having to trust the HD manufacturers don’t, voluntarily or forced, play along with the security services of this sometimes nasty planet.
I would just like to draw people’s attention to a part of Dan Kaminsky’s talk at last year’s Defcon. How about serial console access to hard drive firmware?
https://youtu.be/xneBjc8z0DE?t=3m33s
The access did enable people to revive their seagate drives when it had that stupid countdown issue in its firmware that killed drives. So it had its good sides.
“We just developed this really scary megavirus. You can read about it in our pdf!”
Is anyone else laughing really hard about this?
There is also a way to encode this into the (4-64MB) Flash chip on external DVD/BRD rewriters.
Last vector you’d expect, and it could easily spread bits of itself into normally unused sectors on a disk just before closing a session which then get dumped back to the victim machine the next time they reload their OS using one of the infected disks.
I am actually trying to reverse engineer a drive the moment, some drives notably the slimline externals seem to have a particularly gnarly bug which causes them to stop writing after a certain number (about 99) DVDs yet there is nothing wrong with the laser as it reads fine and still writes CDs.
A similar problem also exists on some slimline laptop drives which causes them to completely stop reading CD/DVD disks but if you reflash the firmware with the same version it starts working fine so it is obviously some sort of buffer overflow-like effect.
not frighteningx, no frightened for such or any
I guess I have exactely this. After complete Format and Re-Install of Windows 10 (whithout connected Internet) and even re-flash my BIOS (using an external Hardware programmer) My System ist immediately highjacked as soon as I connect to the Internet. I even blocked Internet within the Windows-Firewall without any effect (except Internet did not work for ME) but there was access from outside.
Did this Procedure several times and two SSDs are affected.
Trying to upgrade the SSD-Firmware of one of the drives fails at ATA-Command 0x92 (send microcode). The tool is genuine and upgrade should work.
Whould be really nice to extract this little beauty! Help is appreciated.