No announcement yet.

Hex String Viewer

  • Filter
  • Time
  • Show
Clear All
new posts

  • Hex String Viewer

    Just wanted to compliment you on OSForensic's ability to extract text strings from files.

    I have a 54 gigabyte IBM Informix database file (file extension FC7) which I needed to determine the version of Informix used as well as the type of server system used (Unix).

    I was able to open the 54 GB FC7 file using OSForensics, extract all text strings and then search for the required information successfully.

    Also, I just learned in my Cellebrite Advanced Smartphone Analysis certification training about carving of data from BLOB files residing within SQLite database files.

    I was able to use Cellebrite Physical Analyzer to extract out the BLOB files from SQLite database tables, and then use OSForensics to extract out text strings from the BLOB files.

    Some text messaging applications will store SMS messages, internet browsing history and location based data within BLOB files that are stored within cells of SQLite database files, so being able to carve such content out is critical.

    In future releases of OSF it would be helpful if the indexing function could create searchable indexes of SQLite database files as well as BLOB files.

    Love the tool - many thanks for your hard work.

  • #2
    Back in V5.1 we put a lot of effort into improving the string extraction and subsequent filtering in the Internal Viewer. So it is much faster than it was. We tested it with some pretty large files (e.g. 16GB memory dumps), but never something 54GB big. So good to hear it worked OK.

    You probably could have just done the string extraction directly on the SQLite DB file in OSF (without the preliminary extraction of the blob).

    You can do Blob extraction in OSF, from the SQLite DB browser. Just right click on the blob cell and save it (or view it directly). So you don't need Cellebrite for this task.

    For searching a single file, using the Internal Viewer (with string extraction) is usually the best option. If you have lots of binary files however and need to search them for multiple different search terms, then creating an index is a better option. The indexer does in fact already do string extraction from binary files, but it only does it on selected file types. I'll need to check what it does for SQLite files (which can be hard to identify, as they often have no file extension).


    • #3
      And after some experimentation, a quick update:

      Note: #1
      The behaviour in release V5.2.1001 is that the indexer treats SQLite files as text files. Which means most of the content doesn't get fully indexed, as there is a lot of binary fluff in these files. We are going to chance this behaviour in release V5.2.1002 so that the indexer assumes they are binary files and performs a string extraction on SQLite files. This will take a bit more time during the indexing process, but will pick up a lot more text from these files.

      Note: #2
      While testing I found another minor bug. It seems the newest SQLite version has broken the blob extraction process in the SQLite viewer. Looks like they have done away with the Row ID values. So we'll make some changes to fix this up as well in release V5.2.1002

      Release V5.2.1002 will be done before the end of the week (3/Nov/17)


      • #4
        Release V5.2.1002 is now available & should address the above issues.