recover.c, Can not open JPG's

Question

I got stuck on recover.c. It saves 10 JPG's to file but i'm only able to open the first one. Of this first JPG i can only see a small part of the upper side of the picture.

when I look at the first 4 bytes of the 2nd till the 10nd JPG, it shows a part of the JPG signature. ff or d8 but not the whole signature ffd8 ffe0 or ffd8 ffe1.

/** * recover.c * * Computer Science 50 * Problem Set 4 * * Recovers JPEGs from a forensic image. */

include

int main(int argc, char* argv[]) { if (argc != 2) { printf("Usage: ./...., infile (Compact Flash)"); return 1; }

//assign a pointer to argv[1], infile
char* infile = argv[1]; 

//opens the infile and allow to read. Assing to a FILE pointer
FILE* inptr = fopen(infile, "r");
if (inptr == NULL)
{
    printf("Could not open %s.\n", infile);
    return 2;
}
//+1 every time a new JPG is opened
int counter = 0;
// buffer to store a part of JPG
unsigned char buffer[512];
// place to store the filename of each new JPG
char filename[10];


do
{
    fread(&buffer, sizeof(buffer), 1, inptr);
}
//read till JPG begins
while (buffer[0] != 0xff && buffer[1] != 0xd8 && buffer[2] != 0xff && (buffer[3] != 0xe0 || buffer[3] != 0xe1));

do
{
    // open a new JPG 
    counter = counter + 1;
    sprintf(filename, "%03d.jpg", counter);
    FILE* img = fopen(filename, "w");

    do //read and write from the start of JPG
    {
        // write 512 bytes into JPG
        fwrite(&buffer, sizeof(buffer), 1, img);

        // read 512 bytes into buffer
        fread(&buffer, sizeof(buffer), 1, inptr);

    }
    // while not a new JPG or end of file    
    while (buffer[0] != 0xff && buffer[1] != 0xd8 && buffer[2] != 0xff && (buffer[3] != 0xe0 || buffer[3] != 0xe1));


    fclose(img);
} 
// check if not end of file
while (buffer[0] != 0x00 && buffer[1] != 0x00 && buffer[2] != 0x00);

fclose(inptr);

}

Answer 1

There are a number of issues in the code. A rework of the code is in order.

In several places, you do a negative test, checking that bytes 1 through 4 are not something. The problem lies here: (buffer[3] != 0xe0 || buffer[3] != 0xe1) If you analyze it, this clause will always evaluate as true. Think about it. If buffer[3] = 0xe0, the first clause is false, but the second clause must be true. If it is 0xe1, the reverse is true. In either case, if one of the subclauses is true, then the whole is true. IF buffer[3] doesn't match either e0 or e1, then the clause is true on both sides, so the whole clause is always true.

You can't just reverse == for != across a complex clause, it doesn't work that way. However, if you're looking for the opposite of a==x && b==y && c==z && ( w==p || w==q) the simple way to do it is !( a==x &&... ) Just enclose the whole positive version of the test in parentheses and negate it.

There are no actual tests for end of file (EOF). At one point, you have this:

// check if not end of file
while (buffer[0] != 0x00 && buffer[1] != 0x00 && buffer[2] != 0x00);

This is not a valid end of file check. All this does is check for three bytes that contain all zeros, which is exactly what you are finding while processing the 10th file. There is actually an EOF representation. Check the documentation for fread and the values that it will return.

Minor issues: the filenames start with 000, not 001. The assignment says to check for sixteen different values in the 4th byte, not the two mentioned in the video, which is a carryover from a prior year. (The assignment was updated.) Also, the input file name is hardcoded in the program. The program should not be requesting it as a parameter.

Another piece of advice - the more calls to fread and fwrite in a program, the greater the complexity and the more likely problems will be. This program can be written with one of each, with the right logic flow.

There may be more issues, but until some of the major ones are dealt with, drilling down any further serves no purpose as those issues may disappear with rewriting for the major issues.

If this answers your question, please click on the check mark to accept. Let's keep up on forum maintenance. ;-)