Issues with: Forens...
 
Notifications
Clear all

Issues with: Forensic Acquisition Of Solid State Drives

52 Posts
6 Users
0 Likes
4,856 Views
jaclaz
(@jaclaz)
Posts: 5133
Illustrious Member
 

The only thing I can say is that I am just sharing the findings of my experiments, the results show that it works.

Well, I still have the questions I asked unanswered, please don't take this in any way as "adversarial" ) , I only want to understand
1) Can you detail the differences between "volume" and "partition" and share the EXACT commands you used to image the one (and the other)? (and why you did these experiments since normally the whole device or "PhysicalDrive" is imaged)

2) Can you better explain the idea behind (or around) the "take note of the adapter used and only use that one"?

3) What do you see particularly as "novelty" in your findings? Or if you prefer, which specific steps/recommendations in your paper are different from common, current, "best practice standards?

jaclaz

 
Posted : 15/03/2018 3:05 pm
(@jefferreira)
Posts: 19
Active Member
 

Jaclaz, I will do my best to explain it.

1) Can you detail the differences between "volume" and "partition" and share the EXACT commands you used to image the one (and the other)? (and why you did these experiments since normally the whole device or "PhysicalDrive" is imaged)

After using the shasum - a 256 /dev/sdb to hash the drive, I used dd to image it dd if=/dev/sdb of=ssd1_first_img. 001and changed the img name to second, third and so one for a month

Hashed the image and compared the hash values.

I regards to the partition v volume. Honestly, it was the only way I could think of to differentiate them.

/dev/sdb volume and dev/sdb1 partition. Because of the changes on the hashes generated by the adapter I got curious if the hash values between dev/sdb would also differ. They did, the dev/sdb changed depending on the adapter while the /dev/sdb1 remained unaltered. And that is why I used the internal SATA connector to be used has a baseline for the "correct hash"

I only image drives as whole too.

2) Can you better explain the idea behind (or around) the "take note of the adapter used and only use that one"?

The idea is to ensure that the results(hashes) are consistent. Has shown in the results of the experiments, the hash values changed and that is why I wrote what I wrote in the recommendations to validte the cables and adapters to ensure that they all generate the same hash value.

3) What do you see particularly as "novelty" in your findings? Or if you prefer, which specific steps/recommendations in your paper are different from common, current, "best practice standards?

From my understanding and knowledge currently you either let the ssd stabilise by plugging it with no regard to what is inside or you (after plugging it) hash individual files… My question is why?

I am suggesting a method that is straightforward, not intrusive and that is similar to the way you handle and image HDDs.

Jaclaz, you are really smart and knowledgeable and I would like to say thank you for taking the time to read the article, post and your questions. If there is anything I am doing wrong or missing, please let me know ????

jaclaz

 
Posted : 15/03/2018 3:26 pm
jaclaz
(@jaclaz)
Posts: 5133
Illustrious Member
 

1) Ok, we will need to find a better way to define things or agree to a same convention.

The matter is slippery and a lot of people tend to use improperly this or that confusing term, disk, disk drive, disk, drive, volume.

sdb is a "disk drive" "whole disk-like device", or "device" or (in windows) "PhysicalDrive" or "disk" or if you prefer it is the object composed by ALL sectors of the mass storage device from offset 0 to the very last sector.

sdb1 is a "partition", if you prefer an object that is a given subset of the entire capacity of the device, that by definition starts at an offset higher than 0 and (normally but not always) also ends before the very last sector, on windows this is called a "drive" because when mounted it gets assigned a "drive letter" and is BTW the same object to which you can apply a "volume label".

If a partition is primary it is EXACTLY the same as a "volume" [1].

If a partition is an Extended one it contains "logical volumes", which are not anything different from a "primary partition"as above, the only difference being that their addresses is not stored in the MBR, but rather in the chain of EPBR's.

On GPT all partitions are primary, so all partitions are also volumes, with the only caveat in [1]

2) About the hashing, if I get it right, you did in two separate steps
1) hash the source before dding it
2) hash the resulting image after having dded it
Is that correct?

3) This is where I am really failing to understand, what you recommend seems to me what is ALREADY recommended by everyone [2] before and besides your article.
The only item with a *difference* (AFAICT) is about the (combined) effects of points 2. and 7. of your "recommendations"

2. To ensure the integrity of digital evidence and avoid unexpected results, the cables and adapters used at the forensic laboratory should be verified and validated, prior to the imaging process, to ensure that all the cables produce the same hash values.

7. The SATA adapter used at the crime scene to image or hash the Solid State Drive should be the same adapter used at the forensic laboratory for hashing and imaging the SSD. This helps to determine if any changes to the device occurred.

If a given adapter/converter is validated, it is validated, and all validated adapters/converters will not introduce hash changes of any kind.
The alternative being that the given adapter/converter cannot be validated (and should be thrown in the garbage bin) because it unpredictably changes hashes OR assume that a same (anyway somehow "defective") adapter/converter always changes hashes in exactly the same manner on the same data.

I am asking because very likely I am missing something of relevance in your recommendations.

jaclaz

[1] With most filesystem, (primary) partition=volume=filesystem, the exception is NTFS, where there is a single sector (which is used to store the backup of the first sector of the bootsector or of the $Boot file) that is after the end of the volume but inside the partition.

[2]personally I go even a little further sideways, but that is my personal approach to the possible issues, rigorously not validated, let alone accepted by anyone in the forensic community at large, we may talk of this once cleared the other points

 
Posted : 15/03/2018 4:08 pm
(@jefferreira)
Posts: 19
Active Member
 

2) About the hashing, if I get it right, you did in two separate steps
1) hash the source before dding it
2) hash the resulting image after having dded it
Is that correct?
"

Thank yo ufor clarifying I do misuse volume to refer to a device sometimes. P

I did four separate steps

1) hashed the SSD
2) Created image of the SSD with dd
3) hashed the image
4) hashed SSD again to confirm if the integrity had been compromised.

I did this for every SSD.

with the auto-mount disabled, I just followed the steps above,

In regards to the recommendations, I wrote them based on the feedback I got from some people.

I did what seemed logical. If the validation is common pratice then my recommendations are useless.
It is like I previously said, I only added the issue with the adapters because I didn't want the paper to be just about the auto-mount and a lot of people I know were unaware that this issue with the adapters happens.

The adapters are fine btw, they are just different. why? I did not have a chance to find out,

Was it already common pratice? I was unaware of it.

Ando no, I don't think you are missing the relevance of anything I wrote. )

Thank you

 
Posted : 15/03/2018 4:37 pm
jaclaz
(@jaclaz)
Posts: 5133
Illustrious Member
 

I did four separate steps

1) hashed the SSD
2) Created image of the SSD with dd
3) hashed the image
4) hashed SSD again to confirm if the integrity had been compromised.

I did this for every SSD.

with the auto-mount disabled, I just followed the steps above,

Good. )

Then - maybe - there is still the possibility of a read error of some kind (i.e. if you prefer a malfunctioning of either the source device or of the adapter/converter) or of a write error on the target device/media or even *something else* (unspecified).

Some of the imaging tools (besides plain dd) do create the hash while imaging, not that this is particularly better but at least guarantees that the generated hash is that of what is read from the source at the moment of the imaging.

Fact is that anyway hashing is (or has become, doesn't matter) a very poor way to detect possible issues (i.e. it works just fine if everything is fine, but if something fails, the mismatched hash foesn't give any hint about what has failed).

JFYI (and as a side note) there was a proposal to do "better" hashing, check this
https://www.forensicfocus.com/Forums/viewtopic/p=6587736/#6587736
and given links, particularly this one
https://www.forensicfocus.com/Forums/viewtopic/t=11739/

jaclaz

 
Posted : 15/03/2018 5:09 pm
(@thefuf)
Posts: 262
Reputable Member
 

The adapters are fine btw, they are just different. why? I did not have a chance to find out,

Was it already common pratice? I was unaware of it.

It's easy to compare two forensic images sector-by-sector to find the difference between them. If you see different content of the same drive when you change the connection type, then the first thing to do is to note the difference is this an extra sector (block), or a missing sector (block), or some null bytes instead of real data, or garbage instead of real data, is "modified" data stable between two acquisitions? You didn't do that.

 
Posted : 15/03/2018 5:10 pm
(@thefuf)
Posts: 262
Reputable Member
 

I didn't want the paper to be just about the auto-mount

There is no direct connection between mounting a file system and garbage collection (see before).

 
Posted : 15/03/2018 5:13 pm
(@jefferreira)
Posts: 19
Active Member
 

In reg\ards to the adapters I would like to explain what I did and how.

I first noticed this change when I used a SATA-2-USB adapter I had borrowed from a friend, then I started borrowing more and more to compare the hash values.

I used two laptops, two PCs and the results were consistent throughout. Each adapter generated it's hash value in each one of the pcs and laptos that I used for the experiments

About the the Gargabe collection and trim… with or without a link between these and auto-mount.. I can only state that the integrity of the SSDs was verified, using two laptos and 2 PC, nearly everyday (I only showed day 1, day 15 and Day 30 in the experiments section to simplify.) and their hash values remained unlatered regardless of the LInux live CD or Ubuntu, with auto-mount disabled, installation that I had on each laptop and PC.

Again, experiment with the suggested method and if I am wrong, please let me know. I only have the results of my experiments and that is all that I can use to support my premisse.

I am glad that the user AmNe5iA created this post. Thank you. ) you got people to comment on the article. D

It was my first article based on a paper and I am glad that it got this far. )

 
Posted : 15/03/2018 5:35 pm
(@c-r-s)
Posts: 170
Estimable Member
 

About the the Gargabe collection and trim… with or without a link between these and auto-mount.. I can only state that the integrity of the SSDs was verified, using two laptos and 2 PC, nearly everyday (I only showed day 1, day 15 and Day 30 in the experiments section to simplify.)

Is it possible, that a power management configuration (BIOS or OS level) interfered with your test? The drive won't perform a garbage collection when under read stress or powered down soon afterwards.

 
Posted : 15/03/2018 6:41 pm
jaclaz
(@jaclaz)
Posts: 5133
Illustrious Member
 

I can only state that the integrity of the SSDs was verified, using two laptos and 2 PC, nearly everyday (I only showed day 1, day 15 and Day 30 in the experiments section to simplify.) and their hash values remained unlatered regardless of the LInux live CD or Ubuntu, with auto-mount disabled, installation that I had on each laptop and PC.

Sure ) , but this brings us back to

https://www.forensicfocus.com/Forums/viewtopic/p=6593179/#6593179

Yes but all you have really proved is that storing an SSD in a cupboard for 30 days has no effect on the data.

Something that somehow I wouldn't consider "surprising".

Again, experiment with the suggested method and if I am wrong, please let me know. I only have the results of my experiments and that is all that I can use to support my premisse.

Well, no.

The point (at least mine) is not at all whether you are wrong or not (and usually proving someone "wrong" is done through counter-experiments, as the most that can be done by doing the same experiments is proving that the experiments provide repeatable results or that they don't), what I am still struggling to understand is the theory behind the experiment, whether this theory corresponds to practice (causation rather than correlation), and where this practice is in any way different from current ones, i.e. what is innovative.

jaclaz

 
Posted : 15/03/2018 6:57 pm
Page 2 / 6
Share: