OneDrive Reparse Points - Githubissues

sepinf-inc / IPED

IPED Digital Forensic Tool. It is an open source software that can be used to process and analyze digital evidence, often seized at crime scenes by law enforcement or in a corporate investigation by private examiners.

Other

968 stars 219 forks source link

OneDrive Reparse Points #545

Open patrickdalla opened 3 years ago

patrickdalla commented 3 years ago

OneDrive files not synchronized are stored in NTFS as "reparse points". These reparse points are been exported by IPED as zero filed files, as the content is actualy on the cloud. The problem is the size of these zero filed files on the generated reports. IPED export could ignore the exporting of these files and show why it wasn't actually exported on the GUI.

lfcnassif commented 3 years ago

I think this will be possibly solved by https://github.com/sepinf-inc/IPED/pull/458

patrickdalla commented 3 years ago

I think this will be possibly solved by #458

Well, not fully. The current implementation does reconize the item as an PDF document, even with no access to the actual content. This seams good to me, as the analyst can know the existence of the entry with the name. The problem is that the exported result occupies disk space with zeros.

lfcnassif commented 3 years ago

So #458 proposal would classify these zeroed files as unknown. But I agree with you current behavior could be good in some scenarios, worst in others. Maybe you can leave your thoughts on #458

lfcnassif commented 3 years ago

Sorry, original discussion is on https://github.com/sepinf-inc/IPED/issues/401

patrickdalla commented 3 years ago

The problem here is not about classification of the content, as it is unkown (is in the cloud). The problem is with the content generated by IPED Export routine, a zero filled file that doen't represent neither what is on the evidence nor what is on the cloud and waste report media space. I've wasted time trying to figure out what does these zero filled files were, till i've found they were not zero filled files, but entries pointing to files on the cloud.

lfcnassif commented 3 years ago

Yes I understood, so I kept this open instead of closing as duplicate.

lfcnassif commented 3 years ago

This possibly needs to be identified at the sleuthkit level, I don't know if it already does, and exposed by TSK java api. Without FS info, currently decoded by TSK, Iped can't distinguish reparse points from regular zeroed files.

lfcnassif commented 3 years ago

I don't know if it already does

Actually seems TSK already has a flag to identify those files: https://sleuthkit.org/sleuthkit/docs/jni-docs/4.6/enumorg_1_1sleuthkit_1_1datamodel_1_1_tsk_data_1_1_t_s_k___f_s___a_t_t_r___t_y_p_e___e_n_u_m.html#a5ce25ef595e4fa19825667332cd51052

gisms commented 2 years ago

Hi!

I would like to confirm if this would be the case that I am experiencing. A HD contains several files of Category "Cloud Storage".

Files that are marked as "Deleted = true", in case of spreadsheet, are filled with ######;

The ones "Deleted = false", some open, some don't, others give the same content # in the view. It has no pattern.

When I exported the files, they are exported with the indicated size.

Is this the expected behavior for entries pointing to files on the cloud? What treatment do you still intend to give (marked for version 4.0)?

lfcnassif commented 2 years ago

Hi,

I would like to confirm if this would be the case that I am experiencing. A HD contains several files of Category "Cloud Storage".

Files that are marked as "Deleted = true", in case of spreadsheet, are filled with ######;

The ones "Deleted = false", some open, some don't, others give the same content # in the view. It has no pattern.

I don't know, the original description talk about file content totally filled with zeroes (0x00). Are you seeing ##### chars in Hex viewer or other? What is the Hex viewer content of those that open or not? Are those files returned by "Parsing Error" ("Erro de Parsing") filter?

When I exported the files, they are exported with the indicated size.

And those that don't open internally do open fine with an external application?

Is this the expected behavior for entries pointing to files on the cloud?

I would need more information to understand what this behavior exactly is.

What treatment do you still intend to give (marked for version 4.0)?

None, at least from my side, unfortunately this is not scheduled for 4.0.

gisms commented 2 years ago

The files in my case are also OneDrive.

I don't know, the original description talk about file content totally filled with zeroes (0x00). Are you seeing ##### chars in Hex viewer or other? What is the Hex viewer content of those that open or not? Are those files returned by "Parsing Error" ("Erro de Parsing") filter? I checked, in fact in the hex view only zero appears, in the next preview "#". No parsing error
And those that don't open internally do open fine with an external application? No, it is not possible also to open in a external tool.

I was trying to make sure that this is the case commented on by PatrickDalls (OneDrive files not synchronized are stored in NTFS as "reparse points"). I think it is

lfcnassif commented 2 years ago

The files in my case are also OneDrive.

I checked, in fact in the hex view only zero appears (...)

So, seems your case is similar to @patrickdalla's past case.

gisms commented 5 months ago

I would like to confirm another case which possibly matches this situation and leave a suggestion:

I have som files located in path with OneDrive:
They are all in the filter "Parsing Error"
The pre-visualization of the files return this:

The hex contains just zeros:
In FTK Imager they are typed as "Reparse Point":

So, the content of all this file are actualy on the cloud and not possible to access?

It would be interesting if iped indicated in some metadata that we were dealing with a "reparse point" file.