If there are bad sectors on a flash drive that contain data left over, will they show up on FTK Imager?
So in other words if you encrypt the entire partition of the drive, then attach the drive to FTK Imager, if there are any bad sectors with data on them will they appear separately and unencrypted?
Is there an easier way to identify bad sectors on a drive?
If there are bad sectors on a flash drive that contain data left over, will they show up on FTK Imager?
So in other words if you encrypt the entire partition of the drive, then attach the drive to FTK Imager, if there are any bad sectors with data on them will they appear separately and unencrypted?
Is there an easier way to identify bad sectors on a drive?
What makes you think that bad sectors can be actually read? (to be more exact, what makes you think that FTK Imager can actually image them?)
Bad sectors are un-mapped (actualy their address is re-mapped to a good sector).
Any tool reading what is "exposed" to the interface won't see them.
Some dedicated tool (hardware and software) capable of imaging the contents of the actual chips, including ECC and what not (and capable of interpreting the result) may actually be able to access those "bad" sectors, though most probably (it may depend on specific controllers) without actually knowing where on the Physicaldrive they were before being re-mapped, but in any case if a sector is actually "bad" (and detected as bad by the controller and removed from the pool of addressed sectors) its contents are more properly to be considered "undetermined", meaning that it is possible that
1) the sector still contains the original data because it was marked as bad because it did not accept a new write (and the write integrally failed)
2) the sector only contains part(s) of the original data because it was marked as bad because it did not accept anew write (but *some* new data has been written nonetheless
3) the sector contains only garbage because it was marked as bad because the ECC (or *whatever*) didn't validate, i.e. what was actually attempted to be written to the sectors turned out to be *something else*
4) the sector contains garbage because it is actually "bad" and cannot be read anymore
The above - more or less - limits the practical outcome to text only and moreover to fragment(s) of text that may be useful even if only a fraction of it (less than 512 bytes) is accessible.
I won't even try to calculate the probabilities of this actually happening, but they must be very, very low.
jaclaz
My experience with Bad sectors is if Encase pukes out during acquisition. Next step FTK imager. If that pukes, try cloning or data recovery steps.
For recovering bad sectors, I have used GetDataBack and recovered some significant amount of data.
My experience with Bad sectors is if Encase pukes out during acquisition. Next step FTK imager. If that pukes, try cloning or data recovery steps.
For recovering bad sectors, I have used GetDataBack and recovered some significant amount of data.
On flash drives? 😯
And AFTER encryption was applied? roll
Or on (older) hard disks? (not encrypted and possibly after having mingled with P-list and G-list)
jaclaz
I thought bad sectors can only occur on flash drives?
I thought bad sectors can only occur on flash drives?
Bad sectors can appear on any kind of disk. Back in the old bad days, a bad sector was a bad sector, and it was up to the operating system to deal with it. So, operating systems kept track of bad sectors, and avoided allocating file content there.
But disk image software will still have to cope with them they don't know how a operating system established a bad-sector list, so they will hit all those bad sectors.
Today, disks do bad sector handling on their own, and you rarely see a bad sector, unless something disastrous has happened. If a disk is really BAD (which should be possible to see from S.M.A.R.T. information), the disk may have remapped all additional sectors, and there's nothing to do but return a response identifying a read failure.
To find out what happens when it does, you would want to have a special test drive where you've added a number of known, bad sectors manually. Before you use any imaging software (or any major new release), try it on that test disk and verify that it behaves as you expect.
However … the only source I can imagine for a tool to do that would be the hard drive manufacturer. Someone here may know where to find one.
Not entirely related, but …
I have – very far down – on my to-do list the idea "create a software-controlled hard drive emulator, exhibiting xATA and/or SCSI interface, and following some useful protocol standard level. Allow for the user to set disk size, disk content, bad sectors, and basically allow for any error result a disk may produce. Purpose test imaging software, disk software, OS bad block handling, OS boot failure situations, etc."
Using USB may be easier today – there's some open-source software out there to do the 'make ISO image look like a USB CD-ROM' thing. If all you want is to test 'read failure' that might be the easiest way to go.
I thought bad sectors can only occur on flash drives?
Ok, but again what made you think that? ?
Sometimes you happen to ask a question that makes little sense (to me) like this one.
Clearly this happens because behind the question there is a set of assumptions coming from somewhere (something you have read or heard or experienced) that brought you to a line of reasoning that finally led you to asking the question.
It is likely that either you have some incorrect basics (maybe a leftover from information related to previous technologies) or that you were deceived by one of the n crappy pieces of info you can find here and there on the net.
If - besides asking a question - you can provide some background for it, and share the line of reasoning that brought you to the question, it will be easier to provide a more comprehensive and proper answer, hopefully identifying where/what led you there and - should it be incorrect - provide more appropriate related info.
@athulin
Your hypothetical hard drive emulator would surely be fun to play with.
At which specific software you are referring to when you talk of '"make ISO image look like a USB CD-ROM' thing"?
jaclaz
At which specific software you are referring to when you talk of '"make ISO image look like a USB CD-ROM' thing"?
I think I found two – this is memory of research done at least three years ago, so it's a bit hazy.
One project was called cdemu, located at renosite.com, and involved both hardware and software creation. The idea was to create something similar to those Zalman VE virtual cd devices, or the ISOStick. But it seems to have gone away.
(Not sure if the current sourceforge cdemu project is related in any way – but it seems to be software only, and linux-based, not standalone, so … perhaps not. )
Today I find a lot of apparently related stuff on other hardware platforms, such as DriveDroid, android_usb_msd, perhaps also Easy2Boot etc. I suspect those simply map a file as a USB MSD – but if they allow a general read() interface to data, it might be possible to emulate any-sized drives as well as produce read failures, and that would probably do it. Need to check that up.
Well the CDemu was a nice little project, but it was hardware more than software
http//cdemu.blogspot.it/
https://
https://
There is no end to drivers (software) that can make a .iso image appear as a CD-ROM, with various levels of integration in the OS, this is where we misunderstood each other.
There are similar projects around
https://
http//
Easy2boot is only a (nice BTW) project leveraging on the capabilities of grub4dos (and of RMPREPUSB, by the same Author as Easy2boot).
For booting almost *any* Linux distro's it simply uses a trick originally found by cdob of mapping the extents of a (Linux based) .iso to a (empty) partition slot (keeping the partition ID 0x00) and chainloading it.
jaclaz
