After getting data from old software, I can save it to a file with a specific format.
I wanted to extract the data from this file.
Unfortunately, this format is unreadable.
It seems to have specific characters (? or #).
I don't really understand how it is encoded but I have the data in the software to check the answer.
Here is a small sample of the bytes that the file contains:
0000-06f0: 10 db 2f 34-dc 80 c4 3f-8c e7 f7 ae-e6 61 02 40 ../4...? .....a.#
0000-0700: 41 69 af a4-f1 9e c2 3f-d9 e4 52 91-d4 1e 02 40 Ai.....? ..R....#
0000-0710: 50 0f be bc-f0 b5 c3 3f-df 4e 84 c9-0e e0 02 40 P......? .N.....#
0000-0720: 51 fe 42 71-a4 15 c3 3f-52 58 bc ab-ff f5 02 40 Q.Bq...? RX.....#
0000-0730: f6 26 e6 87-3c 27 c3 3f-ef 02 25 a5-db 9b 02 40 .&..<'.? ..%....#
0000-0740: 1e d4 37 19-a1 56 c3 3f-b5 76 c8 6a-34 3c 02 40 ..7..V.? .v.j4<.#
0000-0750: 81 34 51 8c-b0 f8 c4 3f-2e 74 d6 cd-4a 84 01 40 .4Q....? .t..J..#
0000-0760: 14 c7 40 00-7a 93 c5 3f-02 43 07 2b-76 a4 01 40 ..#.z..? .C.+v..#
0000-0770: c9 2d 42 c2-03 51 c6 3f-0c c5 30 d2-b5 38 01 40 .-B..Q.? ..0..8.#
0000-0780: 70 3e bb b0-cb 0a c8 3f-4b b7 12 c7-28 18 00 40 p>.....? K...(..#
0000-0790: 6a ad b4 7a-62 ae c7 3f-90 11 50 41-f1 f2 fd 3f j..zb..? ..PA...?
0000-07a0: 3a e9 01 1a-a7 f4 c7 3f-96 7b d0 a5-33 40 fd 3f :......? .{..3#.?
0000-07b0: 87 a1 ac 47-6c c0 c6 3f-90 78 3d 69-07 43 fe 3f ...Gl..? .x=i.C.?
0000-07c0: 36 d7 1c 39-43 27 c8 3f-d4 a3 47 47-80 df fd 3f 6..9C'.? ..GG...?
If someone knows how to decode it to get, it could be super useful.
Thanks.
I'm trying to change some data from an old PS1 game save file but the data keeps getting corrupted even though I isolated the exact bit I wanted to change and made sure nothing else was altered.
I changed some data for every save file and here's the possible checksum constant I found.
8A B5 2E CC
BD E6 AE 3A
B7 88 25 21
61 EC 03 37
35 3E 6D 59
11 48 91 D0
77 4B B2 85
85 55 F7 B5
Any advice or help is appreciated.
I've come to work with a strange database file format.
Each DB comes with two files: one is "database.db" and the other is "database.key".
The ".db" file always starts with a 0x78 0x9C binary header, while the ".key" always contains, in a random part of the file, the string "1.00 Peter's B Tree" inside.
Looking online I found that the header 0x78 0x9C could refer to compression Zlib, but have not found any way to view the contents of the database.
Does anyone here know something that could help me with this format ? Thnaks :)
Edit 1:
It appears that the ".db" file contains more than one zlib deflated streams:
The signature 0x78 0x9C is not only present at the beginning of the file but in different parts of it.
Fo example this are some of the streams i can find in one file:
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
By inflating thoose 2 streams i get 2 new uncompressed streams.
What i did then is a C# program that loaded a ".db" file and created a list of byte arrays; a byte array is a deflated stream.
To do this I simply split the file at every 78 9C.
This seems to work with some of the ".db" files but, in other situations it gave me some errors like "Invalid distance code", with this stream
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
or "Invalid stored block lenght", with this stream
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
Maybe simply splitting the file at each 78 9C is not the correct way of doing it ...
As for the ".key" files: I was able to open them using the library of Peter Graf "PBL".
With the "pblKfGetAbs ()" (http://www.mission-base.com/peter/source/pbl/doc/keyfile.html) I managed to get all records related to each key in the file. These records are of 4-byte values.
Searching for these values on a decompressed ".db" file (In a file that did not give me errors during the inflate process) with an hex editor I was able to get some results but nothing more. I don't understand wat thoose records on the key file means...
Thank you for the help !
Yes, those are very likely zlib streams stored in the database.
There is nothing keeping 78 9c from appearing in the compressed data, so simply searching for that is not a good way to extract the contents of the file. Also 78 9c is not the only valid zlib header. The easiest way to find the valid zlib streams is to simply start decompressing at every byte. zlib will very quickly rule out most as not having a valid zlib header. For the rest you can decompress until it completes or fails. If it completes with a good integrity check (returning Z_STREAM_END), then it is extremely likely that that was an intentional compressed zlib stream.
You are trying to reverse-engineer a data base format with what appears to be relatively little to go on. This is a detective job that stackoverflow can't help with, unless someone here knows the format and recognizes it.
These are zlib magic headers widely used by different utilities (such as Git, Memcached, etc).
To uncompress the file, you can use the following command:
printf "\x1f\x8b\x08\x00\x00\x00\x00\x00" | cat - zlib-file.dump | gunzip
To skip some bytes before, use dd, e.g.
cat <(printf "\x1f\x8b\x08\x00\x00\x00\x00\x00") <(dd skip=100 if=zlib-file.dump bs=1 of=/dev/stdout) | gunzip
If the data got crc/length error, consider as faulty.
the .db files are compressed data , the .key files are key_informations to find the wanted data in those .db (like an index file) after you open them,you may not find string data in those .db files,because they are a runtime databases, these .db files containt hex data like 'packets'and they are compressed as he said
78 9C is the zlib magic headers with Default Compression.
Try Aluigi's offzip commandline tool to extract the data.
I am currently investigating a disk image with a FAT12 file system for data recovery purposes/researching for file carving. For this investigation, I have the actual files that need to be carved/recovered from the disk image so that I can validate my results obtained from the carving process/recovery.
During the comparison and analysis from the recovered files, I noticed that after exactly 2 clusters (each of size 16384 bytes/32 sectors) of file data there are 4 extra/embedded bytes. These repetitive and distinct 4 bytes that are being noticed after 2 clusters are not found in the corresponding actual files. I think that these bytes are used somehow by the file system, is this right? What is their purposes and how can be identified during the recovery process?
Hex dump:
Actual File that needs to be recovered from disk (hex between 2 clusters):
Offset 0 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15
00016336 BC 55 B4 F8 A5 E1 69 82 2A DD 4A 5D DC 46 B9 80 ¼U´ø¥ái‚*ÝJ]ÜF¹€
00016352 E1 33 D3 F9 76 AE 8A 79 2E 22 0F 58 EE 67 FD AD á3Óùv®Šy." Xîgý
00016368 49 E9 7B 76 45 99 3E 25 69 36 F2 00 8B 71 70 C0 Ié{vE™>%i6ò ‹qpÀ
00016384 FC BB 6D 65 E9 DC F2 30 7E BD 6A B4 BF 17 52 0B ü»meéÜò0~½j´¿ R
00016400 64 9A 2D 13 58 B8 0E FB 13 65 9B 1E 87 93 F9 00 dš- X¸ û e› ‡“ù
00016416 7F 11 55 4F 21 AD A7 3A 51 D7 B9 CF 3C DE 35 25 UO!§:Q×¹Ï<Þ5%
Disk Image:
Offset 0 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15
00132880 BC 55 B4 F8 A5 E1 69 82 2A DD 4A 5D DC 46 B9 80 ¼U´ø¥ái‚*ÝJ]ÜF¹€
00132896 E1 33 D3 F9 76 AE 8A 79 2E 22 0F 58 EE 67 FD AD á3Óùv®Šy." Xîgý
00132912 49 E9 7B 76 45 99 3E 25 69 36 F2 00 8B 71 70 C0 Ié{vE™>%i6ò ‹qpÀ
00132928 **08 B5 A9 88** FC BB 6D 65 E9 DC F2 30 7E BD 6A B4 µ©ˆü»meéÜò0~½j´
00132944 BF 17 52 0B 64 9A 2D 13 58 B8 0E FB 13 65 9B 1E ¿ R dš- X¸ û e›
00132960 87 93 F9 00 7F 11 55 4F 21 AD A7 3A 51 D7 B9 CF ‡“ù UO!§:Q×¹Ï
00132976 3C DE 35 25 <Þ5%
From the above hex dump it can be visualized that 08 B5 A9 88 is exactly between the two clusters, however in the actual file those 4 bytes were eliminated.
The extra 4 bytes that were being encountered between the two clusters were CRCs that were embedded by the Encase disk image file format for security purposes. You can refer to the following link for more detail.
Is there any way to create a QR code from a byte array? I decoded one using "zxing", and now that I changed it, I want to turn it back. If there is a solution, please tell me. Here is the code churned from "zxing":
40 07 01 18 2b 3c ba 4c 0e 1d bd 8a b4 23 29 10
40 72 b0 fe 7f 12 7c 71 2f f2 2b 8e 2a 2b b9 88
21 93 94 83 c8 b2 57 d8 a1 5f 0f 70 c3 56 8f 88
81 16 70 1d b0 b8 dc 0d ce 4c 1e 7c 01 85 26 74
d3 ae ce 6b b0 4b 02 6a 45 50 11 1b 65 2c 5e e2
cc 4a 65 f2 04 94 27 84 6a 88 2c c1 92 8b 65 b3
4d a4 9a 07 4f 41 14 bd 6e b6 ab 02 ca cc 7b dd
fe 34 60 ec 11 ec 11 ec 11 ec
The array format and the spaces seem important. Now, here is the original QR Code I put into "zxing":
Thanks everyone!
---In Response to the On-Hold Message:---
I tried to convert the array to a QR Code, but it was much different from the original. I expected it to be the same.
There are different ways of encoding the same information for a QR code. One of several possible mask patterns is applied to the information in order to produce a QR code that has a well distributed pattern of black and white pixels. In a QR code on a piece of paper that is bent in some way, the apparent distances of the pixels may vary. Long series of white or black pixels could disturb the reading process. When reading a QR code, the edges between the white and black pixels are used to synchronize with the raster used.
In order to test if the printed QR code is correct, re-read it and compare the information with the information of the original QR code. Don't compare the pictures!
See QR code / Encoding on Wikipedia.