Okay i have followed what you tasked me and here are the result when i use Winhex
imgur.com/a/xIFga
it shown ADSEGMENTEDFILE at the right

for the Image fragment Size, maybe what you are trying to do is, to get the smaller bits of the image file so that able to see what's inside? or to decrypt and get the main size of the file which is 8.14gb?

I'm really not sure what are the numbers and value that i saw in Winhex are. does they mean something? like Ascii characters? i tried comparing those using Ascii table but it doesn't add up and mean anything, please advise me.

- jaclaz

- Nephalem

what should i do next?

Open the file part1.ad1 with a hex editor.
What do you see? (check the first two sectors)

Open the file part1.ad2 with a hex editor.
What do you see? (check the first two sectors)

Now remove from the evidence tree in FTK image everything.

Add (File->Add Evidence Item>Image file) the part1.ad1 in FTK.
Make a screenshot of what you see.

Remove again from the evidence tree everything.
Add only the part1.ad2.
Make a screenshot of what you see.

Remove again from the evidence tree in FTK image everything.

Rename the file part1.ad1 to part1.adx.
Add in FTK the part1.ad2 as evidence item.
What happens?

Now the questions you need to answer:
1) What could be a good (logical, not necessarily technical) explanation of what you saw in the hex editor? (also at the light of the change in the field from 1500 to 200 and the generation of files up to ad42)
2) In what do the two FTK screenshots differ?
3) How would you describe the behaviour of the FTK imager when the evidence item "part1.ad1" is loaded compared to when the evidence item "part1.ad2 is loaded?
4) How would you explain the behaviour happening when part1.ad1 is renamed to part1.adx and you add part1.ad2 as an evidence item? (also at the light of what you saw in the hex editor)

jaclaz

 

- Nephalem

Okay i have followed what you tasked me and here are the result when i use Winhex
imgur.com/a/xIFga
it shown ADSEGMENTEDFILE at the right

Good .
Now what that might mean (in plain English)?

What is in the second sector (starting at offset 0x200) of the .ad1 file?
And what is in the second sector (starting at offset 0x200 of the .ad2 file?

What about the other tests:

- jaclaz

Now remove from the evidence tree in FTK image everything.

Add (File->Add Evidence Item>Image file) the part1.ad1 in FTK.
Make a screenshot of what you see.

Remove again from the evidence tree everything.
Add only the part1.ad2.
Make a screenshot of what you see.

Remove again from the evidence tree in FTK image everything.

Rename the file part1.ad1 to part1.adx.
Add in FTK the part1.ad2 as evidence item.
What happens?

Once completed the above, you should be able to answer to the given questions:

- jaclaz

Now the questions you need to answer:
1) What could be a good (logical, not necessarily technical) explanation of what you saw in the hex editor? (also at the light of the change in the field from 1500 to 200 and the generation of files up to ad42)
2) In what do the two FTK screenshots differ?
3) How would you describe the behaviour of the FTK imager when the evidence item "part1.ad1" is loaded compared to when the evidence item "part1.ad2 is loaded?
4) How would you explain the behaviour happening when part1.ad1 is renamed to part1.adx and you add part1.ad2 as an evidence item? (also at the light of what you saw in the hex editor)

jaclaz
_________________
- In theory there is no difference between theory and practice, but in practice there is. - 

The "second sector (starting at offset 0x200)" is it this?
imgur.com/a/VAEZ4
the screenshot i highlighted in red

the other tests i have tried, renaming of ad1 to adx and also adding ad2 as evidence item
its on the screenshot here
imgur.com/a/xIFga



Q1 - I think, change the field from 1500 to 200 is to divide the ad1 file into segment, but i'm not sure whats the purpose.

Q2 - If from what i highlighted in red from the first imgur linked i shown is correct. ad1 is the logical image of the main image file while ad2 is the segmented file? so it means to say all the other files up to ad42 are segmented?

Q3 - Both of them seems to be the same on the way its loaded

Q4 - Before i change "part1.ad1" to "part1.adx", "part2.ad2" was shown "ADATA UFD"
but after i changed, "part2.ad2" became ASEGMENTEDFILE shown on FTK
screenshot here: imgur.com/a/Wjs1o

- jaclaz

- Nephalem

Okay i have followed what you tasked me and here are the result when i use Winhex
imgur.com/a/xIFga
it shown ADSEGMENTEDFILE at the right

Good .
Now what that might mean (in plain English)?

What is in the second sector (starting at offset 0x200) of the .ad1 file?
And what is in the second sector (starting at offset 0x200 of the .ad2 file?

What about the other tests:

- jaclaz

Now remove from the evidence tree in FTK image everything.

Add (File->Add Evidence Item>Image file) the part1.ad1 in FTK.
Make a screenshot of what you see.

Remove again from the evidence tree everything.
Add only the part1.ad2.
Make a screenshot of what you see.

Remove again from the evidence tree in FTK image everything.

Rename the file part1.ad1 to part1.adx.
Add in FTK the part1.ad2 as evidence item.
What happens?

Once completed the above, you should be able to answer to the given questions:

- jaclaz

Now the questions you need to answer:
1) What could be a good (logical, not necessarily technical) explanation of what you saw in the hex editor? (also at the light of the change in the field from 1500 to 200 and the generation of files up to ad42)
2) In what do the two FTK screenshots differ?
3) How would you describe the behaviour of the FTK imager when the evidence item "part1.ad1" is loaded compared to when the evidence item "part1.ad2 is loaded?
4) How would you explain the behaviour happening when part1.ad1 is renamed to part1.adx and you add part1.ad2 as an evidence item? (also at the light of what you saw in the hex editor)

jaclaz

 

- Nephalem

The "second sector (starting at offset 0x200)" is it this?
imgur.com/a/VAEZ4
the screenshot i highlighted in red

Yep, that's it, and it is telling you that it is a "logical image" (though we already knew that as the .ad1 format is for logical images) and since you checked the .ad1 file of the original image of the assignment you can also see that the source for the image was a file:
D:\FORENSIC-IMAGES\jo19dd\jo19
So, this might be a meaningful difference, the .ad1 files have at offset 0x200 "ADLOGICALIMAGE" followed by something that is human readable and is evidently a path, whilst the .ad2 file at the same offset show only some apparently random binary data.

- Nephalem

Q1 - I think, change the field from 1500 to 200 is to divide the ad1 file into segment, but i'm not sure whats the purpose.

Very good .
The purpose - just for the record - is (was) to be able to copy the files on limited size media (think of CDR or DVDR).
The idea is that the whole image is saved in segments (or parts) to be easier to be copied/stored (or sent/downloadef).
Another possible target, as an example, would be storage on a FAT32 filesystem where the single file size cannot exceed 2^32-1, i.e. roughly 4 GB.

- Nephalem

Q2 - If from what i highlighted in red from the first imgur linked i shown is correct. ad1 is the logical image of the main image file while ad2 is the segmented file? so it means to say all the other files up to ad42 are segmented?

Almost but not quite.
More simply, the .ad1 is the first file in a set of files, with extension .ad followed by a number indicating the sequence of the file in the set.

- Nephalem

Q3 - Both of them seems to be the same on the way its loaded

Good .

- Nephalem

Q4 - Before i change "part1.ad1" to "part1.adx", "part2.ad2" was shown "ADATA UFD"
but after i changed, "part2.ad2" became ASEGMENTEDFILE shown on FTK
screenshot here: imgur.com/a/Wjs1o

Not only, you also got a pop-up message to the effect of "Image Detection Failed" when you tried to open the .ad2 file at the time the .ad1 was renamed to .adx.

Let's sum together the results of tests #3 and #4:
When the .ad1 files exists the .ad2 file looks exactly like the .ad1 file in FTK imager.
When the .ad1 file does not exist (as it is renamed to .adx) the .ad2 file throws an error and looks completely different in FTK imager, so next question.

5) How could this happen?
Again a "logical", "plain" explanation, rather than a "technical one", is welcome.

And time for next experiment.
Remove everything from the FTK evidence tree.
Rename back the .adx to .ad1.
Add the .ad42 (or the .ad31 or the .ad17) image to the evidence tree.
Select the "child item" (you remember, you will see on the top right pane [root], [unallocated space], etc.) , right click and "Export Logical Image (AD1).
Press the Add button, put *something* in the Evidence Item Information window, then go on, input a suitable destination path and a filename, I suggest "monolithic_test", and replace the 1500 in the "Image Fragment Size (MB)" field with a value higher than the sum of the sizes of all the 42 files you have now, let's say 20000.

Now ask to yourself, before pressing the Finish button, what would you expect to happen?
Press the "Finish" button, let the FTKimager do its thing, it will take a few minutes.
What actually happened?

jaclaz
_________________
- In theory there is no difference between theory and practice, but in practice there is. - 

Q5 - I think its because of the extension? to check the file if its able to load in other extension form, so apparently FTK is only able to read extension with ad, but not adx as it become "Detection fail"

For the experiment i followed your tasked and i selected unallocated space > Export logical image.
since we tried image fragment size the value was set at 200, the file was fragment and became smaller, so if its set to 20000 i assumed that it will become huge, but didn't know that it became a main file.
here is the screenshot of the result imgur.com/a/RXR9R
it became a main file which is 7.19gb

- jaclaz

5) How could this happen?
Again a "logical", "plain" explanation, rather than a "technical one", is welcome.

And time for next experiment.
Remove everything from the FTK evidence tree.
Rename back the .adx to .ad1.
Add the .ad42 (or the .ad31 or the .ad17) image to the evidence tree.
Select the "child item" (you remember, you will see on the top right pane [root], [unallocated space], etc.) , right click and "Export Logical Image (AD1).
Press the Add button, put *something* in the Evidence Item Information window, then go on, input a suitable destination path and a filename, I suggest "monolithic_test", and replace the 1500 in the "Image Fragment Size (MB)" field with a value higher than the sum of the sizes of all the 42 files you have now, let's say 20000.

Now ask to yourself, before pressing the Finish button, what would you expect to happen?
Press the "Finish" button, let the FTKimager do its thing, it will take a few minutes.
What actually happened?

jaclaz

 

I would provide you an alternate explanation.

If the size in the field "Image Fragment Size" is big enough to contain all the data, only one file with extension .ad1 is created, i.e. there is only a fragment.

If the size in the field "Image Fragment Size" is not big enough to contain all the data, as many files as needed are created, everyone but the last being the size specified in"Image Fragment Size" (the last one will normally be smaller than that).

How could this happen?

How could the good guys at Access Data have implemented that?

Maybe they wrote a "descriptive" header for the first file.
Then started writing the actual data until the target file was exactly the given image fragment size,
Then created a "next" file, incrementing the number in the extension, writing a different "continuation" header and continued writing the data from the point they stopped writing it in the "previous" file, up to when they reached in this file the set size, and created a new "next" file, etc. until all data has been written.

The actual "descriptive" header (and the beginning of the data) is only in the first file of the set, the .ad1, so the FTKimager, no matter if you choose to add the file .ad2 (or .ad42) to the evidence tree will always look for a file with the same name in the same folder with extension .ad1.

When this file (same name, in the same folder as the selected one but with extension .ad1) is not found, FTK imager cannot recognize the file anymore (simply because one file of the set, actually the first and main one, is missing).

Does this sound as a logical explanation of the behaviours observed?

However, WHY did you select to make a logical image of just the "unallocated space"?
(that is one of the "nephews", not the "child" of the .ad file opened in FTK Imager)

If you had chosen the actual first child, you would have obtained a "monolithic" file containing all the data.

Maybe you want to try again, delete the monolithic-test.ad1 file and make it anew, this time selecting the right item, the result should be (roughly) 42*200=8,400 Mb or slightly less.

jaclaz
_________________
- In theory there is no difference between theory and practice, but in practice there is. - 

Oh okay, i roughly gets it. Thanks for the explanation!

And sorry!, cause i misread it, and i created on "the unallocated space".
Okay just to confirm, that the first child is the one that i see it after i expand the "part.1ad42" for the first time right? like for example mine is "\\PHYSICALDRIVE1\Parition 1".
so is part1.ad42 > PHYSICALDRIVE 1 > Export Logical Image AD1 > Image fragment set to 20,000
because i tried it again and i got roughly the same size again, this 8.14gb this time.
am i doing something wrong here?

- jaclaz

I would provide you an alternate explanation.

If the size in the field "Image Fragment Size" is big enough to contain all the data, only one file with extension .ad1 is created, i.e. there is only a fragment.

If the size in the field "Image Fragment Size" is not big enough to contain all the data, as many files as needed are created, everyone but the last being the size specified in"Image Fragment Size" (the last one will normally be smaller than that).

How could this happen?

How could the good guys at Access Data have implemented that?

Maybe they wrote a "descriptive" header for the first file.
Then started writing the actual data until the target file was exactly the given image fragment size,
Then created a "next" file, incrementing the number in the extension, writing a different "continuation" header and continued writing the data from the point they stopped writing it in the "previous" file, up to when they reached in this file the set size, and created a new "next" file, etc. until all data has been written.

The actual "descriptive" header (and the beginning of the data) is only in the first file of the set, the .ad1, so the FTKimager, no matter if you choose to add the file .ad2 (or .ad42) to the evidence tree will always look for a file with the same name in the same folder with extension .ad1.

When this file (same name, in the same folder as the selected one but with extension .ad1) is not found, FTK imager cannot recognize the file anymore (simply because one file of the set, actually the first and main one, is missing).

Does this sound as a logical explanation of the behaviours observed?

However, WHY did you select to make a logical image of just the "unallocated space"?
(that is one of the "nephews", not the "child" of the .ad file opened in FTK Imager)

If you had chosen the actual first child, you would have obtained a "monolithic" file containing all the data.

Maybe you want to try again, delete the monolithic-test.ad1 file and make it anew, this time selecting the right item, the result should be (roughly) 42*200=8,400 Mb or slightly less.

jaclaz