platomav/MCExtractor

1995 0x611 version 0xB..26 (reversed endian header, 2048, null padding)

Closed this issue · 8 comments

sladen commented

Revision 0x26 with reverse-endianness in prefix header. This could be May or September 1995:

$ hexdump -C 1995mmdd-0x611_v26.pdb | head -n2
00000000  00 00 00 01 00 0b 00 26  09 05 19 95 00 00 06 11
00000010  56 52 0b 61 00 00 00 00  00 00 00 00 00 00 00 00

$ sqlite3 -csv -header ../MCE.db 'select * from intel' | head -n2
cpuid,platform,version,yyyymmdd,size,checksum
00000611,00000000,00000B27,19961218,00000800,05793E46

This one is notable for having null padding after the active payload, instead of the usual "0x838BA96F"/"0x6FA98B83" trailing squence.

Kudos to:

platomav commented

I don't understand, what is the issue? There is no usual padding as it was AES encrypted before RSA in 2006 and onward.

sladen commented
  1. A 0x26 version (0x611 processor target) appears to exist. The numbering appears to be one lower than 0xb27, but with a spaced out '0xB' prefix (per. '0xA0001' and '0xC0004' also from 1995).
  2. This 0x26 version does not appear in the MCE database. Hence this report/heads-up.

Side-notes:

  1. Most of the Pentium-Pro microcodes have a common pseudo-random trailing sequence measuring c.0-1kB in length.
  2. in the 0x26 microcode version, the trailing sequence is all nulls (0x00000000 … ) verses the normal sequence (0x6FA98B83D339024F…)
  3. The trailing sequence (or the nulls in the case of 0x26) are ignored by the processor (@ddcc/Chen & Ahn, 2014) and appear solely for obfuscation purposes.
  4. Thus, locating the beginning of the trailing sequence (or nulls in the case of 0x26) gives an indication of the length of the active part.
platomav commented

This 0x26 version does not appear in the MCE database. Hence this report/heads-up.

Alright, thanks for the heads up. If it shows up at some point then MC Extractor will detect it as not in DB so we can add it. Since this is not a current issue of MCE I'll go ahead and close this issue, the discussion below remains unaffected.

The trailing sequence (or the nulls in the case of 0x26) are ignored by the processor (@ddcc/Chen & Ahn, 2014) and appear solely for obfuscation purposes.

Sure, although it seems kind of silly to have a static obfuscation padding when one needs only two microcodes and a hex editor to figure it out. It would make much more sense to randomize the padding before encrypting like they started doing in 2006 with RSA. Not that it matters anymore.

Thus, locating the beginning of the trailing sequence (or nulls in the case of 0x26) gives an indication of the length of the active part.

The payload size, yes. Intel added an offset for that in their 2006+ Undocumented Header.

sladen commented

The loader version is zero, so MCE require some adjustment to find it:

 # Intel - HeaderRev 01, LoaderRev 01, ProcesFlags xx00*3 (Intel 64 and IA-32 Architectures Software Developer's Manual Vol 3A, Ch 9.11.1)
-pat_icpu = re.compile(br'\x01\x00{3}.{4}[\x00-\x99](([\x19\x20][\x01-\x31][\x01-\x12])|(\x18\x07\x00)).{8}\x01\x00{3}.\x00{3}', re.DOTALL)
+pat_icpu = re.compile(br'\x01\x00{3}.{4}[\x00-\x99](([\x19\x20][\x01-\x31][\x01-\x12])|(\x18\x07\x00)).{8}[\x01\x00]\x00{3}.\x00{3}', re.DOTALL
sladen commented

Early hexdump had the wrong endianness; this was followed up, and the original has now been obtained (loader field set to zero, instead of one):

00000000  01 00 00 00 26 00 0b 00  95 19 05 09 11 06 00 00
00000010  61 0b 52 56 00 00 00 00  00 00 00 00 00 00 00 00
platomav commented

Ah so that early microcode has 00000001 instead of 01000000 at Loader Version, clearly a mistake from Intel. Yes I can add support for that I suppose as the Intel pattern is good enough to not produce false positives easily like the AMD one. Do you have the source file which includes that specific microcode to test this?

sladen commented

Yes, have a source file.

With a bit of date-typo correction things make more sense; originally the version contained the physical stepping, and the incremental microcode version; This then got compressed down to a single byte, to free up more bits for later use:

1995-09-05, 611, b0026   # Pentium Pro 150MHz,  B0
1995-10-20, 612, c0004   # Pentium Pro 150MHz,  C0
1995-10-20, 616, a0001   # Pentium Pro 200MHz, sA0

1996-01-05, 612, 000c5   # Pentium Pro 150MHz,  C0
1996-01-25, 616, 000c5   # Pentium Pro 200MHz, sA0
1996-01-25, 617, 000c5   # Pentium Pro 200MHz, sA1

Is there an update blob somewhere with 612/c0004 and 616/a0001?

platomav commented

Ok, I've added detection for Loader 0 as well as that revision 26 microcode. The updates to the script & DB will be pushed in the weekend and will close the issue then. As for these other microcodes, I don't keep records of where microcodes are found but it's almost always from random BIOS from OEMs. For these ancient things you can search for these .PDB files in google (like you're already doing), that's how I got most of them two years or so ago.