From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1754100AbdEHVSP (ORCPT ); Mon, 8 May 2017 17:18:15 -0400 Received: from esa5.dell-outbound.iphmx.com ([68.232.153.95]:26987 "EHLO esa5.dell-outbound.iphmx.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1750954AbdEHVSO (ORCPT ); Mon, 8 May 2017 17:18:14 -0400 From: X-LoopCount0: from 10.170.28.39 X-IronPort-AV: E=Sophos;i="5.38,311,1491282000"; d="scan'208";a="1106489450" To: CC: , , , , , , , , , Subject: RE: RFC: WMI Enhancements Thread-Topic: RFC: WMI Enhancements Thread-Index: AQHStXDRfWGz3Na/pUazu2XvXvLesqHF0EKAgASlkYCAABLTgIAA6aUAgAA5pYCAADDyAIAAOCOAgACXygCAADsZoIAAXFqA//+yhDCAAaJBgIAAfcEAgBdITWCABMfRAP//xH6AgAB5nYD//7BYMA== Date: Mon, 8 May 2017 21:18:11 +0000 Message-ID: <77e4e46f58354e10874ed0515f514fc2@ausx13mpc120.AMER.DELL.COM> References: <20170412230854.GA11963@fury> <201705081917.34242@pali> <201705082259.51850@pali> In-Reply-To: <201705082259.51850@pali> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [10.208.86.26] Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from base64 to 8bit by mail.home.local id v48LINLP006164 > -----Original Message----- > From: Pali Rohár [mailto:pali.rohar@gmail.com] > Sent: Monday, May 8, 2017 4:00 PM > To: Limonciello, Mario > Cc: dvhart@infradead.org; rjw@rjwysocki.net; luto@amacapital.net; > len.brown@intel.com; corentin.chary@gmail.com; luto@kernel.org; > andriy.shevchenko@linux.intel.com; linux-kernel@vger.kernel.org; platform- > driver-x86@vger.kernel.org; linux-pm@vger.kernel.org > Subject: Re: RFC: WMI Enhancements > > On Monday 08 May 2017 21:21:45 Mario.Limonciello@dell.com wrote: > > > -----Original Message----- > > > From: Pali Rohár [mailto:pali.rohar@gmail.com] > > > Sent: Monday, May 8, 2017 12:18 PM > > > To: Limonciello, Mario > > > Cc: dvhart@infradead.org; rjw@rjwysocki.net; luto@amacapital.net; > > > len.brown@intel.com; corentin.chary@gmail.com; luto@kernel.org; > > > andriy.shevchenko@linux.intel.com; linux-kernel@vger.kernel.org; > > > platform- driver-x86@vger.kernel.org; linux-pm@vger.kernel.org > > > Subject: Re: RFC: WMI Enhancements > > > > > > On Friday 05 May 2017 23:55:46 Mario.Limonciello@dell.com 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.