3

I am attempting to discover the exact format/encoding of a file. These files stem from closed-source analysis software we use on a daily basis. I would like to obtain the format in order to create an open source viewer for these kind of files and analysis. I am by no means a deciphering expert but I've did some research concerning the file. Currently I am not sure however to pursue any further, so I would be very grateful for any help.

I've ran several tools in order to profile the file. The extension of the file is .SMP.

1. TrID
TrID is an utility designed to identify file types from their binary signatures.
enter image description here

I was positively surprised when I saw this result because it suggested that it would be a known file format. However, when using the described tools (e.g. packARC and packPNM) it appears that these cannot be read by that format. Terminal below:

C:\Users\wptmdoorn\Documents\programming\sysmexviewer\data>packarc x f1.smp

--> packARC Frontend v0.7RC17 (11/21/2014) by Matthias Stirner / Se <--
--> packARC library v0.7RC17 (11/21/2014) by Matthias Stirner / Se <--
--> contains: packJPG v2.5j, packMP3 v1.0f, packPNM v1.6c, packARI v0.6e <--
Copyright 2006-2014 HTW Aalen University & Matthias Stirner
All rights reserved

*could not open archive "f1.smp" (file is not a PJA archive)!*

2. Binvis and Binwalk
Binwalk does not return any meaningful information (in this case I used -e to extract potential files if there are).

C:\Users\wptmdoorn\Documents\programming\sysmexviewer\data>binwalk --signature f1.smp -e

DECIMAL       HEXADECIMAL     DESCRIPTION
--------------------------------------------------------------------------------

Binvis.io does return some patterns however.

Scan (left) and cluster (right)
enter image description hereenter image description here

Entropy; scan (left) and cluster (right)
enter image description hereenter image description here

3. Hex editor
At last I tried to look at the files in a hex editor. Underlying figures show the file opened at the beginning and somewhere in the middle.

enter image description here enter image description here

Conclusion
My gut feelings says that it's some kind of archive of several files with some kind of header, although I am not completely sure. Nonetheless I would be very grateful if anybody would be able to look at these preliminary results and give some hints on routes I should consider :-)

Thanks a lot in advance. Best, William

1 Answer 1

5

This is only a partial answer but the data at offset 0x100 looks very much like that produced by Microsoft's C++ MFC serialization.

Specifically, the FFFF is a 'new class tag' followed by -

  • 0001 a schema version
  • 0011 length of class name
  • 'CSampleBackupFile' class name (using naming convention consistent with MFC's)

Decent information on MFC Serialization is pretty scarce but there is a good write-up here.

2
  • That's a very nice finding, thank you. It's indeed a pretty high chance that this originates from MFC serialization. You don't have to answer, but any advice on deserializing a MFC file from whose original class structure/format I do not have access to? If you read and think about it, it seems almost impossible to do. At this point I might even try to disassembly the original software to see if I can find some of these classes there.
    – wptmdoorn
    Jan 2 at 10:04
  • It's been years since I really looked at anything MFC based, but if you know what info you expect the file to contain it will help considerably; especially if you can create files and control what's in them using the device itself. If you try to look at the original software, I'd expect it to contain MFC Runtime Class Information. This should help identify where in the code to look. You'll be even luckier if MSVC C++ RTTI is enabled too.
    – Ian Cook
    Jan 2 at 22:55

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.