This is a follow up to my previous question. After I went through my code on debug50 it shows that my while on line 35 is not going through. I checked my code with other others on this site and they seem to match up so I can't tell why it is being skipped. I am just wondering if there is a way to fix it.

This is my code:

#include <stdio.h>
#include <stdlib.h>
#include <stdint.h>
typedef uint8_t BYTE;

int main(int argc, char *argv[])
    // checks if the right things were writen
    if (argc < 2)
        printf("Write: ./recover card.raw \n");
        return 1;
    // stores file info
    BYTE buffer[512];
    // keeps trak of the num of jpgs
    int jpgnum = 0;
    // name of jpgs
    char name[8];
    // memory card
    FILE *file = fopen(argv[1], "r");
    // checks if there is forensic image
    if (file == NULL)
        printf("Can't open memory \n");
        return 1;
    // the img
    FILE *img = NULL;

    const int BLOCK_SIZE = 512;

    // repeats until end of card
    while (fread(buffer, 1, BLOCK_SIZE, file) == BLOCK_SIZE) // skips while loop
        printf("L"); // testing print


        // checks if is starting of new img
        if (buffer[0] == 0xff && buffer[1] == 0xd8 && buffer[2] == 0xff && (buffer[3] & 0xf0) == 0xe0)
            // if it is NOT the first img then close previous image
            if (img != NULL)
            // set and write to the img
            sprintf(name, "%03i.jpg", jpgnum);
            img = fopen(name, "w");
            fwrite(buffer, 1, 512, img);
            // increase jpgnum by 1
            // if not starting then continue writing
            if (img != NULL)
                fwrite(file, 1, 512, img);
    // close files
    fclose(img); // segfaults here due to there being no img file made

I just want to say it segfaults on line 67 because of there not being an imaged open. Also if someone could help I would appreciate it.

1 Answer 1


First of all, are you sure that you remembered to recompile/make a new executable from the new source code file? The while loops are working fine.

When I test the code, it's generating the correct number of files, but they are corrupted. The cause is very similar to the problems you were previously having - use of the wrong vars. Look at line 61:

            fwrite(file, 1, 512, img);

This reads 512 bytes from the var file, which is a pointer. That means that it's reading 512 bytes whatever raw data is stored in memory at the starting address of the file var itself and continuing into whatever data and vars are physically mapped in memory from that point on. It's definitely not reading from the actual input file.

BTW, shouldn't it be reading from the buffer instead? ;-)

Another programming tip: If you're going to create a var to hold a constant, use it everywhere it's appropriate. The code creates BLOCK_SIZE on line 31. It should have been created earlier, perhaps in a define statement, and used on line 15 to define the size of buffer[]. If the block size were to be changed at a future date, the odds are that the size of buffer wouldn't be updated, leading to a logic bug.

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

  • I recompiled my code again but it is still skipping the while loop. Could this be a problem with my codespace?
    – Raheel A
    Sep 30, 2023 at 19:11
  • Hmmm...... I see no reason related to the code that would cause the code to never execute the loop unless the code is never finding a signature. There is one possibility that comes to mind. Check the size of the input file. Is it zero??? Is it possible that it was emptied because you had a previous version of the code that opened the input file for write instead of read? If that happened just once, the file would be emptied and perhaps had other data added to it at some point. I suggest you re-download the zip file and replace the card.raw input file from the zip file.
    – Cliff B
    Sep 30, 2023 at 19:16
  • That has worked
    – Raheel A
    Oct 1, 2023 at 0:24
  • This is a good lesson. Problems aren't always bad code. Bad input data can cause a lot of frustration too. ;-)
    – Cliff B
    Oct 2, 2023 at 2:35

You must log in to answer this question.

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