I need to identify a binary file by examining the raw contents

Question

I have encountered this file - and know this much about it's structure...

512-byte header (which contains a 'counter' of field definition records.)

768-byte field definition records - multiple instances. Apparently one for each field in the subsequent data records.

Data - in FIXED-LENGTH records (the data-record length is also in the header.)

I have examined several files from this same source - and the first few bytes of each file are different - one from another.

There is a string of HEX characters that are the same in the examples I have - but these hex characters do not represent a readable string: Š¾ŽY#dË@=qÒã¼dÐ

There are NO human-readable strings in the header.

Anyone have any ideas what kind of file I have here?

EDIT Last evening, I was able to get to the source machine - and noted that - for this one file, at least, there were three other files with the same base name - with extensions: .blb, .blk and .idx.

I do not yet have copies of these additional files ...

Does this help - anyone have any idea what kind of 'database' this goes to?

Answer 1

On a GNU/Linux system, I would give a try with the file command that uses underneath the libmagic to identify a bunch of file types.

On windows, you can try the win32 port of file from the GnuWin project (its diagnostic will be equal to the Linux version as it is the same library).

I just remember the good old days when we tried to get resources from games binary files: perhaps that a resource ripper could have some results, if the binary file holds some known file types concatenated inside of it.

On the other hand, if the data was compressed it is far more difficult to identify the compression method (appart the well known PK zip header). In this case, you can find something by trying the windows version of the 7zip archive manager (once installed, try a right click / open archive). It has some surprising results (e.g. it can even show the content of some installer files)

Answer 2

DBISAM!!

When we finally got to the ACTUAL server, we found the DB engine running - and it had clear declarations as to what kind of database was in use.