Firmware on Toshiba...
 
Notifications
Clear all

Firmware on Toshiba HDD

15 Posts
7 Users
0 Likes
2,502 Views
(@swheeler)
Posts: 4
New Member
Topic starter
 

Good afternoon everyone,

I have a puzzling case I am working and need your help. I have a Toshiba HDD from a laptop that was sent to me for analysis. The employee that seized the laptop allowed bad guy to have access to the laptop to "unlock it" for said employee 0 Needless to say, the employee saw the Windows splash screen and then what he described as a black screen with white letter (possibly command line). The employee said bad guy typed something in and the screen went black. I know, I know…….

Anyways, now to the lab portion of this. I connected the HDD to a Forensic Falcon, which sees the drive and all its data (size, serial number, LBA, etc.), but has ALL read errors, from start to end when I try to image it. I've tried to iSCSI to the drive to see what's on it and it freezes my FTK Imager. I have booted to Paladin and attempted to image and again ALL read errors. I have read the S.M.A.R.T. data on the drive and it does not show any raw-read-error-rate is 0.

According to the employee that seized the laptop, the bad guy is very computer savvy and had LOTS of hacking software and "how to go undetected by the government" documents (unfortunately not seized for my viewing). My question is this…does anyone know of a command line or executable that will easily corrupt the firmware or tell the firmware that it is bad? The firmware is the only explanation that I can come up with for the drive having ALL read errors, when the employee just saw the bad guy on the laptop. If he wiped the drive, I should still be able to image it.

Any help would be greatly appreciated. Also, I don't have a power cable to boot to BIOS so I have none of that data.

Investigator Wheeler

 
Posted : 14/02/2018 9:02 pm
(@bntrotter)
Posts: 63
Trusted Member
 

There are all sorts of nasty boot bombs out there. They could have started a format process, zero out process, or overwriting the MBR or File Table.

Options
1. Hardware Imager
2. DEFT/CAINE Discs
3. Encase Imager
4. If all else fails, clone the Suspect Drive > Analyze the Clone

 
Posted : 14/02/2018 9:27 pm
Passmark
(@passmark)
Posts: 376
Reputable Member
 

bntrotter,

I don't think your comments make sense. OP has already tried hardware and software imaging, which seems to have failed.

swheeler,

Do you have any details about the type of the error? e.g. CRC.
Might be that the drive was encrypted and the password was rolled over.
What model hard drive it is? Does it support SED

See also
https://www.pcworld.com/article/225392/toshiba_self_encrypting_drive_has_promise.html
"Toshiba has introduced a series of self-encrypting hard drives that come with what the company says is a unique self-diagnostic feature that blocks access to data if the drive doesn't recognize the host, in case it is lost or stolen …… a feature that deletes the keys required to decrypt data when a drive is removed or is connected to an unrecognized host."

Might have been a bad move to remove that drive from the host.

 
Posted : 15/02/2018 4:00 am
(@einstein9)
Posts: 50
Trusted Member
 

@swheeler

as a DR (Stands for Data Recovery) opinion i can tell you this is a common G-list issue with Toshiba drives (specially the new models)

better you seek a DR firm asking for a Clone of the drive if possible.

 
Posted : 15/02/2018 8:15 am
(@swheeler)
Posts: 4
New Member
Topic starter
 

bntrotter,

I don't think your comments make sense. OP has already tried hardware and software imaging, which seems to have failed.

swheeler,

Do you have any details about the type of the error? e.g. CRC.
Might be that the drive was encrypted and the password was rolled over.
What model hard drive it is? Does it support SED

See also
https://www.pcworld.com/article/225392/toshiba_self_encrypting_drive_has_promise.html
"Toshiba has introduced a series of self-encrypting hard drives that come with what the company says is a unique self-diagnostic feature that blocks access to data if the drive doesn't recognize the host, in case it is lost or stolen …… a feature that deletes the keys required to decrypt data when a drive is removed or is connected to an unrecognized host."

Might have been a bad move to remove that drive from the host.

The drive is a Toshiba, model MQ01ABF050, not the MX model that supports SED. I don't believe this model is a SED, but I may be wrong. As for the error type, Forensic Falcon is not giving me an error type. In fact, it doesn't actually appear to be reading the sectors. I think the drive is locked an it is just going through the motions.

I attempted additional troubleshooting and connected the drive to a Logicube Dossier. The Dossier could not image the drive as it said the drive was "locked." If the drive is merely encrypted, I should still be able to get an image still, the data will just be random. Now if the BIOS/Firmware is password protected, then I won't, correct?

 
Posted : 15/02/2018 2:41 pm
jaclaz
(@jaclaz)
Posts: 5133
Illustrious Member
 

I attempted additional troubleshooting and connected the drive to a Logicube Dossier. The Dossier could not image the drive as it said the drive was "locked." If the drive is merely encrypted, I should still be able to get an image still, the data will just be random. Now if the BIOS/Firmware is password protected, then I won't, correct?

Could it be a (more generic, i.e. not Toshiba specific) ATA PWD "lock"? ?

I don' think that there are ways (software, without a specific hardware connection to diagnostic/TTL ports or similar) to actually clear G-Lists or however modify the ROM/firmware, while setting an ATA password lock is possible.

jaclaz

 
Posted : 15/02/2018 3:32 pm
(@swheeler)
Posts: 4
New Member
Topic starter
 

I attempted additional troubleshooting and connected the drive to a Logicube Dossier. The Dossier could not image the drive as it said the drive was "locked." If the drive is merely encrypted, I should still be able to get an image still, the data will just be random. Now if the BIOS/Firmware is password protected, then I won't, correct?

Could it be a (more generic, i.e. not Toshiba specific) ATA PWD "lock"? ?

I don' think that there are ways (software, without a specific hardware connection to diagnostic/TTL ports or similar) to actually clear G-Lists or however modify the ROM/firmware, while setting an ATA password lock is possible.

jaclaz

jaclaz,

That is what I am beginning to think. Are you aware of a forensic tool that can detect if there is an ATA password on the drive?

 
Posted : 15/02/2018 3:40 pm
jaclaz
(@jaclaz)
Posts: 5133
Illustrious Member
 

That is what I am beginning to think. Are you aware of a forensic tool that can detect if there is an ATA password on the drive?

Atola Insight
http//atola.com/products/insight/password-removal.html

but to only detect if the ATA password is set MHDD would do nicely
http//hddguru.com/software/2005.10.02-MHDD/
or *any* Linux with hdparm.
(Windows versions of hdparm might work as well but in some cases the "new" i.e. Windows 7 and later drivers may conflict with it)

jaclaz

 
Posted : 15/02/2018 4:10 pm
(@athulin)
Posts: 1156
Noble Member
 

The employee that seized the laptop allowed bad guy to have access to the laptop to "unlock it" for said employee 0 Needless to say, the employee saw the Windows splash screen and then what he described as a black screen with white letter (possibly command line). The employee said bad guy typed something in and the screen went black.

Sounds remotely like unlocking on-disk encryption or BIOS password. That is, based on the amount of details you have given, I don't see this as definitely weird (except for that other employee …). (I have to make a number of assumptions about UEFI boot, what subsystem shows the splash screen, and just possibly about if the disk was a system drive or a data drive.. In the absence of facts, that is not a problem.)

I connected the HDD to a Forensic Falcon, which sees the drive and all its data (size, serial number, LBA, etc.), but has ALL read errors, from start to end when I try to image it.

Here's one of the places where facts could help what disk exactly are you talking about? Is it self-encrypting? Or, has it been configured to enable ATA security modes? Is it a UEFI boot?

Unless you can say definitely NO to each of those questions, this does not seem to be a problem either.

I've tried to iSCSI to the drive to see what's on it and it freezes my FTK Imager.

Why? What did you think that would change? (Here's where I'm beginning to scratch my head …)

According to the employee that seized the laptop, the bad guy is very computer savvy and had LOTS of hacking software and "how to go undetected by the government" documents (unfortunately not seized for my viewing).

Just the kind of person who might use a self-encrypting drive, or enable ATA Security.

The firmware is the only explanation that I can come up with for the drive having ALL read errors, when the employee just saw the bad guy on the laptop. If he wiped the drive, I should still be able to image it.

I used to say that unless you can come up with a dozen explanations tp any forensic anomaly, you're too green to do the job. I have had to eat crow over that that, so now I usually say 'half a dozen'. I'm not sure I can do it in this case, so I may have to eat crow again …

A one-hypothesis person will usually focus on that hypothesis, and enter tunnel vision mode, and basically become useless.

Go on, make a list of possible explanations to what you face. Don't erase any!

My first hypothesis is that the disk has enabled ATA security, that is, it has a password set. Unlock only unlocked it temporarily, and now it has locked up again. Locked drive refuses to read, so you get read errors.

Test check original disk with hdparm or equivalent. Create a second disk, enable ATA security, set a password, and boot it. Does it 'look'the same as the scenario you described? Does it work the same with FTK imager, i.e. return error messages?

My second hypothesis is that the disk was configured with ATA security in such a way that changing user password deletes the data. (I think it's called 'maximum security') (Doubtful, as I don't think this returns errors, but … )

test Create a HDD, and set it up that way. Erase user password – does the disk now behave in the same manner as you observed?

Third hypothesis self-encrypting hard drive, with its own special features. Needs a manual from the manufacturer to device a test.

Test Check documentation does this particular make of HDD do self-encryption? If it does, find a manual and learn what other features it has. Particularly, if chagning passwords or such changes access to previous data.

Forth hypothesis It's a plain hard drive, but bad guy booted kali or something similar from an alternate boot, and ran a pre-created script to impede investigations. Perhaps he just reset DCO or HPA to the entire drive, and the errors you see is the disks subseqent failure to read sector 0, because DCO or HPA now starts at sector 0. If that's even possible (never tried, admittedly), it's just what could cause a disk to return errors.

Test Check detailed error message. What is the error really attempt to read sector beyond end of drive? Or something else? Check HPA and DCO configuration of drive. Find alternate boot environment. (Might be too late for that. I'd probably keep a mouse that also contained a USB storage, and boot from that. Or keep one in the dock UCB, and only hand over the laptop itself. Or … well, see below)

Fifth hypothesis … from now, all ideas I have are based on alternate boot possibilities, which are basically the same as before, but differs as to what happened.

The only one I think can be tested (unless you are able to locate the alt boot) involves reflashing the drive, but that would basically make the drive incommunicado. Best tested by trying to talk to the drive using hdparm and such tools. However, if FTK Imager didn't complain about the drive refusing to talk – and probably also Windows (did you check system logs?), it seems unlikely to have happened.

Sixth hypothesis You're looking at the wrong drive.

I'll leave that one as an exercise. Yes, unlikely.

(yay, half a dozen hypotheses … !)

It seems that you can exclude just about anything that requies decryption software from the disk itself to be executed. If the laptop does have TPM, you may want to find out if there's any standard form of disk encryption that uses other boot forms, such as PXE boot, for example.

(Of course, some of these may be trivial to dispose of, as you presumably know more or less what took place, what equipment was seized, what equipment was examiend, etc.)

 
Posted : 15/02/2018 4:57 pm
jaclaz
(@jaclaz)
Posts: 5133
Illustrious Member
 

(yay, half a dozen hypotheses … !)

Naah, you cannot count those that were already proposed (and partially excluded).
At the most you have a couple "new" ones.

jaclaz

 
Posted : 15/02/2018 5:55 pm
Page 1 / 2
Share: