Read the Note of the latest commit.
Read the Note of thelatest commit[/URL].
Thank you!
@plutomaniac might probably be a false positive but the antivirus is telling me the latest MCE.exe has the "occamy.c" trojan
this is only for the 1.37 version as the 1.36 seems "clean" according to windows antivirus.
Obviously a false positive, usually of PyInstaller. You can always install python and use the script by itself or build an executable yourself.
Not sure what you are saying exactly.
cpu906EC_plat22_ver000000A02018-09-17_PRD_8CDAD79E.bin
cpu906ECplat22_ver000000A2_2018-09-29_PRD_FCAF004B.bin
These microcodes are interchangeable.
There are no Intel pre-production microcodes in the GitHub repository.
I have added the 306F0 microcode to this thread, which includes ES/QS microcodes.
I’ve found these mCodes in Lenovo T480s latest BIOS
!New_cpu406E3_platC0_ver000000DC_2020-04-27_PRD_459D4483.bin
!New_cpu806E9_platC0_ver000000D6_2020-04-27_PRD_C979B5EA.bin
!New_cpu806EA_platC0_ver000000D6_2020-04-27_PRD_D9DD064F.bin
Updated:
I used outdated MC Extractor 1.38. Those codes were added into 1.43 release.
20200722_Intel.zip (305 KB)
Now MCE can count the number of found mCodes. But I understand that he only counts those mCodes that he knows?
If so, can you add another option?
First, we look for and calculate the mCodes that we know.
Then we search and calculate everything only by the general search string
Then we look for and count everything, only by 'pat_acpu’
Compare the results of both searches.
If the results match, then nothing new.
If ‘pat_acpu’ counter is greater than the known counter, then something has been found and can be analyzed.
If believe AMD’s statements, then until the end there will be new 4xxx models, and next year 5xxx models for laptops. And it is difficult to say what the CPUID will be.
Edit/Added:
No calc/count. Example
1
2
3
4
2
3
4
while (found (pat_acpu))
if (check (cpu_id) == false)
printf ("Found Unknown %X %X\n", CPUID, Offset)
MCE counts all the microcode patterns detected by pat_icpu + pat_acpu + pat_vcpu + pat_fcpu. There is one pattern for each vendor which should detect all their microcodes and prevent false positives as much as possible. In this case, there is no need to have an extra less strict AMD pattern because it would give false positives and whatever MC count comes from there will be inaccurate.
Unless absolutely necessary (i.e. vendor changed Header structure completely, never happened so far) there should only be 1 pattern per vendor because regex searches are generally very complicated/slow. Optimizations can be made (and are made in MCE) to make them faster but the rule of thumb is to keep them as infrequent as possible.
Regarding CPUID, MCE does not rely on that for the regex patterns. Since AMD, in their infinite wisdom, do not have a microcode size in the header (even though half of it is "reserved"), MCE needs to keep a hardcoded list of generations and their static (unique to AMD) microcode sizes. This is done via the CPUID but only after the microcode has been detected/allowed by the regex pattern:
If a new microcode CPUID is found and MCE does not know its static size yet, an error is shown but the microcode is shown/accepted:
So the problem is not with CPUID. It is a matter of balancing how strict, fast and future-proof the regex pattern is:
The issue with Zen 3 was that the Loader ID value range was set to 0-4 but Zen 3 started using 5 so it needed to be increased first to detect a valid microcode before dealing with the Size (CPUID). Honestly, any vendor can change many things in the header which will break the regex searches (reserved fields, revisions etc) but for AMD, I increased Loader ID to 6 now (should cover the next generation) to be on the safe side and hopefully without extra false positives.
Just came here to post this, was trying to download MC Extractor v1.48.1 r159 and Windows Defender reported a trojan, had a small scare thinking the MC Extractor github was compromised, edge removed it as soon as it was downloaded. Did not happen with R157. Maybe a new version needs to be pushed to remediate this issue?
UPDATE: For some reason, windows is calling r157 as a PUP (Potentially Unwanted Program), still much nicer than to call it a trojan and immediately blocking it, lol
Guys, please read the README over at Github. There a specific section just for false positives. I’ll probably have to include that note at each release from now on unfortunately.
@plutomaniac
Starting from v1.52.0 r168 MC Extractor now works with Python installed.
Everything is correct.
@ plutomaniac
Found funny readings in a Z97 bios Lost_N_BIOS is working with- fragments of AMD mcs in NVRAM in a HSW/BDW bios (Z97)- NVRAM entries are named 'MrcS3resume’
MCE output:
Are these fake recognitions or how could that have happened?
Attached zipped NVRAM, complete dummp can be found here: ASUS Maximus VII Gene BIOS missing ME Version (3)
False positives. Must be ignored. The AMD detection pattern is already as strong as it can be considering AMD’s idiocy when it comes to firmware development.
Hi, All.
I can’t find any newer microcode for:
# │ CPUID │ Platform ID │ Revision │ Date │ Type │ Size │ Offset │ Last
3 │ 106A4 │ 02 (1) │ A │ 2008-09-19 │ PRD │ 0x2400 │ 0x93820 │ No
Anyone can help me with it?
Latest for Bloomfield 106A4 is cpu106A4_plat03_ver00000013_2015-06-30_PRD_35DDB232.bin.
You can download it from Platomav’s Github page here.
So it seems i can remove it from my BIOS completly:
cpu106A4_plat02_ver0000000A_2008-09-19_PRD_6D0F43C1.bin
Hello
I no longer know where I found the MCE.exe file to use with UBU
Can someone help me
Thanks
Hello
There is no longer the MCE.exe file in the archive ?
Thanks