When I add them to Encase, it claims they are 250gb.
How? I mean, from where is that number taken?
It *should* be taken from the hardware – though that can be faked, as already described. (I don't think EnCase does this – I think it relies on Windows System Calls, but I may be wrong.)
File system is FAT32.
And it could be taken from the BPB_TotSec32 field of the boot sector, and multiplied with the BPB_BytsPerSec field, and then reduced to either Gigabytes or Gibibytes. (Do you know which?)
If I fake the contents of those fields, any software that trusts them blindly will report a bad size. It's easy to fake – you can do it with a hex editor yourself. Try it sometimes.
Surprisingly, much forensic software is not written to work in defensive or paranoid mode, where media or the information recorded on them are distrusted.
You have to supply that yourself.
Try overwriting your USB stick with 0xFF then browse it in a hex editor (or forensic tool).
A simple method is use Encase (dongle not needed) and use the wipe option using 0xFF.
Work had got some branded 8GB USB stick's which I found some of the files I had put on were corrupted. This occured once the disk was over half full.
After running the wipe I discoved the first half of the stick was 0xFF and a small section at the end. Showing only 4GB could be written to it.
Quite sneaky as the small section at the end would allow NTFS to also work fine on the stick.
Made me think that we maybe should wipe all our devices with 0xFF, especially as we use SSD's more often now. Doing this would allow detecting sectors that are besically read only blank (0x00).
Made me think that we maybe should wipe all our devices with 0xFF, especially as we use SSD's more often now. Doing this would allow detecting sectors that are besically read only blank (0x00).
Yes and no.
It would be useful on those sticks that behave like you described, but in the case of a purposedly mal-programmed controller that wouldn't work, the same memory is re-accessed in a loop, so you would re-write 0xFF over an already overwritten with 0xFF sector.
You would need a "pattern" including the LBA number of the sector to detect the occurrence of such a loop.
jaclaz