Flash Memory Recovery Attempts

Initial inspection of the flash memory card showed JPEG images; however, attempting to copy some of the images would cause Windows Errors (Failed copy attempts). Using another device seemed to allow the problematic images to be copied.

Understanding the JPEG File Format

• JPEG – Joint Photographic Experts Group

•  How a JPEG image is made

  • Divides original image into small chunks (typically 8x8 pixels)

  • Quantizes these chunks (Data loss occurs)

  • Huffman Coding (Compresses the Quantized Data)

JPEG Main File Markers

• SOI (Start Of Image) [FF D8]

  • Indicates the beginning of the image data.

• APP (Application) [FF E0, FF E1, FF E2]

  • Provide information, such as the software used to create it and any EXIF.

• DQT (Define Quantization Table) [FF DB]

  • Defines the quantization table used to compress the image data.

• DHT (Define Huffman Table) [FF C4]

  • Defines the Huffman table used to compress the image data.

• SOS (Start Of Scan) [FF DA]

  • Indicates the beginning of the image data for each scan.

• EOI (End Of Image) [FF D9]

  • Indicates the end of the image data.

Hex Values using Hexed.it

Initially, a Python script to convert JPEG files to Hex values was written to examine the file (Link to Python Code); however, after a little bit of research, a website called hexed.it was used to investigate the files better. The tools, such as a histogram viewer, make it convenient. The Hexdump tool in Linux can also be easily used in the terminal.

Corrupted File

In the corrupted file, you can see a lot of "noise" at the start of the file HEX values below (Figure 1). The histogram also shows higher peaks compared to the non-corrupt file. While further examining the corrupt file, I noticed that its entropy was 7.96 bits/bytes, which I initially thought was a cause for concern, but the non-corrupt file had a higher entropy of 7.97 bits/bytes.

Not Corrupt File

The non-corrupt JPEG file has a clear Start of Image marker (FF D8) at the start of its HEX values (Figure 3). The data shows the APP marker (FF E1), where the Exif information is stored. The file's histogram (Figure 4) is even more constant than the previous one, lacking peaks. 

1st Repair Attempt

The first attempt was made using JPEG-Repair by Disktuna, as shown in Figure 5. The results of this attempt were poor. While there is a visible pattern, there is no clear discernible image. The results of this attempt can be seen below in Figure 6. A separate effort was also made using a program called Stellar Repair for Photo; however, the results were also lackluster, showing a patterned image with no discernable detail.

2nd Repair Attempt

I wrote a simple Python script (Link to Python Code) to chop up the file's HEX text file based on the starting marker (ffd8). Then used a separate Python script (Link to Python Code) to convert it into JPEG files. This is when I found multiple images in the one supposed JPEG file. Further looking into this, I showed that the file size was around 62 MB.

Found AVI Markers

At this point, I scrubbed through the file again using Hexed.it and found AVI markers (Figure 10). Clearly proving that the corrupt JPEG file was actually a corrupt AVI file.

3rd Attempt

Using the trial Stellar Data Recovery tool, I got a poor, jittery video result; however, it showed that there was enough data present to make a video.

Final Attempt

In my final attempt, I just used my previous Python code to get a series of images; then, I stitched them together using video editing software.

It is worth noting that Python Codes need to be done in the correct order and with minor changes to file names to work correctly. While all of these steps could have been completed with a single proper Python script, all my work was done in an iterative matter only to see If there was usable data.