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... > > 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. And there are also sizes for BFn buffers, together with some types. -- Pali Rohár pali.rohar@xxxxxxxxx
Attachment:
signature.asc
Description: This is a digitally signed message part.
