0

My code only recovers images till 008.jpg and does not pass the 000.jpg or 0001.jpg test of check50. What is wrong with my code?

Here is my code - https://pastebin.com/QmJG7ccX

UPDATE 1 - https://pastebin.com/kuN09swU

UPDATE 2 - So I'm able to recover all 50 images now, but they appear to have only one block of 512 bytes. Where am I going wrong?

Here is the code - https://pastebin.com/tZb8cC6N

UPDATE 3- Just added an else before

if(c>0)

in update 2 code and now all the images are being recovered properly except for 000.jpg

UPDATE 4 - Finally Got it working :D

1

UPDATE 1 code:

This declaration char* buff[512]; is a problem. Remember, a char is in the range of 0 - 127. Use a "byte" type, as in bmp.h from recover.

Program always writes a block that is not a sig block, therefore it will be writing the "garbage" data from the beginning of the raw file to the first (000) jpg. It needs (at least) one more test


First a small problem: "00%i.jpg". This says "pad with 0 to a maximum width of 0". So there will be no padding at all. The output will be 1.jpg, 2.jpg, etc instead of 001.jpg, 002.jpg.

Now the really big problems:

  • This while(fgetc(src)!=EOF) reads one character at a time. The next thing it does is fread(&tmp,sizeof(JBLK),1,src);: ie, read the next 4 bytes. The chances that it will find a jpg signature at a 512-byte boundary are low (8 out of 50 perhaps?). And it also increases the liklihood that it will find a sig in the middle of a block! The "unit-of-measure" for this assignment is 512-byte blocks because a jpg starts on a block boundary, and occupies X blocks.
  • within the while loop, program only reads and writes 4-byte (JBLK) chunks. fgetpos and fsetpos are file position functions, they don't access any data in the file.

It might serve you well to watch the walkthrough again. Pay special attention to the psuedocode at 8:00. You need to read the file in 512-byte chunks, and decide what to do with each chunk. There are only 3 choices:

  1. If no jpg found yet, ignore it.
  2. If it's a jpg signature, start a new jpg.
  3. Otherwise, write block to current jpg.
| improve this answer | |
  • Watch the position of the %, 00%i.jpg means always add 00 before the number, however long it is going to be. – Blauelf Jun 20 '17 at 12:06
  • I've changed my code, I'm uploading the new one. Now I can only recover half the JPEG. Please have a look? – Archit Checker Jun 20 '17 at 12:16
  • At the risk of being snarky, you uploaded new code within 36 minutes of getting the answer. To me that indicates you have not done the requisite (any?) debugging on your own. When program recovers half the jpgs it usually indicates a double read. Like while(fread.....) and then fread in that loop. (I have not looked at your new code). – DinoCoderSaurus Jun 20 '17 at 12:43
  • I did the debugging on my own :( I had actually created two files sets of code, one using 4 bytes and another using a buffer of 512.. I couldn't figure out how to read the signature when using the buffer of 512 but i rewatched the walkthrough and made a few minor changes :( – Archit Checker Jun 20 '17 at 12:50
  • Anyway, Thank you. I will look for double reads.. – Archit Checker Jun 20 '17 at 12:53

You must log in to answer this question.

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