78 9C 헤더가있는 데이터베이스 파일?

Question

이상한 데이터베이스 파일 형식으로 작업하게되었습니다. 각 DB에는 두 개의 파일이 있습니다. 하나는 "database.db"이고 다른 하나는 "database.key"입니다.

".db"파일은 항상 0x78 0x9C 이진 헤더로 시작하지만 ".key"는 항상 파일의 임의 부분에 "1.00 Peter 's B Tree"문자열을 포함합니다.

온라인으로 볼 때 헤더 0x78 0x9C는 압축 Zlib를 참조 할 수 있지만 데이터베이스 내용을 볼 수있는 방법을 찾지 못했습니다.

누구든지이 형식으로 나를 도울 수있는 것을 알고 있습니까? Thnaks :

편집 1 : 그것 ".DB"파일이 하나 이상의 ZLIB 수축 스트림이 포함되어 있는지 나타납니다 는 0x9C 0x78을 서명은 파일의 시작 부분 만의 다른 부분에만 존재하지를 그것. 내가 2 개 개의 새로운 압축 스트림을 얻을 thoose 2 스트림을 팽창하여

78 9C CB 63 40 07 33 76 5B 6A AF 78 DD 54 23 CE C9 90 C4 78 89 81 89 81 F1 22 86 9A ED 6A D7 44 F6 03 D5 B0 31 30 94 60 91 F6 D4 2A 76 3B 0C 94 E6 63 60 2C 51 B6 63 00 00 22 13 11 57 
78 9C CB 63 40 07 2F 53 D7 B8 9F EC 8B B2 E1 7A F1 32 87 F1 12 03 23 03 E3 45 0C 35 4B B7 68 5B CD 90 2E E7 65 67 60 2A 51 B6 63 00 00 A6 E8 0C 5D 

: 예를 Fo로이 내가 하나 개의 파일에서 찾을 수있는 스트림의 일부입니다.

내가 한 것은 ".db"파일을로드하고 바이트 배열 목록을 만든 C# 프로그램입니다. 바이트 배열은 압축 된 스트림입니다. 이렇게하려면 78 9C마다 파일을 분할하면됩니다.

이것은 ".DB"일부 파일 만 작동하도록 보인다

, 다른 상황에서이 스트림

78 9C E2 13 FD 2F 14 9F CD 9B 29 3E 65 9F A0 F8 BC 7C 92 E2 93 EF 29 8A CF B0 A7 29 3E 8D FE 4A F1 B9 F2 0C C5 27 C4 B3 14 EF F5 5B 28 DE B5 B7 52 BC FF 6E A3 78 27 DD 4E F1 9E B8 83 E2 DD 6D 27 C5 FB D4 2E FA F0 6A EE A6 78 EF 78 EE EA 2F AA D3 91 FE 1F 2F 94 78 6C 

또는 "잘못된 저장된 블록 아이폰에와, 나에게"잘못된 거리 코드 "와 같은 약간의 오차가 준 "이 스트림에 관해서는

78 9C 90 35 CE 34 2F 0C 7D FE A5 57 C9 FF D5 2B 47 5B B7 C4 7F 69 EA 3F 0F AC 25 F4 45 49 3D CC FF 00 E5 AE 30 40 

어쩌면 단순히 각 78 9C에서 파일을 분할하는 것은 그 일을의 올바른 방법은 아니지만 ...

에".KEY "파일 : 나는 열 수 있었다 그들 Peter Graf "PBL"의 라이브러리를 사용합니다. "pblKfGetAbs()"(http://www.mission-base.com/peter/source/pbl/doc/keyfile.html)를 사용하여 파일의 각 키와 관련된 모든 레코드를 가져올 수있었습니다. 이 레코드는 4 바이트 값입니다. 16 진수 편집기를 사용하여 압축 해제 된 ".db"파일 (압축 프로세스 중에 오류를주지 않는 파일에서)에서이 값을 검색하면 몇 가지 결과 만 얻을 수있었습니다. 중요한 파일에 대한 기록은 이해가 안됩니다. ...

도움 감사합니다!

Answer 1

예, 가능성이 높습니다. zlib 스트림이 데이터베이스에 저장되어 있습니다.

압축 된 데이터에 78 9c이 나타나지 않으므로 단순히 파일 내용을 추출하는 것은 좋지 않습니다. 또한 78 9c 만 유효한 zlib 헤더가 아닙니다. 유효한 zlib 스트림을 찾는 가장 쉬운 방법은 모든 바이트에서 압축을 풀기 만하면됩니다. zlib는 유효한 zlib 헤더를 가지고 있지 않은 것을 대부분 빨리 배제 할 것입니다. 나머지는 완료 또는 실패 할 때까지 압축을 풀 수 있습니다. 양호한 무결성 검사 (Z_STREAM_END 반환)로 완료되면 이는 의도적으로 압축 된 zlib 스트림이었을 가능성이 큽니다.

상대적으로 거의 진행되지 않는 것으로 보이는 데이터 형식을 리버스 엔지니어링하려고합니다. 이것은 누군가가 형식을 알고 인식하는 경우를 제외하고는 stackoverflow가 도울 수없는 형사입니다.

Answer 2

.db 파일은 압축 된 데이터이고, .key 파일은 열어 본 후 색인 파일과 같은 .db에서 원하는 데이터를 찾기위한 key_information입니다.이 .db 파일에는 문자열 데이터가 없습니다. 런타임 데이터베이스이기 때문에 이러한 .db 파일은 'packets'과 같은 16 진수 데이터를 포함하며 압축 된 상태입니다.

Answer 3

이들은 zlib magic headers (Git, Memcached 등)에서 널리 사용됩니다. dd를 사용하기 전에, 예를 들어, 일부 바이트를 건너 뛰려면

printf "\x1f\x8b\x08\x00\x00\x00\x00\x00" | cat - zlib-file.dump | gunzip 

:

파일의 압축을 해제하려면 다음 명령을 사용할 수 있습니다 데이터가 CRC/길이 오류을 가지고있는 경우

cat <(printf "\x1f\x8b\x08\x00\x00\x00\x00\x00") <(dd skip=100 if=zlib-file.dump bs=1 of=/dev/stdout) | gunzip 

, 같은 결함 고려한다.