Recover Only getting half of the images

Question

I feel like I have a decent approach to the recover solution. I seem to be missing something however, and I'd like to ask to be pointed in the right direction.

If I can't get it right I'll switch to the flag approach instead but I felt like this had some potential and I don't want to abandon it if I can figure things out.

I'm only getting images 000 -> 024 and I'm passing all but the middle images and the last image checks on check50.

I have an idea of where I might be going wrong but I'd like second opinions.

Here's what I have:

/**
 * recover.c
 *
 * Computer Science 50
 * Problem Set 4
 *
 * Recovers JPEGs from a forensic image.
 */
#include <stdint.h>
#include "stdio.h"
#include "stdbool.h"

typedef uint8_t  BYTE;
#define SIZE 512

#define JPG0 0xff
#define JPG1 0xd8



BYTE buffer[SIZE];
int addr = 0;
int num = 0;
int jpg = 0;



bool LoadBuff(FILE* card)
{
  // Load up the buffer 
  for(int i = 0; i < SIZE; i++)
  {
    if(fread(&buffer[i], sizeof(BYTE), 1, card) == 0)
    {
      return false;
    }
  }

return true;
}


void WriteBuff(FILE* out)
{
  for(int i = 0; i < SIZE; i++)
  {
    fwrite(&buffer[i], sizeof(BYTE), 1, out); 
  }
}


bool SearchBuff()
{
  bool test = false;

  for(int i = 0; i < SIZE; i++)
  {
    if(i < 511)
    {
      if(buffer[i] == JPG0 && buffer[i+1] == JPG1 && buffer[i+2] == JPG0)
      {

        printf("\n\tJPEG FOUND! #%i at %07x\n\n", num, addr);
        num++;
        return true;
      }

    }

//    printf("%07x:\t%02x\n",addr , buffer[i]);
    addr++;
  }

return test;
}


void ClearBuff()
{
  for(int i = 0; i < SIZE; i++)
  {
    buffer[i] = 0x00;
  }
}




int main(/*int argc, char* argv[]*/)
{
  /* 


      Function specs follow:

        LoadBuff: Takes inptr. Bool                                                      [X]
          Function loads buffer from offset to offset + 511
          and detects end of file when fread gets 0 objects.

        SearchBuff: No param. Bool                                                       [X]
          Returns True if the leading bytes are found in the right 
          sequence inside the 512 byte buffer.

        WriteBuff: Takes outptr. Void -?-                                                [X]
          Writes every byte in the buffer to file.


        ClearBuff: No Param. Void                                                        [X]
          Clears buffer by zero writing the 512 bytes.
          --Note: This is a function that can probably be left out, 
                  but could be good insurance against write errors.

  */

  FILE* card = fopen("card.raw", "r");
  char name[8];


  //ClearBuff();

  while(LoadBuff(card))
  {
    if(SearchBuff())
    {
      // Create Filename
      sprintf(name, "%03i.jpg", jpg);

      // Open file
      FILE* img = fopen(name, "w");
      do
      {
        WriteBuff(img);
        //ClearBuff();
        LoadBuff(card);

      }
      while(!SearchBuff());

      // Close file
      fclose(img);
      jpg++;
    }

    //ClearBuff();
  }


  fclose(card);

return 0;
}

Answer 1

One thing that might be making your program go awry is here if(buffer[i] == JPG0 && buffer[i+1] == JPG1 && buffer[i+2] == JPG0) in SearchBuff. Remember from the spec:

Thanks to FAT, you can trust that JPEGs' signatures will be "block-aligned." That is, you need only look for those signatures in a block’s first four bytes.

Isn't that searching for the (partial*) signature anywhere in the block?

* From the spec:

The fourth byte, meanwhile, is either 0xe0, 0xe1, 0xe2, 0xe3, 0xe4, 0xe5, 0xe6, 0xe7, 0xe8, 0xe8, 0xe9, 0xea, 0xeb, 0xec, 0xed, 0xee, of 0xef. Put another way, the fourth byte’s first four bits are 1110.

Why is it only finding 1/2 of the pictures? If this while(!SearchBuff()); is true, that means the last LoadBuff(card); (in the do/while) found a sig. Where does control go next? Here while(LoadBuff(card)), which reads the next block. Which is (presumably) not a jpg sig, so it won't write a new file 'til the next next jpg comes along. You are only getting images named 000 -> 024. Compare you outputs to the staff outputs. You should see that you are getting only the "even named" jpgs from staff version.