Google Answers Logo
View Question
 
Q: Deserializing MFC serialized classes without class definitions ( Answered,   0 Comments )
Question  
Subject: Deserializing MFC serialized classes without class definitions
Category: Computers > Programming
Asked by: carbon-ga
List Price: $8.00
Posted: 08 Oct 2003 12:26 PDT
Expires: 07 Nov 2003 11:26 PST
Question ID: 264286
Some data I want is in MFC serialized format, which has a header that
looks like a 16-bit class count, 'new class' tag 0xffff, a 16-bit
class version, a 16-bit string length, and the name of the class
(usually something like CClassName). If this seems familiar, we are
probably talking about the same thing.

Is it practical to try to get this data out when I don't have access
to the class definitions? I basically want to write some program using
MSVC to deserialize this data so that I can convert it to CSV or
something else simple. Past attempts to extract this data without
using any MS deserialization functions have proven futile; if you
misinterpret the meaning of some byte, you are jumping to some random
location in the file, and the results are horrible. In case I'm not
clear, fields in this format often look like <length byte><field
data>. If you misinterpret the meaning of some byte (which is very
easy to do, as the meanings of all the fields are not known) and jump
forward the wrong amount, disaster.
Answer  
Subject: Re: Deserializing MFC serialized classes without class definitions
Answered By: efn-ga on 10 Oct 2003 23:33 PDT
 
Hi carbon-ga,

No, it is not practical to decode a file like this without detailed
knowledge of the software that wrote the file.

Even if you knew the types of the data elements involved, that would
not necessarily be sufficient, because the representation of the data
in the file is largely under the control of the application software. 
The application can have MFC write some information about the class in
the file, as you described in your question, but that information is
not sufficient to decode all the data.

MFC provides some functions for serializing primitive data types and
MFC objects, but this doesn't help for two reasons.  First, the
representation of the data in the file is not self-defining.  A
sequence of four bytes could represent four BYTE members or two WORD
members or one LONG or DWORD member and there is no way to tell from
the information in the file alone which of these interpretations is
appropriate.

The second reason the standard functions don't help is that an
application does not have to use those functions anyway.  When one is
writing the software to serialize an object, the main requirement is
that it be able to read what it has written and reconstruct an object.
 MFC does not impose any requirements on how the data is represented
in the file.  If a programmer writes the software to put out a
floating-point number in character representation, for example, that
will be perfectly fine with MFC.

So the problem of decoding a file written with MFC serialization is
much the same as the problem of decoding any file of unknown format. 
If you have some information about what may or should be in a file and
you study the data, you may be able to crack the code, but it is not
practical to do it automatically.


Additional Links:

Microsoft Developer Network pages on serialization
http://msdn.microsoft.com/library/default.asp?url=/library/en-us/vccore/html/_core_Serialization_Topics.asp


Search Strategy:

I consulted two books:

MFC Programming by Alan R. Feuer.  Addison-Wesley (1997)

Inside Visual C++ by David J. Kruglinski.  Microsoft Press (4th ed.,
1997)

I also referred to the help files of Microsoft Visual C++ 6.0, and I
wrote a test program and looked at its output.  I relied primarily on
these off-line information sources, not Internet sources.


I hope this information is helpful.  If anything in this answer is too
obscure, please ask for a clarification.

--efn-ga
Comments  
There are no comments at this time.

Important Disclaimer: Answers and comments provided on Google Answers are general information, and are not intended to substitute for informed professional medical, psychiatric, psychological, tax, legal, investment, accounting, or other professional advice. Google does not endorse, and expressly disclaims liability for any product, manufacturer, distributor, service or service provider mentioned or any opinion expressed in answers or comments. Please read carefully the Google Answers Terms of Service.

If you feel that you have found inappropriate content, please let us know by emailing us at answers-support@google.com with the question ID listed above. Thank you.
Search Google Answers for
Google Answers  


Google Home - Answers FAQ - Terms of Service - Privacy Policy