One thing not accounted for in this design is the possibility of finding a "false jpg sig" in the middle of a 512-byte block. Recall 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.

Think "greedy". Since the sigs are "block-aligned", a better approach would be to read the raw file in 512-byte blocks.

One thing not accounted for in this design is the possibility of finding a "false jpg sig" in the middle of a 512-byte block. Recall 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.

Think "greedy". Since the sigs are "block-aligned", a better approach would be to read the raw file in 512-byte blocks.

Let's imagine a card.raw with 1 "junk" block and 3 jpgs that looks something like this: ([blah] is any 4 bytes, [sig ] is a 4byte jpg signature)

[blah] [sig ] [blah].....to 512.....[blah]
[sig ] [blah] [blah].....to 512 ....[blah]
[sig ] [blah] [blah].....to 512 ....[blah]
[sig ] [blah] [blah].....to 512 ....[blah]

The first checkSig returns 0, file pointer is at 4th byte.. The second checkSig returns 1. Where is the file pointer? At the 5th byte. So fread(buffer, sizeof(unsigned char) * 512, 1, intpr); starts reading at the 5th byte. It will never find a jpg sig.