![]() Unpacking value.hex, starting at offset 0x10, and using TINFL_FLAG_PARSE_ZLIB_HEADER (as I am using miniz.c for eaze) gave me a correct unpacking result and a data file of 33,208 bytes long. Right after this header comes that familiar pair 78 9C again, so I brought out my zlib decoder wrapper. This lops off the first 16 bytes, hence my guess the 2nd dword is 'data length'. The third and fourth dwords may be flags of some kind and do not appear to point to data. In value.hex, the first dword appears to be a total file length the second dword the data length. This combined with the fact that I cannot directly change the values that I wish to extract from the proprietary files leaves me in a difficult position.ĭoes anybody know any tricks for trying to tease out time series data from binary data?Įdit This zip file contains 2 hex blobs (index and value) from the decompressed database and the same data as it is exported from the program. Most of the tables contain checksum fields, which I believe, are responsible for my inability to edit the blobs and see what changes in the proprietary software. The problem is that the software can export in a myriad of formats and I'm not sure which one (if any) the data would be stored in. So far I haven't been able to find any matches. I have tried finding known values in these blobs by exporting values from the proprietary software, converting to hex and searching for that value in the database file. These blobs account for 99% of the disk space of the overall database file.Īs far as I can tell, these blobs are not compressed data (by using unix 'file' command). A few of these tables contain fields that are stored as blobs of hex data. Each of these tables only have a few records, many of them don't have any records at all. This database file has a few dozen tables. I have a proprietary file format that is a compressed database file.
0 Comments
Leave a Reply. |