यहाँ "बहाल" छवियां हैं, जो कि टबर्ग के आगे के शोध के लिए धन्यवाद:
जैसा कि अपेक्षित था, 0x4020 बाइट्स के बारे में हर 5-बाइट ब्लॉक मार्कर है । प्रारूप निम्न प्रतीत होता है:
struct marker {
uint8_t tag; /* 1 if this is the last marker in the file, 0 otherwise */
uint16_t len; /* size of the following block (little-endian) */
uint16_t notlen; /* 0xffff - len */
};
एक बार मार्कर पढ़ने के बाद, अगला marker.lenबाइट्स एक ब्लॉक बनाता है जो फ़ाइल का हिस्सा है। marker.notlenएक नियंत्रण चर ऐसा है कि marker.len + marker.notlen == 0xffff। आखिरी ब्लॉक ऐसा है marker.tag == 1।
संरचना शायद इस प्रकार है। अभी भी अज्ञात मूल्य हैं।
struct file {
uint8_t name_len; /* number of bytes in the filename */
/* (not sure whether it's uint8_t or uint16_t) */
char name[name_len]; /* filename */
uint32_t file_len; /* size of the file (little endian) */
/* eg. "40 25 01 00" is 0x12540 bytes */
uint16_t unknown; /* maybe a checksum? */
marker marker1; /* first block marker (tag == 0) */
uint8_t data1[marker1.len]; /* data of the first block */
marker marker2; /* second block marker (tag == 0) */
uint8_t data2[marker2.len]; /* data of the second block */
/* ... */
marker lastmarker; /* last block marker (tag == 1) */
uint8_t lastdata[lastmarker.len]; /* data of the last block */
uint32_t unknown2; /* end data? another checksum? */
};
मुझे नहीं पता है कि आखिर क्या है, लेकिन चूंकि PNG पैडिंग स्वीकार करते हैं, इसलिए यह बहुत नाटकीय नहीं है। हालाँकि, एन्कोडेड फ़ाइल का आकार स्पष्ट रूप से इंगित करता है कि अंतिम 4 बाइट्स को अनदेखा किया जाना चाहिए ...
चूंकि फ़ाइल की शुरुआत से ठीक पहले मेरे पास सभी ब्लॉक मार्करों तक पहुंच नहीं थी, इसलिए मैंने इस डिकोडर को लिखा जो अंत में शुरू होता है और ब्लॉक मार्करों को खोजने का प्रयास करता है। यह बिल्कुल मजबूत नहीं है, लेकिन अच्छी तरह से, यह आपकी परीक्षण छवियों के लिए काम करता है:
#include <stdio.h>
#include <string.h>
#define MAX_SIZE (1024 * 1024)
unsigned char buf[MAX_SIZE];
/* Usage: program infile.png outfile.png */
int main(int argc, char *argv[])
{
size_t i, len, lastcheck;
FILE *f = fopen(argv[1], "rb");
len = fread(buf, 1, MAX_SIZE, f);
fclose(f);
/* Start from the end and check validity */
lastcheck = len;
for (i = len - 5; i-- > 0; )
{
size_t off = buf[i + 2] * 256 + buf[i + 1];
size_t notoff = buf[i + 4] * 256 + buf[i + 3];
if (buf[i] >= 2 || off + notoff != 0xffff)
continue;
else if (buf[i] == 1 && lastcheck != len)
continue;
else if (buf[i] == 0 && i + off + 5 != lastcheck)
continue;
lastcheck = i;
memmove(buf + i, buf + i + 5, len - i - 5);
len -= 5;
i -= 5;
}
f = fopen(argv[2], "wb+");
fwrite(buf, 1, len, f);
fclose(f);
return 0;
}
पुराना शोध
0x4022दूसरी छवि से बाइट हटाते समय आपको यही मिलता है , फिर बाइट को हटाकर 0x8092:
यह वास्तव में छवियों की "मरम्मत" नहीं करता है; मैंने यह परीक्षण और त्रुटि के द्वारा किया। हालांकि, यह जो बताता है कि हर 16384 बाइट में अप्रत्याशित डेटा है। मेरा अनुमान है कि छवियों को किसी प्रकार की फाइल सिस्टम संरचना में पैक किया गया है और अप्रत्याशित डेटा केवल ब्लॉक मार्कर हैं जिन्हें आपको डेटा पढ़ते समय निकालना चाहिए।
मुझे नहीं पता कि वास्तव में ब्लॉक मार्कर कहां हैं और उनका आकार, लेकिन ब्लॉक आकार ही सबसे निश्चित रूप से 2 ^ 14 बाइट्स है।
यह मदद करेगा कि क्या आप छवि के ठीक पहले और उसके ठीक बाद दिखाई देने वाली हेक्स डंप (कुछ दर्जन बाइट्स) भी प्रदान कर सकते हैं। यह संकेत देता है कि किस तरह की जानकारी ब्लॉक की शुरुआत या अंत में संग्रहीत है।
बेशक वहाँ भी संभावना है कि आपके निष्कर्षण कोड में एक बग है। यदि आप अपने फ़ाइल संचालन के लिए 16384 बाइट्स के बफर का उपयोग कर रहे हैं, तो मैं सबसे पहले वहां जांच करूंगा।
