Recovery of deleted...
Clear all

Recovery of deleted video from Galaxy S3

New Member

Hello fellow forensicators. I'm new to the boards here (and mobile forensics in general), looking for some help with a video taken with a Galaxy S3 which was deleted and needs to be recovered.

I've run it through the Cellebrite (we have the UFED Classic), but I've gotten very little in regards to the video. I can see that the file did exist (correct date and time), but it's listed as 0kb in size (and deleted).

I did come across an interesting piece of information that looks to be of some value

/Root/data/ lists an Epoch "mImportTime" that would correspond to about five minutes after the video was taken.

Unfortunately, that's about all I've found with Cellebrite.

I did also attempt a recovery with IEF, and although IEF pulled considerably more useful and user-friendly information in general (found several videos that Cellebrite did not), it did not produce the results I was hoping for in regards to this specific video.

What would be most helpful (aside from actually getting the video) would be if there were some way to show when the video was deleted.

I'd be happy to try to reconstruct the hex with known good headers and footers if I could find the bit that should remain - but I can't find it!

Does anyone have any tools, tips, or tricks for any of this? I've been scouring the 'net for resources, but haven't come across anything useful.

Thanks for any insight!

Topic starter Posted : 07/01/2015 3:27 am

Maybe you can provide some more information.
Did you extract the device logical or physical with Ufed?
Do you know what kind of video you are talking about, do you have a filename or maybe a copy of the video?
I understand if the actual filename isn't available for sharing.

If you have a copy of the file, you know what kind of file and encoding you're looking for.
Maybe have a look at the tool Defraser, it can recover videofragments.

Posted : 07/01/2015 1:23 pm
Active Member

As I know, you could do physical extraction from Galaxy S3 with ufed ultimate. Once done,you could use some tools to do carving from image file. I know some tools could carve by file signature. even it is not common type and you could add manually.
Winhex is good at carving.

Wish you success~

Posted : 07/01/2015 1:42 pm
Senior Member

I do not know anything about Galaxy video recording. However, almost all videos I have seen are not recorded in sequence. Typically the moov data is physically stored last, but logically stored first. This is taken care of by the file mapping of the file system (FAT on many FAT32 chips).

I have spend much time developing routines as part of my program to process video files. It can often reconstruct working non sequential files when all file allocation has been lost. Please send me a PM if you require more help.

Many carving programs will find headers, and then assume that the data is sequential. This results at best in a black video with no sound. Other people try and repair a video, but actually what happens there is that video one header is matched with video two data, and these could be very different lengths, and may even include embedded JPEGs.

For my routine to work, you would need the equivalent of a DD dump of the 'drive'. I am not sure if this is possible from the Galaxy.

Posted : 07/01/2015 4:37 pm
New Member

Thank you all for your prompt replies!

To answer some questions

This was a physical extraction. The extraction file is a DumpData.bin file.

The video is an mp4.

The file name is the following format YYYYMMDD_TTTTTT.mp4

Judging by other files (working files) of this same type on the device, I see the hex of the header as

00 00 00 18 66 74 79 70 69 73 6F 6D 00 00 00 00 69 73 6F 6D 33 67 70 34 (….ftypisom….isom3gp4)

I will take your suggestions and do some ore digging. I do have one further question

If dropbox was set to try to upload the video (which it certainly appears to have tried to do), would it have retained a copy of the video somewhere else?

I have the following listed in one of the db files {"mServerHash" [followed by the hash in quotes], "mImportTimeoffset" [followed by the correct offset], then the batch file number, MimeType, ContentUri, and the FilePath, then the "mImportTime" listed in Epoch time, and the row ID}

In each reference to the file in question, the file path is listed as storage/emulated/0/DCIM/Camera/[file name]. Is there any good way to tell at what offset I should start searching for anything that may be left of it?

Again, thank you all so much.

Topic starter Posted : 07/01/2015 8:51 pm
Senior Member

I somehow doubt that a copy would have been made (and saved) if uploaded.

Looks like a standard MP4 file. Have you tried the CnW demo? Assuming the .BIN file is a standard DD file it may work

Posted : 07/01/2015 10:02 pm
New Member

use ufed make physical image
S3 root needed, CF-Auto-Root may help you to root the device.
and use rstudio/wihex to scan this image
it is eazy to recover photoes, GOOD luck!

Posted : 08/01/2015 7:59 am
Junior Member

Did the device have a Micro SD card in it or do you believe the video was stored on internal storage? There's some clues in the epoch time stamp from dropbox you mentioned was possibly created at the end of the video recording which means you are looking for around 5 minutes worth of video? It's possible that the video was never recorded to the internal storage and instead saved to a memory card? I would be pulling out the sqlite databases and any other files from dropbox and looking for any entries that can corroborate your filenames and the possible upload.

Posted : 06/11/2015 1:09 pm
Active Member

You can import UFED Android physical image into Oxygen Forensic Analyst or Oxygen Forensic Detective and search for a deleted video file there. Probably you will find more data about this video.

Posted : 06/11/2015 5:13 pm
Senior Member


Once a sector of a SD card has been overwritten, the data has gone. The only hope of any possible recovery would if the overwritten sector had been reallocated for wear levelling. The chance of recovering a useful sector is extremely low, and the chance of recovering a file is zero.

Posted : 20/11/2015 2:49 pm
Share to...