Running file on the binary file simply reports that it contains "data".Īn example of the hexadecimal contents ( xxd dump) corresponding very nearly to the contents above and aligned to show the progression of '0x40' = that I mentioned previously is shown below. If they are compressed, then the compression would be restricted to the data table itself since I can find plain text elsewhere in the binary file by running strings on it.
Bin file extractor how to#
I do not know whether the data are compressed and if so how to determine the method of compression.They do not appear to be encoded in various float or integer representations, nor as ASCII characters. I do not know how the human-readable numbers are encoded.I do not know the "phase" of the 16 bytes of data (i.e., where one 16 byte segment ends and the next begins).Indeed, I can account for most of the header: 15 bytes containing a data descriptor in plain text, 16 bytes of zeros which appears to serve as an offset, and one byte ('0x46' = 70 in decimal) which appears to encode the number of lines in the table. The complete data table is 1156 bytes, so I further assume the unexplained 36 bytes contain header information. Thus, the total size of the binary data table would be 16*70 = 1120 bytes. Based on the 16-byte periodicity of this motif, I assume each row in the human-readable table is represented in the binary file by 16 consecutive bytes. One challenge is that although there is a monotonic progression in the ASCII value of the byte preceding the ('0x40'), it does not always increase (i.e., there are stationary points, sometimes followed by a jump that skips over one of the ASCII characters for instance. This "motif" occurs every 16 bytes and there are 70 occurrences. There is a repeating pattern of characters ascending the ASCII table followed by signs (e.g., = '0x3440', = '0x3540', ='3640', etc.). The corresponding data section comprises 2312 hexadecimal digits, or 1156 bytes. I have 70 such lines, each containing two numbers of the precision shown in the table. The human-readable data are as follows: 20.0,0.001 Perhaps the section containing the data has been compressed by some algorithm, or perhaps the numbers are stored in a representation with which I am unfamiliar. The data do not appear to be stored as float16, float32, float64, signed/unsigned int of various length, or char, based on analysis of the hexdump. However, I am unable to determine in what manner the data are encoded.
I have a binary file and a text file of the corresponding data, and I know the location in the binary file where the data are contained.
0 kommentar(er)
