1

I had been working on this for 6+ hours and could not figure out what was going on. All 50 images are produced, but when I opened them, I saw no pictures in it. What is wrong? Please help me out, and thank you so much!!!!! Here are the codes:

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

#include <stdio.h>
#include <stdint.h>

int main(void)
{
    // open CF card 
    FILE* CF_card = fopen("card.raw", "r");
    if (CF_card == NULL)
    {
        printf("Could not open %s.\n", "card.raw");
        return 1;
    }

    // define a counter that counts the number of JPEGs found, a buffer, a character that denotes a filename, and a global variable for the output file
    int JPEG_counter = 0;
    uint8_t buffer[512];
    char filename[8];
    FILE* img = NULL;

    // read CF card
    while(fread(&buffer, sizeof(buffer), 1, CF_card) == 1)
    {

        // JPEG signature hunt
        if((buffer[0] = 0xff) && (buffer[1] == 0xd8) && (buffer[2] == 0xff) && (buffer[3] >= 0xe0) && (buffer[3] <= 0xef))
        {
            if (img != NULL)
            {
                fclose(img);
            }

            // JPEG found, create new file
            sprintf(filename, "%.3d.jpg", JPEG_counter);

            // open newly created file
            img = fopen(filename, "w");
            if (img == NULL)
            {
                fclose(CF_card);
                fprintf(stderr, "Could not create %s.\n", filename);
                return 2;
            }

            // keep track of JPEG found
            JPEG_counter++;

            // write to newly created file
            fwrite(&buffer, 512, 1, img);
        }

        // continue to write to the same file until the next JPEG is found
        else if (JPEG_counter > 0)
        {
             fwrite(buffer, sizeof(buffer), 1, img);
        }

    }
    // close the file
    fclose(CF_card);
    return 0;
}
2

Well, it took me a while to recognize the root cause. Along the way, I verified that output files were the right size, that the opening 120 bytes were right, etc., etc.

Then, I noticed that the first byte of the second and every block that followed was always ff. Hmmm.....

Since it took so long for me to find it, I'll narrow the search for you. ;-) Look at the following line:

    // JPEG signature hunt
    if((buffer[0] = 0xff) && (buffer[1] == 0xd8) && (buffer[2] == 0xff) &&
       (buffer[3] >= 0xe0) && (buffer[3] <= 0xef))

Do you see anything wrong??? There's an error. To teach the lesson, and make sure it burns into the farthest reaches of your brain, (and payback :-P ) I'll let you find it yourself! :-D I will guarantee that the problem lies in this line of code though.

(I want this to set in because I made this mistake over and over when I first started programming and it haunted me for a long time. Hopefully, this will save you from that. )

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

7
  • No I get it. Thank you so much! If I made that mistake, however, why was the program still able to make 50 JPEGs successfully?
    – Alex Chan
    Oct 11 '16 at 6:05
  • Well, that depends on your definition of success. Yes, it made 50 files. No, they weren't valid. Why did it make any files? When you do while (a=b) instead of while (a==b), it actually sets the contents of a equal to the contents of b. More important in this case, an assignment operation always returns true (unless, possibly, the assignment fails - I've never tested that. hmmm...) So, the content of the first byte didn't matter. It would be set to ff by the assignment. (Continues....)
    – Cliff B
    Oct 11 '16 at 6:27
  • Thank you for your comment Cliff. I have corrected my mistake. The program now compiles and creates 50 valid images. It, however, does not pass Check50, do you have any idea?
    – Alex Chan
    Oct 11 '16 at 6:33
  • (...continued) If there had been any blocks where the 2nd thru 4th bytes matched a signature but the 1st didn't, the 1st byte would be set to ff and a new file opened. Since there aren't any in the data, only the 50 files are created. This is a flaw that hid the problem really well! At the same time, the first byte of every 512 byte block was changed to ff. I tried to find the reason for the invalid file error for quite a while. I looked at the beginning 120 bytes, the end of the file, file sizes, etc. I only saw the problem when I looked at the changed beginning of the second block!
    – Cliff B
    Oct 11 '16 at 6:34
  • No idea what's wrong now without seeing the check50 output and the updated code. When I fixed these errors, it works fine.
    – Cliff B
    Oct 11 '16 at 6:34

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .