> -----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. > > 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. > > 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.
