다음은 tillberg의 추가 연구 덕분에“복원 된”이미지입니다.
예상 한대로 약 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 바이트입니다.
이미지 직전과 직후에 나타나는 16 진 덤프 (수십 바이트)를 제공 할 수 있다면 도움이 될 것입니다. 이것은 블록의 시작 또는 끝에 어떤 종류의 정보가 저장되는지에 대한 힌트를 제공합니다.
물론 추출 코드에 버그가있을 가능성도 있습니다. 파일 작업에 16384 바이트의 버퍼를 사용하는 경우 먼저 확인합니다.
