Yes, I only showed you that info about MAC in regards to meaning "This is where MAC is stored" IN "This Exact BIOS" only type of thing. Due to this areas contents vary, it's location will likely differ in all systems

MAC address cannot be "Changed" only corrected (added back in). MAC address can ONLY be the MAC address that was originally programmed to that system when it was manufactured, you can't "change it" unless you replace the chip (This is for legal reasons)

Modding BIOS you can update stuff, change settings etc, lots can be done in a mod BIOS.
Reasons to use M-Flash vs programmer, when you don't care about serial or MAC is that M-Flash does not require you to clip on the the chip and add more wear and tear on your clip (if it's cheap one it will only grab hold so many times before it stops being able to grab a chip properly)
And when you use M-Flash you also are not risking shorting anything out like you are with programmer.

Unless you have a ME FW issue, then no, what you linked about ME FW has nothing to do with what we're discussing here

I am not sure where, why etc, I would advise you to program in stock BIOS vs anything else, as you mentioned above. Maybe you misunderstood me?
I would always advise dump BIOS with programmer if programmer being used, edit that, then program back. Same for M-Flash, dump with M-Flash, edit, M-Flash back.
If you cannot boot a board, bricked BIOS, dump it with programmer, send to me to fix, then program that back. <<< Here, I think is maybe where you thought I said use stock BIOS, I didn't, except when you said you already have used stock + Programmer to fix a bricked board (and didn't get backup first)
^^ So in that case, then yes, stock BIOS + programmer would be your only option, unless you program in some other same model programmer dumped BIOS << This would be ideal if BIOS is bricked and you do not have backup, but DO have same exact other system + Fix MAC First


Yes, MAC tools like that may work on these systems, only you can find out by zero or FF out current known working MAC. Then use tool to try and fix, then test and see if fixed or not.

You have programmer, so Realtek Pinmod not required here. Yes, I can unlock FD for you on any BIOS, but you must then program that BIOS in with programmer and not program in any other BIOS later without first unlocking it's FD (or replacing the FD with one I unlock for you first)
Yes, M-Flash does not usually write in FD region, so programming it in would be required (just once)

Zitat von Lost_N_BIOS im Beitrag #16

---

Unless you have a ME FW issue, then no, what you linked about ME FW has nothing to do with what we're discussing here

---

Zitat

---

I am not sure where, why etc, I would advise you to program in stock BIOS vs anything else, as you mentioned above. Maybe you misunderstood me?
I would always advise dump BIOS with programmer if programmer being used, edit that, then program back. Same for M-Flash, dump with M-Flash, edit, M-Flash back.

---

Yep I just misunderstood. I just expected, you hadn't noticed that I'd know for the reason with the backup dump already, as you reminded just few times to do backup dump. I think we were a bit crosstalking (yes you meant the MAC address of course ), it just had diffculties (with my too much) text, to explain that I had done a 1.4 backup already. But you just warned me to dump first, as you (Maybe) had to fear I could forget.

Zitat

---

If you cannot boot a board, bricked BIOS, dump it with programmer, send to me to fix, then program that back. <<< Here, I think is maybe where you thought I said use stock BIOS, I didn't, except when you said you already have used stock + Programmer to fix a bricked board (and didn't get backup first)

---

Yep firmware 1.4 was dumped wirh programmer. I also took an MFlah 1.4 dump, but here UEFI-Tool NE does show other structure than on the programmer dump (on MFlash 1.4 dump there's no ME,BIOS-region structure visible, so MFlash dump probably the fraud one, and from programmer (principly) OK, with the 2alternating (only 1-Byte differing)checksum periods we talked about.

Zitat

---

^^ So in that case, then yes, stock BIOS + programmer would be your only option, unless you program in some other same model programmer dumped BIOS << This would be ideal if BIOS is bricked and you do not have backup, but DO have same exact other system + Fix MAC First

---

Thx.

Zitat

---

Yes, MAC tools like that may work on these systems, only you can find out by zero or FF out current known working MAC. Then use tool to try and fix, then test and see if fixed or not.

---

Yep I'll try with Asrock MAC Tool. So hexediting is not working? At least we found exact location via UEFITool and hexeditor in which GUID {...} in 1.4 and 1.A the MAC address is stored, at which offset. Is it possible that the MAC-address might be at another GUID in 1.A version compared to 1.4 ? (here MAC is blanc of course on the flashed stock 1.A firmware with programmer)

Zitat

---

You have programmer, so Realtek Pinmod not required here. Yes, I can unlock FD for you on any BIOS, but you must then program that BIOS in with programmer and not program in any other BIOS later without first unlocking it's FD (or replacing the FD with one I unlock for you first)
Yes, M-Flash does not usually write in FD region, so programming it in would be required (just once)

---

yes then I wouldn't need programmer so often, but could use "FPT" without needing the Realtek mod, which could be bit risky s.times, but I have much patience etc. so not too big deal.
---

Zitat

---

Yes, I only showed you that info about MAC in regards to meaning "This is where MAC is stored" IN "This Exact BIOS" only type of thing. Due to this areas contents vary, it's location will likely differ in all systems

---

I know, MAC is unique. Evry ntwork card has its own MAC address, and if s.o changed it in the firmware on another card to the same MAC as other has, and bot network cards in same LAN, it causes networking intranet/internet issues.

Zitat

---

MAC address cannot be "Changed" only corrected (added back in). MAC address can ONLY be the MAC address that was originally programmed to that system when it was manufactured, you can't "change it" unless you replace the chip (This is for legal reasons)

---

Yes the MAC can only be changed, if itÄs in a programmable chip, to where you get a interface-connection established to, so that you could write in a firmware with a changed MAC-address into, correct?
/And /or you mean notpossible as in the network-chip itself (hard-wired)?
(Aynway not important to me, as just get it back, matching to as it was before.

Zitat

---

Modding BIOS you can update stuff, change settings etc, lots can be done in a mod BIOS.
Reasons to use M-Flash vs programmer, when you don't care about serial or MAC is that M-Flash does not require you to clip on the the chip and add more wear and tear on your clip (if it's cheap one it will only grab hold so many times before it stops being able to grab a chip properly)

---

A had that issue recently, but in a special situation. I tried to recover an SATA-USB-bridge firmware for an Asmedia ASM1153E SATA-USB-bridge chio, from a Fantec DB-ALU3e-6G SATA-6G ->USB 3.0-B +eSATA-6G enclosure.
The firmware got bricked as I flashed wrong firmware. Asmedia MPTool firmware-tool no longer detected the bridge to recover any firmware, so I had to use ext. programmer.
The problem was the SOIC-clamp in this situation at first, but mainly the EEPROM Fudan FM25F001 chip, being too near to USB-3.0-port. So I had to cut the SOIC-clamp a bit narrower, to get less wide. This was not the problem itself that it got narrower, that it wouldn't hold.
(I had to start the putting of the SOIC-clamp to other more-open side-direction, which is away from USB-port, to attach it properly, and retry a few more times)Ribbing off a bit plastic helped, to get the attached in tolerant enough mostly rectangular-enoguh angled, without slipping off, and detecting the CHIP-ID.
But later I had to retry more often than normally here in this case, until it was attached properly.
Later the clip/clamp's brass-contacts slipped to the inner side ca 1mm into. And then it didn't have far enough contact with the SOIC-chip-Pins anymore, even though attached fully as before, where it still had worked.

Then I took a small "combination pliers"/engineers pliers -tool and a small thin needle. I hooked the too much to the behind movec clip's brass/gold/plated-contacts a little bit carefully up, and the grabbed pulling with the engineer pliers the too much back-inner-moved brass/golden SOIC-clamp contact back to the outer side, only one-by-one. Worked perfectly, compared with the other new clamps, which were not yet used, contect look perfectly at identical, position Had to do that that with 6 of 8 SOP/SOIC-clip's brass contacts. Worked perfectly like a charm without any problem.
The most issue was only not too pull too much too hard, so that it does not push the cable in behind into the clamp-body, ribbing off any cable. But this was no issue, easier than expected.
And I was more carefully with reattaching the clamping, after that did that 30 time ca, contacts haven't slided back, not any single visible part of any Millimeter so far yet after repairing the clamp. Hehe :)
Programmer again get's the Chip-ID when attaching the clip/clamp.

But anyway still not so helpful as the pirticular PCB in the SATA-USB-adapter hinders being able to write anythig to the EEPROM to recover, just reading works, but not reliable.
I've also replacement Fudan FM25F01 chips, (not within a circuit)
Here I get two stable Chip-IDs reading. With ICSP VC disabled one certain Chip-ID continuesly, with VCC Enabled alaways the other Chip-ID.
On the Fantec with the in-placed FM25F01, I get always the VID-reading, from the NOT-builtin-chip with "ICSP VCC (Disabled setting)". So the replacement chip might be fraud, not sn original FM25F01, and/or over reason. or the Chip ID one from ICSP Vcc enabled is just the correct one.

I've bough several few clamps. Just the the pricely cheap ones with 1€ per piece,inclduing with a DIP/DIL-SOIC adapter+flat cable. Works good. I've also a Panoma clamp, but they are overpriced.
---

What matters short circuiting. I think there can't happen so much. VCC and GND is diagnally on the SOIC-chip very far from each other. And next to VCC-EEPROM-pin is the HOLD-Pin and Hold anyway needs to be shorted with VCC. OK next to HOLD is another-Pin which it could short-cricuit to, but rather unlikely. Well for me if the clamp had slipped off, it was entirely mostly, and I always watched the clamp, that it doesn't get stay into a moved angular angle, which is the most problematic.

Anyway my TL86XX programmer has short-circuit and off-protect protection, and just power only when at reading/writing EEPROM-phase. Anyway when it hasn't contact to the EEPROM pins anymore doing, the process stops immediately "Bad contact, check whether good Pin"
So that's why I don't fear too much, that anything happended, while the board is powered by 24pin-wire
-(Black+Green) jumper connected, only then reads CHIP-ID permanently, to read/wrte firmware.

But I would have more fear to do that with other programmer, in case it wouldn'T have that short-circuit,off-protect protection.

Zitat

---

And when you use M-Flash you also are not risking shorting anything out like you are with programmer.

---

Yep

I just if board still booting if Id like to dump whole firmware, after I reflashed via MFlash, I need FD unlocked, to use with FPT, as MFlash on ZH77A-G43 doesn't dump whole firmware, so needs programmer. But programmer is more risky you saying, and it's easier with FPT, (when board still booting)
(In case I need to rewrite/redump, to have to less to use programmer, which saves time. In recsue situation when not booting, still using programmer. :)

ME "Initialized" means it's in a BIOS that has been run, if it's the same model then this is fine. Or, I can always redo and update ME FW to new clean latest version if you wanted too, not a problem

And no, there is no problem to hex edit in MAC, but you need to dump BIOS from that board first and send to me. I may not get it exact at first, IF location matters, but we'll get there.
The only issue here is where this is stored, it's along with other board specific info, and this differs between models, dumps, etc (updates, changes etc). But we will eventually get it proper.
Also, this may just be a "Copy" and not necessary to function, the actual MAC may be stored and used from the chip FW anyway. Either way, I need the correct MAC for the target system, if you do not have on sticker, see if you can use MAC for real or not, if you can, then run IPCONFIG /ALL from CMD prompt and get the MAC ID
No, you cannot "Change" MAC ID, this is burned into the chip. Some chips store a copy of this in their FW and if missing the LAN doesn't work, same if that is not in LAN FW but stored and used from BIOS area (if missing doesn't work), but you can't "Change" the ID without replacing the chip.

Short can happen in board or programmer too, not just the clip itself, so least you use as possible is best. Yes, this probably more of a concern with cheaper programmers though

"Doesn't dump whole firmware" doesn't necessarily mean you can't use FPT or M-Flash etc.
This only means that region may be locked so you can't read/write it, unless you unlock FD first, otherwise you can dump/reflash as-is and that region will just be skipped, with FPT you can direct it to flash by region only, and that is best way to do it anyway
If FD needs unlocked, then yes, at least one dump and edit/reflash with programmer would be needed (or pinmod instead) then after that you could read/write all regions with FPT

Zitat

---

{...}
And no, there is no problem to hex edit in MAC, but you need to dump BIOS from that board first and send to me. I may not get it exact at first, IF location matters, but we'll get there.
The only issue here is where this is stored, it's along with other board specific info, and this differs between models, dumps, etc (updates, changes etc). But we will eventually get it proper.
Also, this may just be a "Copy" and not necessary to function, the actual MAC may be stored and used from the chip FW anyway. Either way, I need the correct MAC for the target system, if you do not have on sticker, see if you can use MAC for real or not, if you can, then run IPCONFIG /ALL from CMD prompt and get the MAC ID{...}

---

Checked"ipconfig" and in the "System information" section in firmware, the MAC address from the sticker is listed. (Even though in the firmware in EEPROM the MAC got missing from flashing stock 1.A firmware with programmer)

I've made a dump from 1.A firmware from ZH77A-G43 mainboard, attached below, as you requested (see below)

Didn't need putting temporarily any jumper addionally at all on the PWR and reset pins with the 1.A firmware.
I did it 40 times all in all, to see behaviour and how reliable. At every ca. 6th dump I get a different checksum, the rest 5 redumps in that period are all identical (checksum: sha256sum: 253152d1a0c650bc3b006e8af713ed0b1d32c7786ebbf70dc53b6731753129dc).
Now there was not any tweo-checksum pattern phenomenom as I had before on 1.4 firmware, all rest normal.
All rest ca. 35 times tested redumping also identical (253152d1a0c650bc3b006e8af713ed0b1d32c7786ebbf70dc53b6731753129dc), (only evey ca. 6th. time a new random different checksum pattern.). Tested here with "ICSP VCC (dis)abled".
It was interestingly more reliable with "ICSP VCC (dis)abled" than with "ICSP VCC enabled". With enabled, only ca. every one up to 3rd time I got (253152d1a0c650bc3b006e8af713ed0b1d32c7786ebbf70dc53b6731753129dc), in between next tries more random different checksum pattern, than with ICSP (disabled)=here=better

So dump with checksum sha256: 253152d1a0c650bc3b006e8af713ed0b1d32c7786ebbf70dc53b6731753129dc) within zip, should be good.
Attached:
MSI_ZH77A_G43_1.A0_MFlash_reflashed-FW_EEPROM-Backup_TL866II_Plus_-Verify-OK.zip
---------------------------------------------------------------
Below I attempted MAC hexediting, I hope it's done correct way. Could you check?

In the 1.4 firmware dump in UEFITool at GUID {05CA01FC-0FC1-...} you found and showed me MAC address from the sticker label, within the long hex string: ...73 53 69 44 1A 00 24 75 44 01 00 00 00 00 00 00 00 00 00 00 8C 89 A5 E1 93 E9 73 70 57 64 60 00 24 73 24 01...
In 1.A dump I also found that text string like in 1.4 dump, only just the "00" replaced by "FF" and the MAC address missing:

1.4 original-fw-dump
0x "...73 53 69 44 1A 00 24 75 44 01 00 00 00 00 00 00 00 00 00 00 8C 89 A5 E1 93 E9 73 70 57 64 60 00 24 73 24 01..."

1.A stock firmware reflashed back with ext. programmer, then reflashed with 1.A stock with MFlash (ME region + BIOS) -dump:
0x "...73 53 69 44 1A 00 24 75 44 01 FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF 73 70 57 64 60 00 24 73 24 01..."
--
I've hexedited the MAC into the last six (6) Bytes with * FF, so the last 6 bytes before the (0x 73 70 57 64 .. ..) in the 1.A dump firmware, so that I inserted it at same corresponding position of the both nearly same long hex strings in the 1.A firmware as in 1.4 firmware:

1.A stock firmware reflashed back with ext. programmer, then reflashed with 1.A stock with MFlash (ME region + BIOS) -dump - MAC hex values hexedited into:
0x "...73 53 69 44 1A 00 24 75 44 01 FF FF FF FF FF FF FF FF FF FF 8C 89 A5 E1 93 E9 73 70 57 64 60 00 24 73 24 01..."

Interestingly in UEFI-Tool at GUID {05CA01FC-0FC1-...}the position of the found long text string appears a little bit shifted compared from 1.4 firmware dump and 1.A firmware dump, visible in picture below (on the left: UEFI-Tool), (as still in hexeditor the long nearly matching text string is shown at identical offsets, when opening 1.4 dump and 1.A dump in hexeditor)

See picture, where I hexedited the MAC into (see picture on the right bottom the Red letters)



And see result:
"MSI_ZH77A_G43_1.A0_MFlash_reflashed-FW_EEPROM-Backup_TL866II_Plus_-Verify-OK-_MAC-hexedit.zip"
- compared to
MSI_ZH77A_G43_1.A0_MFlash_reflashed-FW_EEPROM-Backup_TL866II_Plus_-Verify-OK.zip

Is this correctly hexedited the MAC at correct place, and if yes, more to modify?

Tell me MAC you want in, and link ONLY that BIOS (1x copy) and I will see if it should go in same place, if not then where etc (probably not same)
Actually, what you have there at the end may be OK, good guessing
I can't say for sure 100% without looking at BIOS, but since you said MAC is already visible without this (and I assume Ethernet LAN functions, correct?) Then this doesn't really matter too much to have to be exact.

I've deleted the other attachments, so that it's not confusing.

Just take in post #19 the remaining one: MSI_ZH77A_G43_1.A0_MFlash_reflashed-FW_EEPROM-Backup_TL866II_Plus_-Verify-OK.zip

Extract the zip.
Then could you do the hexediting the MAC into the .BIN file?
=> 8C 89 A5 A1 93 E9

Then repack it to zip.

And after that could you attach this?

Later then I'll compare with mine, if identical.

If not identical I'd look to find out why, and/or I'd ask back how you did it.
---

OK, I will get on this for you tonight

* Edit - @Vincent12 - Here, I think you had it right when you did before too! Do edit via direct hex only on BIOS as a whole, otherwise padding file can be removed
http://s000.tinyupload.com/index.php?fil...508511830040415

Just compared your hexedit with mine.
Checksum certainly would match actually between my hexedit to yours, as same offset positions I used like you,
if I had just told you entirely correct MAC you using that (my mistake)

(I had told you wrong MAC at post #21, sry)
Wrong: 8C 89 A5 A1 93 E9
This one is correct 8C 89 A5 E1 93 E9

But I used right MAC in the hexediting. I also had written wrong MAC within the long text string in post #19, but at correct psoition (see edit history), just have corrected in #19, (but won't at #21).
---
So all in all everything is correct (principially) actually, could I reflash the (1A-MFlash-reflashed)-dump hexedited with the MAC with my ext. programmer?
Then after that I'd use MFlash to flash your mod with the CPU-microcodes, LAN update etc, you gave me in ealier post?

Maybe unlocking FD is not so important to me, as I can use ext. programmer with ICSP with the SOIC-clip/clap reliably on this board anyway, and maybe a locked FD could be a good security measure.
---

I also had attempted repairing an SOIC test/clip/clamp, with a thin nail (ca. 0.5-1mm max. thin) pushing the brass contact a bit up,
to reach and grab the brass contacts better and more easily with some small plier tool and pulling the brass contact from the clamp ca 1mm back to its original position. Works like a charm:)

I used such as a plier tool:
https://www.amazon.com/-/de/dp/B0001P0C0...=ÅMÅ;ŽÕÑ&keywords=KNIPEX+26+22+200+Flachrundzange+mit+Schneide+(Storchschnabelzange)+schwarz+atramentiert+mit+Mehrkomponenten-Hüllen+200+mm&qid=1583686144&sr=8-1-fkmr1

Works likea charm with that smaller tool and the tiny nail, in case you'd need a tip to repair a SOIC/SOP-test-clip/clamp :)

Yes, you can program in BIOS as we fixed it about the MAC. Then M-Flash after any ucode/LAN updated BIOS etc, the MAC will remain in place and you don't need to program in that kind of BIOS mod. You may need to rename file to stock name.extension for M-Flash to take it, but not always.
About unlocking FD, you can easily do that before you program in the MAC Fix BIOS, it's easy and you can do the edit I'm sure See the thread below, look at spoiler #2 in section "B", image #1 - Never mind, in the file I sent you FD is already unlocked, so one of us must have done previously

You should consider better clamp, Pomona 5250 wont need repair for LONG Time, it's mich higher quality clip and last long time (but pricey $15-18 usually)

Sry for delayed response. Just want to let you know. Only tested MMTool one, you recommended to do first. Your modded file works, boots fine.

I'd like to ask s.th. about another baord. But I'm noot too much in hurry, it's not so important as I can "circumvent" it.

And I don't want to take advantage of s.b. just because I got him donation etc. nor to give him bad conscience.

Just if you should have time and if not too much to do propably for others, for now, in case if were interested, tell me, I'd ask back, otherwise it's not so important etc.

@Vincent12 - No worries about late reply, I am ALWAYS buried, behind, and extra late, so I know how it is
Good to hear the BIOS is working well!

No problem about other BIOS, not sure what you mean up there, but you wouldn't be taking advantage of me, it's OK
Let me know the model and the issue and I'll try to help

I mentioned about Foxconn H61M-S (AMI Aptio 4), about removing BIOS-Administrator-password from firmware-image.
Booting and Quick-Bootmenu is possible, for entering firmware-setup it asks for the Admin-BIOS-password.

So far with help of my father we managed to find out the location (/and/or a 2nd location) where BIOS-password is stored (encrypted) with help of this guide.
https://gist.github.com/en4rab/550880c09...bf3039e3c8ab6fd
Recovering the BIOS password from a Panasonic CF-U1 mk2 (AMI Aptio UEFI)


We also find out that blancing BIOS password (via hexedit), refalshing image, for entering setup, it still wants Admin-password..
We found out the password: IA4KD
It seems to be a standard-BIOS-password, used by BOSCH company, after doing a google search for "IA4KD".
The mainboard was purchased from ebay, 2nd hand, and at BIOS-BOOT splash-logo it shows "beissbarth".
https://www.beissbarth-online.com
---
SO "IA4KD" is accepted and can I get into Setup now, and clear the Admin-password, with changing password option in Setup, typing in when asking for old password+return, new password (leaving field blanc) +return, again return as confirmation.

After I cleared password, I shut off PC,
and made a 2nd dump with external programmer. In C811FA38-42C8-4579-A9BB-60E94EDDFB34 (AMITSESetup)" the coded password area gets blanc aftter cleared the password.

The Admin-password is cleared, but only temporarily.

When attempting a CMOS-reset or putting out battery, I have to redo the procedure or just enter "IA4KD" to get into the setup.

After Password got back automatically after CMOS reset and PC booting freshly, we found the password area in C811FA38-42C8-4579-A9BB-60E94EDDFB34 (AMITSESetup) is filled again with the old coded password.
So it appears firmware has stored the password at 2nd location, and after CMOS reset it copies the password back to C811FA38-42C8-4579-A9BB-60E94EDDFB34 (AMITSESetup) from backup area.
Afaik we did a hex search in the BIOS file, for the old chiffred password , but we didn't find it in hexeditor.
Maybe I used the original file, but forgot to search on 2nd dump after cleared password.
Maybe the firmware shifts the password from C811FA38-42C8-4579-A9BB-60E94EDDFB34 (AMITSESetup) to another area while it acts as inactive.

Overwriting EEPROM with a stock firmware also clears the password, but Foxconn has shut off his Download-servers since severals months, and on Internet I only get, are older versions and for non-OEM -HM61M-S board, booting also, but they behave more buggy than the original B93F1T02 one. B93F1T02 and newer ones are not available on internet, or pürobably just dubios 3rd party-pages wanting money for Download.

This is not very serious at all. But if you maybe have an idea, or in which direction to look further, would be cool.
But anyway we're not sure if was possible to clear the password fully, and even if, it's probably very difficult, at least for for us,
but you have more experience to do that.

Attachment: Foxconn_H61M-S_-Original-FW_B93F1T02_EEPROM-Backup_-gut_ausgelesen_-Password.zip
---
Foxconn_H61M-S_-Original-FW_B93F1T02_EEPROM-Backup_-gut_ausgelesen_-Password.BIN

->UEFITool_NE.exe
->Open Image File ->"Foxconn_H61M-S_-Original-FW_B93F1T02_EEPROM-Backup_-gut_ausgelesen_-Password.BIN"
->Intel Image ->BIOS Region
->EfiFirmwareFileSystemGuid
->NVRAM
->C811FA38-42C8-4579-A9BB-60E94EDDFB34 (AMITSESetup)
->right klick "Body hex view..."
"Body hex view...": Offset 0x28 <->0x4F
(Before Offset 0x28 there are just much zeros (USER-Password is NOT set)
From Offset 0x28 <->0x4F : No zeros and no FF : (=Admin-Password is set)
---

"So Xoring the above encoded password "Body hex view...": Offset 0x28 <->0x4F" (=0x28 bytes (including offset 0x28 and 0x4F =40 dec. Bytes =80 digits)
(here)
12 93 F7 26 25 BA 27 4D 83 E0 22 74 7D 07 D8 9A 33 2E 8E C1 E9 54 44 E8 9F 7B FA 0E 55 A2 B0 35
0B C9 66 5C C1 EF 1C 83

"...with"
(so from leaked XOR-key from AMI Aptio BIOS) 80 digits - (here just use the front 80 digits (dez.) (0x50 digits) for XOR-operation):
5B 93 B6 26 11 BA 6C 4D C7 E0 22 74 7D 07 D8 9A 33 2E 8E C1 E9 54 44 E8 9F 7B FA 0E 55 A2 B0 35 <==(32 Bytes =64 digits)
0B C9 66 5C C1 EF 1C 83 <==(08 Bytes =16 digits)
-------------------------------------------------------------------------------------------------------------------------------------------------------------------
(full leaked XOR-Schlüssel used on some AMI Aptio - 128 digits, (0x80)
(here for me only use the forward 80 (dec.) hex-digits (40 Bytes =0x28 Bytes) of 128 hex-digits (64 Bytes =0x40 Bytes) from leaked full XOR-Key:)
5B 93 B6 26 11 BA 6C 4D C7 E0 22 74 7D 07 D8 9A 33 2E 8E C1 E9 54 44 E8 9F 7B FA 0E 55 A2 B0 35 <==(32 Bytes =64 digits)
0B C9 66 5C C1 EF 1C 83 77 16 D2 A9 2D 3D 88 D0 E3 63 3E F7 99 8A F4 1D 4F B1 AA 44 05 D8 60 6B <==(32 Bytes =64 digits)
-------------------------------------------------------------------------------------------------------------------------------------------------------------------

"gives..." (here for me) - result =>http://xor.pw/
49 00 41 00 34 00 4B 00 44 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
00 00 00 00 00 00 00 00

Administrator-Password (Hex):
49 00 41 00 34 00 4B 00 44 00
(The "00" in between and after, probably can be ignored.
-
https://www.rapidtables.com/convert/number/hex-to-ascii.html

HEX -> ASCII:
49 =I
00 =NUL
41 =A
34 =4
4B =K
44 =D

Administrator-Password (ASCII):
IA4KD

(all in upper case letters)

The Administrator-Passwort "IA4KD" does work! :)
The setup also accepts the password in upper- and lower-case letters.

--------------

Hello

You have found the password for your bios, well done.

I have an asus F402NA bios but there is no password with UEFI tool but when I reflash the bios request administrator password, look for me where the password is.

thank you.

UEFI tool find C811FA38-42C8-4579-A9BB-60E94EDDFB34

Find in S-BPDT ----> OBB end afuwin