Recovering the BIOS password from a Panasonic CF-U1 mk2 (AMI Aptio UEFI)

CF-U1-BIOS.md

Recovering the BIOS password from a Panasonic CF-U1 mk2 (AMI Aptio UEFI)

A mess of my own making

While messing with a CF-U1 handheld PC that I bought off ebay I managed to mess up the BIOS and it seems it reverted to previous settings which included an unknown BIOS password, it would however still boot into windows. Since I could still boot windows I was able to dump the bios flash using AFUWINGUI.EXE the version I used was 3.09.03.1462 which is available here:
https://www.ami.com/support-other/ Click on Aptio 4 AMI Firmware Update Utility

There may be a more appropriate version to use as this seemed to have trouble checking the bios version when flashing but did work if you selected "Do Not Check ROM ID" but flashing isnt needed to get the password.

Dumping the flash

Run AFUWINGUI.EXE and at the bottom of the "Information" tab click the save button to make a backup of your bios, the default name is afuwin.rom Now open this saved image with UEFITool_NE available here:
https://github.com/LongSoft/UEFITool/releases

I used UEFITool_NE_A51_win32.zip later versions should work fine. The new engine (NE) verson seems to deal with AMI's odd nvram format better.

Expand the first EfiFirmwareFilesystemGuid >> NVRAM dropdown tree and look for the GUID
C811FA38-42C8-4579-A9BB-60E94EDDFB34 (AMITSESetup)
with subtype Data there will be others with subtype Link which are older no longer valid entrys because of the odd way AMI nvram works, if you find one of these right click on it and select "Go to data" and it will take you to the actual data entry.
Now right click and select "Body hex view" and you should see something like:

0000  00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00  ................
0010  00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00  ................
0020  00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00  ................
0030  00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00  ................
0040  7B 13 94 A6 07 3A 29 CD D2 60 1A F4 5C 87 ED 1A  {.”¦.:)ÍÒ`.ô\‡í.
0050  07 AE AE 41 DC D4 0A 68 AB FB FA 0E 55 A2 B0 35  .®®AÜÔ.h«ûú.U¢°5
0060  0B C9 66 5C C1 EF 1C 83 77 16 D2 A9 2D 3D 88 D0  .Éf\Áï.ƒw.Ò©-=ˆÐ
0070  E3 63 3E F7 99 8A F4 1D 4F B1 AA 44 05 D8 60 6B  ãc>÷™Šô.O±ªD.Ø`k
0080  01

In this the bytes from 0x00 to 0x3F are the currently unset user password, 0x40 to 0x7F are the obfuscated administrator password and 0x80 is the quiet boot flag.

1337 encryption

The password is obfuscated using super secure xor

VOID PasswordEncode( CHAR16 *Password, UINTN MaxSize)
{
    UINTN	ii;
    unsigned int key = 0x935b;

#if SETUP_PASSWORD_NON_CASE_SENSITIVE
    for ( ii = 0; ii < MaxSize; ii++ )
        Password[ii] = ((Password[ii]>=L'a')&&(Password[ii]<=L'z'))?(Password[ii]+L'A'-L'a'):Password[ii];
#endif

    // Encode the password..
    for ( ii = 1; ii <= MaxSize/2; ii++ )
        Password[ii-1] = (CHAR16)(Password[ii-1] ^ (key*ii));
}

So Xoring the above encoded password:

7B 13 94 A6 07 3A 29 CD D2 60 1A F4 5C 87 ED 1A 07 AE AE 41 DC D4 0A 68 AB FB FA 0E 55 A2 B0 35 
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

with

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 
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

gives

20 80 22 80 16 80 45 80 15 80 38 80 21 80 35 80 34 80 20 80 35 80 4e 80 34 80 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 00 00 00 00 00 00 00

Each character of the password is stored as 2 bytes, and as x86 is wrong endian im guessing should be read as 0x8020 0x8022 I have no idea where the 0x80 comes from possibly its something to do with the EFI_SHIFT_STATE_VALID in this case the password was lower case, possibly uppercase status is encoded in this byte too I have no idea I havent tested uppercase passwords.

WTF scancodes how does this map to keys

From the unobfuscated data you can see the password is 13 characters long, im going to ignore the 0x80 bytes as i dont understand them :P and just look at the others:
20 22 16 45 15 38 21 35 34 20 35 4e 34
They appear to be some sort of scancodes, although while googleing this I found some AMI bioses seem to use ascii here so you can read it out directly as text, but not on this machine.
When this CF-U1 arrived from ebay it had a password which i sucessfully guessed as "toughbook" my second guess would have been "panasonic" since using text written on the front of the PC as a password saves writing it under the battery cover :P
Looking through the older link entrys for the AMITSESetup nvram I found what I thought was the data for this password which deobfuscating as above gave (ignoring the 0x80):

35 39 37 24 25 14 39 39 27
t  o  u  g  h  b  o  o  k

This seemed promising repeated characters have the same value and gives a bit of a key to the mapping Some googeling later about UEFI scancodes and i found this page:
http://wiki.phoenix.com/wiki/index.php/EFI_KEY
From this it seems the value is the offset into this enum so in the toughbook example 35 translates to EfiKeyD5 a second page I found gave the mapping from EfiKey to ascii:
https://github.com/tianocore/edk2/blob/master/MdeModulePkg/Bus/Usb/UsbKbDxe/KeyBoard.c#L36

So i made up a list of byte to ascii using these, below are just 0x10 to 0x4E to cover most values but not be too stupidly long.

Hex	Char	EFIkey	Hex	Char	EFIkey
10	z	EfiKeyB1	30	Tab	EfiKeyTab
11	x	EfiKeyB2	31	q	EfiKeyD1
12	c	EfiKeyB3	32	w	EfiKeyD2
13	v	EfiKeyB4	33	e	EfiKeyD3
14	b	EfiKeyB5	34	r	EfiKeyD4
15	n	EfiKeyB6	35	t	EfiKeyD5
16	m	EfiKeyB7	36	y	EfiKeyD6
17	,	EfiKeyB8	37	u	EfiKeyD7
18	.	EfiKeyB9	38	i	EfiKeyD8
19	/	EfiKeyB10	39	o	EfiKeyD9
1A		EfiKeyRShift	3A	p	EfiKeyD10
1B		EfiKeyUpArrow	3B	[	EfiKeyD11
1C	1	EfiKeyOne	3C	]	EfiKeyD12
1D	2	EfiKeyTwo	3D	\	EfiKeyD13
1E	3	EfiKeyThree	3E		EfiKeyDel
1F		EfiKeyCapsLock	3F		EfiKeyEnd
20	a	EfiKeyC1	40		EfiKeyPgDn
21	s	EfiKeyC2	41	7	EfiKeySeven
22	d	EfiKeyC3	42	8	EfiKeyEight
23	f	EfiKeyC4	43	9	EfiKeyNine
24	g	EfiKeyC5	44	`	EfiKeyE0
25	h	EfiKeyC6	45	1	EfiKeyE1
26	j	EfiKeyC7	46	2	EfiKeyE2
27	k	EfiKeyC8	47	3	EfiKeyE3
28	l	EfiKeyC9	48	4	EfiKeyE4
29	;	EfiKeyC10	49	5	EfiKeyE5
2A	'	EfiKeyC11	4A	6	EfiKeyE6
2B	|	EfiKeyC12	4B	7	EfiKeyE7
2C	4	EfiKeyFour	4C	8	EfiKeyE8
2D	5	EfiKeyFive	4D	9	EfiKeyE9
2E	6	EfiKeySix	4E	0	EfiKeyE10
2F	+	EfiKeyPlus

So what was the password?

Using the above list and the recovered scancodes gave:

20 22 16 45 15 38 21 35 34 20 35 4e 34
a  d  m  1  n  i  s  t  r  a  t  0  r

and when i tried adm1nistrat0r it worked!
This is not complete as there are still questions about the 0x80 bytes but my guess is they encode the shift alt etc modifier keys but im back into my handheld so i'm not sure ill look further into it. This may also apply to other Aptio bioses as well as the Panasonic CF-U1, and if the machine isnt bootable you may be able to use a cheap spi adapter to dump the bios, in the case of the CF-U1 it uses an LPC flash which I don't think you can get cheap clips and readers for and its buried in the machine so a nuisance to get to.

I need help with the XoR part. It's been a minute since I've been in c++, does anyone have a link or example project I can use to decrypt my hash? I have an MK1 CF-31 that I've been trying to extract the password from for 2 years.

using this https://xor.pw/# I'm able to recreate the OP's password (with their hashes), but mine just generated gibberish. Any ideas?

I need help with the XoR part. It's been a minute since I've been in c++, does anyone have a link or example project I can use to decrypt my hash? I have an MK1 CF-31 that I've been trying to extract the password from for 2 years.

@t4thfavor
Just use the website xor.pw,
one field is your hashed password, the other the xor sequence from the first post, which one you put in which field (1/2) doesn't matter.
Make sure to cut the xor sequence from the first post on the end, such that it matches the length of your hashed password.
It is likeley that the length matches already.

Best,
Benjamin

I need help with the XoR part. It's been a minute since I've been in c++, does anyone have a link or example project I can use to decrypt my hash? I have an MK1 CF-31 that I've been trying to extract the password from for 2 years.

@t4thfavor Just use the website xor.pw, one field is your hashed password, the other the xor sequence from the first post, which one you put in which field (1/2) doesn't matter. Make sure to cut the xor sequence from the first post on the end, such that it matches the length of your hashed password. It is likeley that the length matches already.

Best, Benjamin

I did that, I get 0xcc as my first bit which maps to some nonsense character. What are the odds that my bios is encrypted somehow? Everything else matches and I can reproduce your results with the hashes you posted. Mine are just stupid.

This is what I get, and it maps to something like "Ì^M5‰œž¸0^H" where "^H" is one character and :^M is one character, etc.
cc000d00350089009c009e00b80030000800eb0073002800d600c900cc001600c100fc00a300aa000000000000000000000000000000000000000000000000

EDIT: I have two identical machines, both produce the same hashes exactly. Is that good or bad?

This is what I get, and it maps to something like "Ì^M5‰œž¸0^H" where "^H" is one character and :^M is one character, etc. cc000d00350089009c009e00b80030000800eb0073002800d600c900cc001600c100fc00a300aa000000000000000000000000000000000000000000000000

These 20 bytes (with zeros as padding in between) are most likeley a sha1 hash of the password or input keys.
Since hashing is a one way function there is no feasable way to find the password.

But overwriting the hash with all zeros disables the password. Some models have write protection for software flashing the bios in place, which can result in a brick, see the posts above.

@userx14 I overwrote the passwords last night and just overwrote the whole bios image, at first it didn’t work, but then I realized I left a single character in one of the bios blocks. I removed both password blocks and wrote them back from inside windows. Seems to be a serious flaw in their bios security, but whatever, it benefits me this time :)

Thanks for your help!

Hello.
I have a Panasonic CF-AX2 laptop. Unfortunately I only have the user Bios password so I can't boot from USB.
I dumped my BIOS. I found the 2 areas concerned, however I don't see what I can do afterwards to get the supervisor password or delete it.

Thanks for your help

dump link : https://drive.google.com/file/d/1YQbb03qpKXiYYhF8bX1yV_i5Tg36xLAs/view?usp=sharing

You use a hex editor to 0 out the passwords in two places in the rom, then flash it back to the bios chip. Does that help?

ok it's done I replaced the 2 passwords with 0 to 2 places. What tool do I need to flash the bios with?

ok it's done I replaced the 2 passwords with 0 to 2 places. What tool do I need to flash the bios with?

Well, that's the tricky part.
The issue is that the software flasher AFUWIN bricks some laptops, likeley because of write protection of the flash chip.
In this case the only possible way to recover the bios is using a hardware bios programmer like the ch341a,
which can be had for around 10 bucks. The previous posts contain details on this procedure.
Unfortunatelly when backing up the bios with AFUWIN it sometimes only generates a partial backup of half the size, where some parts like the ME-region are missing.
So the first thing you should do, when you consider the software flashing, is to check the size of the flash chip based on the markings on the physical chip and compare with the size of your backup.

Ok i see. my bios chip is N25Q128A. do you know what size the file should be?

Ok i see. my bios chip is N25Q128A. do you know what size the file should be?

That chip is 128Mb / (8 bits per byte) = 16MBytes,
So 16MB is the filesize for a complete dump.

The risk is, that flashing the modified image could not work and "restoring" the chip with a hardware flasher afterwards might get difficult,
as full image dumps are not that easy to find on the web (either paywall or just not available). Also you might loose some model specific things like the mac address of the network card when you flash dumps from someone else.

ok I have all the equipment at home to desolder this component. I will order a programmer to extract and then completely reinject the bios.

ok I have all the equipment at home to desolder this component. I will order a programmer to extract and then completely reinject the bios.

Don't de-solder it, just order one of these clips and some jumper wire - https://uk.farnell.com/pomona/5250/test-clip-8-pos-1-27mm-soj-soic/dp/2406243

Trying the sop8 clip first seems resonable, if it does not work you can always fall back to desoldering.
Sometimes there are additional devices on the 3.3v rail which overwhelm the bios programmer's power output capability,
in which case you have no choise but to desolder or temporarely cut the 3.3V power trace.

Trying the sop8 clip first seems resonable, if it does not work you can always fall back to desoldering. Sometimes there are additional devices on the 3.3v rail which overwhelm the bios programmer's power output capability, in which case you have no choise but to desolder or temporarely cut the 3.3V power trace.

Different devices do certainly behave differently. I have processed hundreds of different bios chips from most vendors (including Apple which has it's own quirks!), there's always a way to make them read. A combination of applying power supply, removing battery, turning the device on (with no battery attached) and then off, without removing power supply can work. Or no battery/no power supply. Sometimes even holding down the power button whilst reading will work. Panasonic is very straightforward and should read just fine with a clip. WSON8 works just the same but using probes.

@warst
Very interesting, indeed.
Which programmer are you using?
I was always afraid of powering the mainboard, since then I feared that there are potentially devices communicating with the bios chip and the output transistors of the programmer would work against the devices on the mainboard (especially the clock line).
Since as far as I know the cheap ones have no additional current limiting resistors for their data lines.

@warst Very interesting, indeed. Which programmer are you using? I was always afraid of powering the mainboard, since then I feared that there are potentially devices communicating with the bios chip and the output transistors of the programmer would work against the devices on the mainboard (especially the clock line). Since as far as I know the cheap ones have no additional current limiting resistors for their data lines.

I use a TL866ii Plus with ICSP adapter, its brilliant and not expensive either. http://www.autoelectric.cn/en/tl866_main.html The board is used to having this low voltage during normal operation so the worst you will get is a bad dump, follow the rule of dump twice and compare for differences (which I'm sure you do) and if the dumps are the same, you are good to proceed. I don't disconnect the connection to the chip until I have flashed back as the chances are, if it read OK, it'll write back OK too. So long as the laptop is in an OFF state, having power applied hasn't ever caused me any issues. The worst I have ever had is a bad dump so then I try a different variation of power/battery combination. I prefer to test with everything removed first and then work my way up to power adapter with no battery and on from there.

I use a TL866ii Plus with ICSP adapter, its brilliant and not expensive either. http://www.autoelectric.cn/en/tl866_main.html The board is used to having this low voltage during normal operation so the worst you will get is a bad dump, follow the rule of dump twice and compare for differences (which I'm sure you do) and if the dumps are the same, you are good to proceed. I don't disconnect the connection to the chip until I have flashed back as the chances are, if it read OK, it'll write back OK too. So long as the laptop is in an OFF state, having power applied hasn't ever caused me any issues. The worst I have ever had is a bad dump so then I try a different variation of power/battery combination. I prefer to test with everything removed first and then work my way up to power adapter with no battery and on from there.

Yeah, that one seems to have way better output protection.
Next time I will come across a board that needs additional power I'm going to try the your method with the off state and connected ac adapter. That probably only powers the 3.3V line and leaves the data pins unpowered, Thanks for the info.

Yeah, that one seems to have way better output protection. Next time I will come across a board that needs additional power I'm going to try the your method with the off state and connected ac adapter. That probably only powers the 3.3V line and leaves the data pins unpowered, Thanks for the info.

No problem at all, let me know how you get on, I have subscribed to this since it started, felt I should at least start commenting to help people out! Oh, also, you do know that some of the chips are 1.8v? I have a little step down in-line module to handle that too, so the clips still just work the same. I also have some tips for WSON8 should you ever want to read those without desoldering/attaching jumper wires to the pads.

Ok that's good I have a clamp for SOP-8 and I bought a TL866II Plus programmer too!
I will keep you posted on my progress as soon as I receive it.

Ok that's good I have a clamp for SOP-8 and I bought a TL866II Plus programmer too!
I will keep you posted on my progress as soon as I receive it.

Make sure you get yourself one of these too - [SPI Driver](￡6.37 | SPI DRIVER, SPI flash in Circuit Programming adapter for TL866II PLUS programmer https://a.aliexpress.com/_v1V1wU)

Hello, I apologize for the question , could the operating hours of a device be modified by this method? is there a tutorial somewhere? thx.

Hello, I apologize for the question , could the operating hours of a device be modified by this method? is there a tutorial somewhere? thx.

Two ways to find out.

1. Take a dump of the bios chip, run PC for several hours, take second dump and then compare them in a hex editor.
2. Take a dump in bios, run PC for several hours, flash it back to PC and see if the hours reset to what they were in the original flash. (This one could cause issues with write protected laptios)

Both methods should give you some reasonable idea on whether or not that info is stored in the bios at all.

That's all worked! I followed this video but without unsoldering the component : https://www.youtube.com/watch?v=YG01jdeMVmk

In link the complete bios of my CF-AX2. This might be useful for someone : https://drive.google.com/drive/folders/1OBuW-YCeXo6noc3bsXV3EaS4PXw6Ia7d?usp=sharing

Only problem I have left. The hard drive is locked and cannot be unlocked ! I will take it out to reformat it on another PC. I do not want to recover the give nor windows 7.

1. hex editor.

Thx I will try. all the best.

Hi! Tell me how to get this string for my CF-53?
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
It is my dump:
0000: 4E5641529800FFFFFF830D414D495453
0010: 455365747570005BE2B69C11CC6C0AC7
0020: AD229C7DD1D8E033748E7DE96D44E89F
0030: BFFA885595B0660B0F66BCC1E51CC677
0040: 16D2A92D3D88D0E3633EF7998AF41D4F
0050: B1AA4405D8606B5BD0B67E113D6C59C7
0060: 6322347DF1D85E33718E0AE966442F9F
0070: 50FAF155F2B0BB0BE1662EC19E1C6A77
0080: 16D2A92D3D88D0E3633EF7998AF41D4F
0090: B1AA4405D8606B01

Hi @avilon-reg

Both passwords are hashed,
the first one corresponds to these bytes in your dump:
5be2b69c11cc6c0ac7ad229c7dd1d8e033748e7de96d44e89fbffa885595b0660b0f66bcc1e51cc67716d2a92d3d88d0e3633ef7998af41d4fb1aa4405d8606b
-> (xored and removed padding in between bytes) ->
71ba76474de8d67a5abc3900c4863753c6e00a45

the second one is here:
5bd0b67e113d6c59c76322347df1d85e33718e0ae966442f9f50faf155f2b0bb0be1662ec19e1c6a7716d2a92d3d88d0e3633ef7998af41d4fb1aa4405d8606b
-> (xored and removed padding in between bytes) ->
435887148340f6c45fcb32c72bff508e287271e9

Both are only the sha1 hash of the respective passwords which one cannot reverse. But you can overwrite the passwords raw bytes in the bios dump with zeros and flash the modified image back to your bios flash. But read some of the previos comments, because some laptops have write protection which bricks the device if you attempt to flash it with afuwin.

Best,
Benjamin

Hi,
I extracted following strings from my Panasonic CF-53 mk1 laptop BIOS.
Would you please help me to find the passwords. The only thing I know so far is my Panasonic has both Power On Password and Administrator Password.
Best Regards

0000 5B 03 B6 49 11 B3 6C 48 C7 3A 22 23 7D F1 D8 E0
0010 33 E7 8E 4E E9 B1 44 08 9F 5E FA F0 55 D8 B0 6C
0020 0B 65 66 F3 C1 34 1C 83 77 16 D2 A9 2D 3D 88 D0
0030 E3 63 3E F7 99 8A F4 1D 4F B1 AA 44 05 D8 60 68
0040 5B BB B6 5B 11 A7 6C FA C7 46 22 CD 7D 5A D8 32
0050 33 CB 8E 17 E9 D9 44 C6 9F 9C FA 4B 55 9A B0 F4
0060 0B 89 66 41 C1 7F 1C FA 77 16 D2 A9 2D 3D 88 D0
0070 E3 63 3E F7 99 8A F4 1D 4F B1 AA 44 05 D8 60 6B
0080 01

@userx14