Try count=167935 option for dd.
Try to calculate hash values in the piecewise mode, e.g.
dd if=/dev/sdb count=167936 2> /dev/null | md5deep -p 512b > sdb.txt
dd if=image.dd 2> /dev/null | md5deep -p 512b > image.txt
Then compare them diff sdb.txt image.txt
It's hard to tell anything until you show what (and how many) sectors are different. Can you try the commands I gave above? Also, tell me what distribution do you use and how do you use it (from Live CD/USB or you have installed it on a drive).
—
PS. Can you also try these "dd if=image.dd skip=128 | file -" and "dd if=image.dd skip=92288 | file -", and the same again for /dev/sdb, and post the output here?
So the answer is simple something altered a bunch of sectors after you restored an image to a drive. Probably Kali mounted file systems read-write after you ran the dd command (but I can't be sure unless we understand what do these changes actually mean). Can you try to run the command "dd if=/dev/sdb skip=557 count=1 2> /dev/null | hexdump -C" and repeat it for "image.dd"?
mount
[REMOVED]
/dev/sdc1 on /media/Lexar type vfat (rw,nosuid,nodev,relatime,fmask=0022,dmask=0077,codepage=437,iocharset=utf8,shortname=mixed,showexec,utf8,flush,errors=remount-ro,uhelper=udisks)
So Kali automatically mounts removable drives in read-write mode.
Then, I did the dd command but I added this conv=syn,noerror (which I am not exactly sure what it does but I saw it all over the place)
dd if=image.dd of=/dev/sdc conv=sync,noerror
167936+0 records in
167936+0 records out
85983232 bytes (86 MB) copied, 21.0107 s, 4.1 MB/s
They tell dd to ignore I/O errors ("noerror") and to fill the buffer with null bytes before doing the data transfer ("sync"). If there are no bad sectors on a drive, the results from dd without any conv= options and from dd with conv=sync,noerror options are the same.
I then tried to mount it as read only but this didn't work
mount -o ro /dev/sdc
mount can't find /dev/sdc in /etc/fstab or /etc/mtab
That's because you didn't specify a mountpoint. Also, you may want to specify a partition with a file system, instead of a whole drive (/dev/sdc1 instead of /dev/sdc, unless your drive is non-partitioned). Please note, that "-o ro" option is not enough to do a forensically sound mount of a file system.
But why? What is different between these except the conv=sync,noerror? I notice that this new device (sdc) is listed as vfat in when checking mount. Does that matter? I would like to figure what is going on even if I have a correct version. I don't want to go buy a new USB every time I want to play around.
I guess you need to choose a distribution which will never automount anything (at least after the boot process is finished). A file system mounted read-write may become altered or may remain the same - it depends on many circumstances, so it's not a surprise that hash values did match last time (also, there is a possibility that a partition table wasn't re-read after you restored an image on a drive, so the operating system mounted nothing, and the operating system could also treat /dev/sdc1 as already mounted if you didn't unmount it before restoring an image).
So why the difference between the 2 tests? Both devices are USB's so Kali would have mounted rw for both.
I did a small update to my previous post.
As for the attempt to mount ro and specifying the partition, I can't because I want it look at the "restored" image which is made up of multiple partitions (I want the disk). Also, I am not sure what you mean by specifying a mountpoint.
If you want to mount a file system on a partition, you need to specify a partition, e.g.
mount -o ro /dev/sdc1 /mnt/sdc1/
(the latter argument is a mountpoint - a directory in which the contents of a file system will appear)
Finally, what would be the forensically sound method to mount a file system?
mount -o ro,loop … (for anything, except Ext3/4 and btrfs)
mount -o ro,loop,noload … (for Ext3/4 only)
PS - Anyone know how to keep Kali from automount rw? Not sure it matters (for this) because both would have acted the same, but out of curiosity. I will be googling as well….
There is a forensic mode in a Live CD, but it will likely automount USB drives during the boot. You better change the distribution to another one (like grml).
So the mountpoint would be a folder containing the contents of the file system so I can view the system (click and look). If that is correct, then that makes sense to me. I think I had done that before with things.
Yes, that's correct.
I wouldn't normally mount it (that just me), I would image it and then look at the image.
You wouldn't, but an operating system may think differently -)
I was just reading www.forensicfocus.com/...le-systems about mounting. But thank you for the details as well.
That's the article I wrote.
I am still uncertain as to why the difference. I remember when I did the restore on sdb, as soon as it was completed a window opened with the contents of the drive. When I did sdc, that didn't happen. So, that "automount" (for lack of a better term or understanding) is what caused the change.
I think this "windows opened" issue supports the version of read-write mounting of a file system. We can dig deeper and match altered sectors with modified timestamps, journal entries and other things, but that's too much effort.
The question is, what is it about the sdc that kept it from doing that and how do I make sdb not do that?
An operating system could re-read the partition table and mount file systems in new partitions in one case, and miss partition table updates in another case. This is likely to happen when you do low-level modifications to a partition table (and that's why disk partitioning tools force an operating system to re-read a partition table when user changes something). An existing mount entry for /dev/sdc1 could also affect the situation (an operating system considers /dev/sdc1 to be mounted, then you overwrite /dev/sdc and create the new partition table, but /dev/sdc1 is still considered to be mounted by an operating system, and a new file system in /dev/sdc1 won't be mounted due to protection against double mounting).
I know you said use another distribution, but I really like Kali and it is supposedly a build for forensics.
There are many issues with forensic soundness in Kali (including arbitrary code execution and altering Linux LVM drives even when no file systems are being mounted), and developers tend to ignore them.
If you have no objection, I am going to wipe out sdb and see if I can get it to work correctly. If you have any more thoughts on how I might step through this and keep it from happening, let me know!
I think it's better to try to reproduce the issue by overwriting a drive again and again. You can also try to find some GUI option that disables automatic mounting of file systems.
Should I be umount /dev/sdb1 /media/CFDI320 and the sdb2 one or are they fine?
Double mounting is extremely dangerous (due to possible data loss, just think of what happens if a driver's code tries to update a superblock, a journal or a data concurred with another instance of the same code doing similar things). The system will do some things to protect you from double mounting, but playing with loop devices (note the "loop" option to the mount command) will allow you to mount something twice. In your case, the second mount is truly read-only, so nothing bad will happen (except you don't need to mount the evidence read-write at all, even if you unmount it immediately, because some alterations may happen on a mounted file system without any user interaction, as you already seen).
In your opinion, what is the best Forensic Linux distribution with all the tools like Kali?
Kali is focused on penetration testing. There is no forensic distribution with a comparable set of penetration testing tools preconfigured. IMHO, it's better to use different distributions for penetration testing and forensics.