ASUS Laptop N550JK-CN090H - Clean-Dumped ME Region Does not Work

Special Topics Intel Management Engine
1

Hello,

My laptop is ASUS N550JK-CN090H, 8 series Haswell.

I believe there’s something wrong with my Intel MEI, (when booting, it waits on a black screen for 17-18 seconds before showing asus logo and loading bios, meinfo and memanuf gives errors - see below spoiler)



So I’ve decided to reflash my ME region.

Note: ASUS does not provide full spi images, only BIOS region update files which contain 6 MB bios region images.
(My bios chip is a 8MB winbond 25q64fv)

First, I’ve dumped by full spi image via CH341A + Test Clip, and unlocked FD.
(I unscrew the mainboard from the laptop, clamp with clip and connect the ch341a programmer to my friend’s laptop. Then, I use flashrom to read/write with the programmer on Ubuntu.)
(Not sure if I’m supposed to take off the CMOS battery of Bios while reflashing. I’ve always taken it off before r/w bios chip except that I once forgot and reflashed the chip but nothing wrong happened.)

Then, by following the awesome guide [Guide] Clean Dumped Intel Engine (CS)ME/(CS)TXE Regions with Data Initialization by @plutomaniac

ME on my dumped image shows 9.0.30.1482, 1.5MB on MEA

So, I’ve used Intel ME System Tools 9.1 r5

I’ve used FIT and the exact same ME firmware “9.0.30.1482_1.5MB_PRD_RGN” as my dumped image.
Attached: before.zip and after.zip includes before.bin + before.xml and after.bin + after.xml
before.bin is my full spi image dumped after the initial FD unlock.
after.bin is the outimage.bin I obtained by following the guide.
after.xml is the xml file generated when I drag&drop outimage to FIT.
before.xml is the xml file generated when I redrag&drop before.bin to FIT to compare with the after.xml


Then, I tried to flash the after.bin with FPT on DOS
fpt.exe -f after.bin
Resulted in Error Failed to disable write protection for bios space
So, I used
fpt.exe -me -f after.bin
fpt.exe -desc -f after.bin
(Was that wrong? I was not sure if fpt would try to flash the whole .bin into the given region or would select the given region from the whole .bin and flash only that region. But I tried anyways, since I have a programmer for just in case.)
fpt.exe -greset
Then, the laptop shuts off very fast.

That resulted in my laptop not booting up.
When I press the power button, the power button’s light turns on for ~1 seconds and then turns back off.

Then, I’ve tried to flash after.bin with CH341A programmer and flashrom on Ubuntu
flashrom --programmer CH341A_spi -w after.bin
It did flash correctly and verified.


That did not change the fact that my laptop does not boot.
However, after reflashing the first boot try takes ~3 seconds
(Not sure but the first boot after fpt flash may have taken ~3 seconds also.)
while the rest takes ~1 seconds just as the previous situation.

So, I’ve though that there must be something wrong with the after.bin maybe?
Thus, reflashed before.bin via CH341A using the above steps.
That led me to be able to boot my laptop.
I’ve entered DOS and ran “fpt.exe -greset” (I didn’t know if I should, but I did it anyways)
(Should I do the fpt -greset even after programming with CH341a programmer?)

Anyways, now, I’m back to my inital state. I still believe that there’s a corruption in my ME since MeInfo and MeManuf gives errors.

To sum up:
Successfully flashed “Clean Dumped ME Region” but failed to boot so had to reflash my old dump

What may have gone wrong? Can someone help me if I’ve created the after.bin from before.bin correctly?

after.zip (3.21 MB)

before.zip (3.3 MB)

2

First of all, amazing work so far. You’ve clearly done your “homework”/research and looked into everything. You knew that you had to clean the ME firmware, that ASUS only includes the BIOS region of the SPI, picked the correct tools & firmware, followed the instructions to the letter, attached before/after files, explained your process and what each file is, kept a verified backup via a programmer, understood that you had to use manually fpt -me and -desc when the BIOS locks are engaged, properly used -greset and successfully restored to the previous state while waiting for some help. Just superb. Such users are very rare, thank you for that and I’ll try to help as much as possible.

I used your before SPI and re-built my own outimage via the guide. You did everything correctly. My result has a tiny difference at the ME settings region but I’m not sure how that came to be since our “after” xml are identical. Just to cover all basis, I have attached my own results but I don’t think that your after.bin is any different in actual terms.

Now, to answer some questions. Yes, you must always run “-greset”, even after using an external programmer. The goal is to force the ME to reset its state and recognize that new firmware has been applied. After using a programmer, you’d have to start the system to run “-greset” so you can do it manually instead by removing all AC + Battery power (RTC not needed) for 1 minute while pressing the power button 2-3 times in between.

I’m not sure if FPT is clever enough to parse the SPI FD and pick the Descriptor (-desc) or ME (-me) region automatically when you input a full SPI. Maybe it does since it usually troughs an error when the user tries to flash something of different size to a region. No matter what, I always extract only the Descriptor and ME region and flash them by themselves. I suggest you do the same as that may have been the reason for the brick. However, since you have a programmer, why not use that? You don’t have to mess with FPT. You can take your after.bin or my outimage.bin and flash it back directly via the programmer. Verify the contents, do a manual “-greset” as mentioned above and you’re good to go.

In some rare cases, after reflashing the system may behave in weird ways (opening but staying a back screen, not opening etc). In such case, after making sure that you did a manual “-greset”, try removing the RAM and placing it back or switching their slots, or leaving just one. A lot of times these post-flash issues may be from the BIOS dump being confused with the current state of things (bad cache) so from experience I’ve noticed that the RAM tricks works great.

outimage.rar (3.11 MB)

3

Hello,
Thanks for your fast and kind reply as well as telling me that I did my homework (it really motivated me :P)
So, I’ve checked the files with a hex file editor and saw that our after files are almost identical as you said.
Anyways, I’ve extracted me.bin and desc.bin from your outimage.bin using UEFITool.
Then, on DOS, I’ve flashed the files with
fpt.exe -desc -f desc.bin
fpt.exe -me -f me.bin
fpt.exe -greset

Just as before the result was: The initial boot try takes ~4 seconds and after that each try takes 1 second.
(When pressing the power button it lights on for 1 second and turns of.)
Doing manual reset as you told did not change the result.
Then, I removed both RAM (I have two RAMs) and manually greset and put one of them back on to the other’s slot. I pressed the power button.
Then, I swapped the two RAM again (putting the other RAM but this time in its correct slot.)
That lead to the same situation of 1 sec shut down again (however, it took ~4 sec initially)
Then, reswapping the RAM again (putting the initial RAM in the initial position)
Then I played around some more but couldn’t get a different result.

Also, I’ve realized that the ~4 seconds that it takes initially does changes the ME region in the bios. (Changes are only in the first 269 KB of the whole ~2 MB ME region)
(I used the programmer to read the contents after trying to power on the computer)

Here are some observations:
When I make a change on the current RAM status (removing a RAM/adding a RAM/changing a RAM’s slot, however NOT taking a RAM out and putting it back to the same slot) with or without manual greset, the initial boot try after doing that change takes ~4-5 seconds and the next boot tries each take ~1 seconds.
That is so when the RTC is plugged

When RTC is also removed the effect is kinda different: When replugging AC independent of RAM statuses, the power on button turns on (without press) for 1 sec, turns off for 4 sec and turns on for ~5 sec just as in the above situation. Then, if I press the button it turns on for ~1 sec and turns off just as in the above situation.

If I remove both RAM, and RTC is removed then when plugging AC: 1 sec on - 4 sec off - indefinetely on
If I remove both RAM, and RTC is plugged and after plugging AC: when pressed power button - indefinetely on (as expected :smiley: with no RAM)

Then, I’ve tried the whole process again with both after.bin and your outimage.bin using my programmer but couldn’t get a different result.

What do you think?

4

I would use the programmer only from now on. The fixed ME firmware should be just fine so the problem is elsewhere. Either BIOS or hardware. Probably BIOS though and more specifically, bad NVRAM. Try the attached outimage2 with the programmer which is the previous one but with the stock ASUS BIOS inserted (after removing the AMI Capsule Header via UEFITool first of course).

outimage2.rar (3.09 MB)

5

Hi, I’ve solved my problem!! Thanks a lot for all your help!

Here’s what I did:
A. Found another dump of the same model laptop from web. Tried to flash it directly => resulted in the same meinfo/memanuf error but the pc did boot.
B. Cleaned that dump’s ME Region with your guide and flashed that. Bingo! It did open and meinfo/memanuf successfully communicated with the ME. Also, my initial 20 seconds of black screen before bios disappeared.
C. I had another dump from AFUDOS when I didn’t had a flash programmer (only Bios region - 6 mB).

My initial problem was that the bios loaded after 20 seconds of black screen time while not showing any POST info or logo. I have been trying to solve that problem for over a month. Before knowing about ME region, I thought my bios was corrupted. I tried to reflash my bios via ASUS files (6 mB), and I successfully did it with AFUDOS but some of my bios options have changed. However, everything else ran the way it was before (my problem was not fixed). So I kept researching and in the end I’ve learned about ME region, what a full SPI was, etc. in this forum and especially thanks to you @plutomaniac Then, I’ve failed to succeed on pinmod, thus, I ordered myself a programmer and a test clip. With them I was able to unlock FD and start flashing the whole SPI. Then, the story continues in the post #1 :D. To sum up, I had a Bios region only backup from a month ago.

D. I’ve opened FIT and following your guide created a new Cleaned .bin SPI using the before.bin I’ve given to you previously. However, I replaced the above old BIOS Region.bin file in FIT just as we do it for the ME Region.bin in your guide. Then, I’ve continued with the steps in your guide and created the new .bin file by hitting build image on FIT. I flashed that new binary and it worked! Again, my 20 seconds of black screen before bios disappeared, solving my initial problem.

So, here are my findings that maybe can help others:
1. For some reason, after flashing Clean Dumped ME Region, the computer may not turn on at all because of something wrong(?) in the BIOS Region. So trying with another dump may actually help.
2. My initial problem is indeed related to ME corruption: "Laptop shows a black screen without any logo or post info for ~20 seconds before it loads bios/os."

Again, thanks for sharing your awesome knowledge! Have a nice life!

6


You are right, I found the same solution by luck as I explained in my previous post. Thanks a lot !!!

Now, I’ve also tried the "outimage2.bin" file you provided. That, too, works.