I am examining a Windows application that uses a database of unknown type. The database consists of several files with file extensions, .i, .iz, .b1, .p and .bi. Is there an API that can be used to view the design, tables and contents of this database? The ambition is to migrate the data to a MySQL environment.
Use a hex editor and see db inside in binary mode. You may get the chance to see the file type in the few starting bytes. Then change the extension appropriately and open it.
Perhaps the Unix file utility (available in Cygwin) can identify them.
From FileExt.com:
File Extension BI
File type: Binary File
Primary association: Binary File
Other applications associated with file type BI:
Progress (Database Before Image File) by Progress Software Corporation
Quick Basic or Visual Basic for DOS (Include File) by Microsoft Corporation Similar to C's .H but is used only in Microsoft's DOS BASIC dialects. Stands for "Basic Include". This association is classified as Text.
Anyway...
Chances are that it's not a relational database system that this program uses; most ad-hoc, single-use databases developed for use in one program are what are called "flat-file databases", which means that "records" have a set size and are accessed through a method of seek-ing through it as you would a normal file. For instance, if you set the record size to 20, then the first record would be at the byte range 0-19, the second would be at 20-39, etc.
If you could somehow derive what the record size this particular program uses, you could split the file into the component records as binary data. Decoding that data into meaningful information would probably be a hassle, though.
Related
I'm working with a scriptable CAD/CAM system that runs on Windows 10 whose built-in code pane is not very useful. The user-defined scripting code for this CAD/CAM system is not saved in text files, but rather, in a field in an SQL Server. I'm thinking there might be some way of setting up Visual Studio/VSCode (or maybe Notepad++) to work with the code in the database the same way it would do if were in a text file. I could probably set up some sort of .Net FileSystemWatcher utility that keeps a bunch of code files it sees in a directory synched with code in the SQL Server data field. But I have deadlines, and I'm supposed to be scripting this CAD/CAM system--not building tools to script the CAD/CAM system. Any ideas for a "quick fix"?
So I know that a file is composed by it's data and also metadata, which is information about it (usually the name, the type of the file, dates of creation and modification, etc.).
My question is where exactly is that information stored. I know it can be included inside the file, the directory or in a database, but for the Windows, Linux and MAC-OS file systems I can't seem to find this information...
Most of this information in the case of Windows and Mac is proprietary.
For Windows I can say for certain that a close enough version of the NTFS file system driver has been written for Linux. You can look into that, there's also some documentation most of it written by Richard 'Flatcap' Russon (http://www.flatcap.org/ntfs/).
Documentation on the FAT Filesystem has been made public a long time ago with the intent that it would provide ample information for developers and engineers working on flash drives and things like that. (http://msdn.microsoft.com/en-us/library/windows/hardware/gg463080.aspx)
Documentation on the Ext Filesystem used by Linux distributions can be found on the web easily. (Ext2 : http://www.nongnu.org/ext2-doc/ext2.html)
I have no clue what Mac uses but I bet it's some kind of proprietary abomination derived from an existing format (probably ext). This is just my opinion, do not take this as fact.
All these formats have some sort of structure that holds meta-data. The file is just a stream of bytes somewhere on the physical drive. Most filesystems should have a structure that stores at least the file's location (usually a starting cluster for each fragment of the file) and the file's size. The rest of meta-data is up to each file system to implement.
For example, the FAT Filesystem there are tables for each directory and each directory stores metadata about the files it contains. But it also has a FAT table that holds the fragment locations for each file contained in the filesystem.
The NTFS Filesystem has a big table called the Master File Table that holds a record of metadata for each file contained by the filesystem including the table itself. Each record holds all the metadata including the file location on the physical drive for each fragment.
However, the directory structure is held as data in directory file records. However, the NTFS has even more structures that hold information about the files such as the USN Journal or the Volume Bitmap.
To access the meta-data contained by the file system you either have to parse the raw volume or to use functions exposed by the operating system's API. The API doesn't generally give you all the information you want about the metadata. For example, Windows API will give you functions to iterate through the USN Journal to find information about a particular file, but you can't get the MFT attributes of a file directly.
Again, I have to stress out that even with most of the documentation on these proprietary file systems, you're taking shots in the dark since it's their intellectual property. Some if not most of the documentation that we have now comes from reverse engineering.
It depends on the filesystem. Take a look at http://lxr.free-electrons.com/source/fs/fat/fat.h for instance.
systems#Metadata show details on which file systems store information in metadata.
I have a legacy system which used to run on dos. It is an ERP system for retail stores (fashion). It think it stores it's data in flat files.
I have files ending with *.KEY and other files ending with *.D00 (counting up).
I think the key files hold the key informationen and the D-Files hold some data ... there are alot D77 files...
As far as my investigation concerns this is not dfb or foxpro it could proprietary...
The company who wrote it is out of business of course so no chance for support or any hints.
When I open these files in vim or other editors I get some binary signs and some text... I tryed it in hex mode but still nothing to use...
Is there any chance I can dump out the data... in csv, ascii, xml?
I am pretty sure that this is not a standard format. Can someone point me in a direction how those data were stored back in the days and how could I make them read-able...
Any tools, tips or tricks?
// EDIT
After some time I made some progress and can now post some details which I did not now of back then and made a good answer impossible.
I asume that the dos system was written in visual cobol and that the files could be b-tree files stored in ISAM format. I assume the closet thing I could provide is, that there is a possibility that the format is C-ISAM.
How can I access / view or modify these files... C#, JAVA, ruby.... everything new age language would be cool... I am not sure if I can handle cobol... It would be great to have a converter or a viewer tool preferable opensource...
Hope this clearifies more my question =)
OpenCOBOL has a very active user group. The language itself is free and runs on Linux and Windows and perhaps MacOSX. Have a chat to the user group there; they may be able to help.
Peachtree Accounting Software used those file extensions back in 1992.
I have a database file with .DB file extension. I have been googling and it looks like SQLite. I tried to connect to it using SQLite and SQLite3 drivers and I am getting an error "File is encrypted or not a database".
So I dont know if file is encrypted or it is not an SQLite database. Are there any other options what should the .DB extension should be? How do I find out that file is encrypted?
I tried to open it in the text editor and it is mostly a mess of charaters and some times there are words visible. I have uploaded the file here: http://cl.ly/3k0E01373r3v182a3p1o for the closer look.
Thank you for your hints and ideas what to do and how to work with this file.
Marco Pontello's TrID is a great way to determine the type of any file.
TrID is simple to use. Just run TrID and point it to the file to be analyzed. The file will be read and compared with the definitions in the database. Results are presented in order of highest probability.
Just download the executable and the latest definitions file into the same directory and then run TrID:
trid.exe "path/to/file.xyz"
It will output a list of possible file types for the file with a confidence rating. Here's a screenshot of using TrID to analyze a SQLite database file:
There's also a GUI version called TrIDNet:
If you're on a Unix-like platform (Mac OS X, Linux, etc), you could try running file myfile.db to see if that can figure out what type of file it is. The file utility will inspect the beginning of the file, looking for any clues like magic numbers, headers, and so on to determine the type of the file.
Look at the first 30 bytes of the file (open it in Notepad, Notepad++ or another simple text viewer). There's usually some kind of tag or extension name in there.
Both SQLite 2 and SQLite 3 have a very clear message: SQLite format 3 for SQLite 3 (obviously) and This file contains an SQLite 2.1 database for SQLite 2.
Note that encrypted SQLite databases don't have a header like that since the entire file is encrypted. See siyw's comment below.
On a Unix-like system (or Cygwin under Windows), the strings utility will search a file for strings, and print them to stdout. Might help you narrow the field.
There are a lot of programs besides database programs that use a "db" extension, including
ArcView Object Database File (ESRI)
MultiEdit
Netscape
Palm
and so on. Google "file extensions" for some sites that catalog file extensions and the programs that use them.
There's no conclusive way to know, because SQLite encrypts the entire database file, including the header.
Further, there's not a lot of difference to you, except for possible error text to a user if you're prompting them for a password.
I've an application, that uses encrypted (txt) files to store data. After investigating the decompiled assembly I concluded that it's a file of some DBMS. So how can find out which DBMS is this application using to store it's data, so that I can attach that file to the correct DBMS.
This is little application and there is no license problem. I can just ask the owner to gimme the data, but just curious to solve this myself.
MORE INFO:
Platform is Windows, and after trying couple of decompilers I concluded that it WAS written in Visual C++. However I couldn't fully decompile this exe, otherwise I just could find out it from the source code.
A couple ideas.
If opening the file in a HEX editor doesn't give you any information (like a magic identifier at the start of the file, which you can pop into google, then:
Use the depends tool from microsoft to grab a list of the DLLs being loaded by the application. Chances are whatever DBMS it's using is contained in an external library.
If the first two suggestions yield nothing, load the executable into IDA pro freeware and have a look at the code which is creating these files.