Testing Opportunity

[paulobreim]

I have a new case to work on that involves indexing approximately 45 ufdr images using IPED.
My idea is to index them all at once.
I'm going to put them all in a single folder and just use -d \folder so I don't have to specify them one by one.
Since all images are cell phones, my idea is to use voice transcription
This will be a very interesting test.
If anyone wants to take the opportunity to test other items available on IPED, just tell me.

[wladimirleite]

Hi @paulobreim!
Just one important detail, processing a folder with UFDRs isn't the correct way.
You need to use -d for each UFDR. What I usually do is to write a trivial script/program to list files and generate the command line.
This has been discussed a few times, but I can't remember where :-)
For the future, this may be supported, perhaps through a new command line option to process all evidences (E01, DD, UFDRs) inside a folder or a mask (like -d f:\Case001*.ufdr).

[lfcnassif]

Months ago a notice about UFDR processing was published here: #1272

[lfcnassif]

One of the reasons for the behavior change was this situation of several UFDR files inside the input folder, just one of them would be processed fine by IPED 3. You should pass each of them to -d param to process them correctly in IPED 4, as @tc-wleite said.

[paulobreim]

I started indexing 42 UFDRs but after several exceptions in different UFDRs (I removed the ones that gave errors), I decided to carry out tests with one of those that gave errors.
The error is this:
java.lang.Exception: Error decoding datasource j:\teste.ufdr
at iped.engine.datasource.ItemProducer.run(ItemProducer.java:154)
Caused by: java.lang.RuntimeException: Invalid UFDR file j:\teste.ufdr
at iped.engine.datasource.UfedXmlReader.getXmlInputStream(UfedXmlReader.java:178)
at iped.engine.datasource.UfedXmlReader.lookUpXmlReportInputStream(UfedXmlReader.java:193)
at iped.engine.datasource.UfedXmlReader.read(UfedXmlReader.java:220)
at iped.engine.datasource.UfedXmlReader.read(UfedXmlReader.java:209)
at iped.engine.datasource.ItemProducer.run(ItemProducer.java:123)

I started checking all the ones that gave errors and found one thing common in all of them.
These UFDRs came from a real case and I don't know how these extractions were carried out with Cellebrite.
There are normally 2 files, as in the example below:

But the ones that give errors have more files, some with several files much larger than the ufdr itself.
see these 2 examples:

Looking at the files they look the same, although the hash is not.

The ufdr files don't open with 7z because they really aren't a zip, they're something very strange.
Ve

But if cellebrite opens it, it shouldn't be the .ufdr that it is reading.

Has anyone ever seen a situation like this?

After I removed these files from processing, the other 35 that remained seem to be doing well, so far.
But obviously it will take a long time.

[lfcnassif]

Hi @paulobreim. Those UFDR files are actually segmented ZIP files with a special content. If IPED complains they are invalid, maybe some segment is corrupted (or missing). I suggest you renaming the main file (the UFDR) to ZIP and to try to uncompress it using 7zip, it should extract the content of all Z01, Z02, etc files automatically and warn if some is corrupted.

[paulobreim]

Hi @lfcnassif ,
I tried, but the file ufdr show that is not a zip file.

See that the first lines are a txt and are still in a strange format. The first line has this which indicates that there should be things like a beforehand.
After a certain bit this txt has binary stuff.

In this case there are 3 zips very big.

What makes me curious is how cellebrite is managing to treat these files. And in this example it opens the 3 zips to work.
I need more time to be able to analyze this with more study.

Thank you for you attention.

[paulobreim]

I did some more tests and cellebrite really has something strange.
Although the .ufdr file appears to be invalid, even starting with a piece of txt files, when I run cellebrite it opens the file .z01 file and runs correctly.