RE: RFC: WMI Enhancements

[Mario.Limonciello]

> -----Original Message-----
> From: Pali RohÃr [mailto:pali.rohar@xxxxxxxxx]
> Sent: Monday, May 8, 2017 4:00 PM
> To: Limonciello, Mario <Mario_Limonciello@xxxxxxxx>
> Cc: dvhart@xxxxxxxxxxxxx; rjw@xxxxxxxxxxxxx; luto@xxxxxxxxxxxxxx;
> len.brown@xxxxxxxxx; corentin.chary@xxxxxxxxx; luto@xxxxxxxxxx;
> andriy.shevchenko@xxxxxxxxxxxxxxx; linux-kernel@xxxxxxxxxxxxxxx; platform-
> driver-x86@xxxxxxxxxxxxxxx; linux-pm@xxxxxxxxxxxxxxx
> Subject: Re: RFC: WMI Enhancements
> 
> On Monday 08 May 2017 21:21:45 Mario.Limonciello@xxxxxxxx wrote:
> > > -----Original Message-----
> > > From: Pali RohÃr [mailto:pali.rohar@xxxxxxxxx]
> > > Sent: Monday, May 8, 2017 12:18 PM
> > > To: Limonciello, Mario <Mario_Limonciello@xxxxxxxx>
> > > Cc: dvhart@xxxxxxxxxxxxx; rjw@xxxxxxxxxxxxx; luto@xxxxxxxxxxxxxx;
> > > len.brown@xxxxxxxxx; corentin.chary@xxxxxxxxx; luto@xxxxxxxxxx;
> > > andriy.shevchenko@xxxxxxxxxxxxxxx; linux-kernel@xxxxxxxxxxxxxxx;
> > > platform- driver-x86@xxxxxxxxxxxxxxx; linux-pm@xxxxxxxxxxxxxxx
> > > Subject: Re: RFC: WMI Enhancements
> > >
> > > On Friday 05 May 2017 23:55:46 Mario.Limonciello@xxxxxxxx wrote:
> > > > Unfortunately the MOF data that comes out of wmi-mof is so called
> > > > "Binary MOF" which has been pre-compiled to an intermediate
> > > > format with mofcomp.exe on Windows. The format of binary MOF is
> > > > not documented and the only known way to get text mof back out
> > > > is by using mofcomp.exe with some esoteric arguments.
> > > >
> > > > mofcomp.exe -MOF:recovered.mof -MFL:ms_409.mof -Amendment:MS_409
> > > > binary_mof_file
> > >
> > > Looks like that binary MOF file has "well-known" file extension
> > > .bmf. File itself starts with magic hader "FOMB" which is in
> > > reverse BMOF (binary mof). But I was not able to find any
> > > specification nor any other details. As this binary format is
> > > dated back to Win9x I guess data would compressed by some old MS
> > > compression algorithm (CAB?).
> >
> > Actually comparing a couple of binary MOF files the first 8 look like
> > the header to me.
> >
> > 0x46, 0x4f, 0x4d, 0x42, 0x01, 0x00, 0x00, 0x00
> >
> > On a compiled Dell binary MOF the next are:
> >
> > 0xed, 0x04, 0x00, 0x00,
> >
> > This looks like the size of the remaining data after taking out 16
> > for the headers 4ed = 1261
> > Total size is 1277
> >
> > 0xd8, 0x15, 0x00, 0x00
> > Maybe a checksum?
> >
> > But that first 16 bytes does look like the header structure to me.
> 
> Good catch! Your observation for first 12 bytes passes also for my
> checks.
> 
> Next 4 bytes (after possible checksum) at 0x10 are always same:
> 0x44 0x53 0x00 0x01.
> 
> And I guess this should be compression header. In time of Win9x
> Microsoft had own non-standard compression for disks called DoubleSpace.
> IIRC it was some modification of LZ77 algorithm. And 0x44 0x53 0x00 0x01
> is DS01. Maybe it is really DoubleSpace compression used for binary MOF?
> 
> I'm going to find specification of that old compression algorithm...
> 
44 53 looks promising to be quantum compression.
https://en.wikipedia.org/wiki/Quantum_compression

Thatâs also what 'file' magic detects from it too.
$ file mof.stripped 
mof.stripped: Quantum archive data

> > > Moreover via tool wmiofck.exe it is possible to generate header
> > > file for
> > >
> > > WMI driver from binary mof file:
> > >   wmiofck.exe -hfile.h -m -u file.bmf
> > >
> > > And what is interesting that in this file are also comments which
> > > looks like comes from that binary mof file.
> >
> > Ah interesting.  The "comments" that come out of that are actually
> > what's mapped to the "Description" field in the WMI repository when
> > the binary MOF is loaded.
> >
> > They are not the developer comments that were placed in the original
> > MOF data.  I would suppose those are lost when compiling to binary
> > MOF.
> 
> Hm.. right they are present in decompiled MOF file in Description field.
> 
> > > When I looked into output from mofcomp.exe with above args, that
> > > MOF output did not contain comments, so looks like we still can
> > > miss something.
> > >
> > > See: http://blog.nietrzeba.pl/2011/12/mof-decompilation.html
> >
> > Actually I see wmimofck output to be missing some important bits.
> > For example on a Dell system You'll get a class BFn declared from
> > mofcomp output, but nothing from wmimofck output.
> >
> > The most important thing that you're really getting out of this MOF
> > is the size, structure and format of the buffer that you would be
> > sending to ASL.
> >
> > Back to the point we were discussing of a potential filter, the
> > information in the MOF could possibly be very useful to declaring
> > what is going into the filter.
> 
> In that header file generated by wmiofck.exe I see definitions for BFn.
There is a definition but it's missing the format of the argument from
what I can tell.

In any case, this will be tangential to this discussion, but useful for
reverse engineering the binary mof format.