a newcomer on WIM'S BIOS forums, though far from being a stranger ... been following forum posts on and off for quite a while.
DISCLAIMER: I do apologize in advance, if I failed to post in appropriate forum section. It just so happens that the topic covers a broad array of aspects related to BIOS, hence my decision to land it here. Also, have mercy if you find any improper use of the term "BIOS" in the given context, or any incorrect references to AMI BIOS platform/family and version.
So here's the challenge that inspired my post - a couple of months ago I got an Atom C2000 platform networking appliance - Lancom R&S UF300 (a.k.a Gateprotect GPA-300v2), essentially a custom modified Caswell CAR-2051 with CAPB-2051 board and Atom C2558 CPU. Bare metal Caswell CAR-2051 appliances seldom show up on the second hand market, for not being designated for consumer market. There's absolutely no documentation for this EOL device available on Caswell's website, nor any downloads for BIOS updates, Intel AVR54 Bug status updates, no drivers, nothing. Try Googling "CAR-2051", you'll get something like 3-4 relevant hits at best.
A device was preloaded with Lancom R&S UTM software (expired license), so I opted to install a serial image of pfSense (no VGA on this one, just RJ45 Console port), by taking out SSD and installing pfSense, having SSD hooked to the board in my desktop PC. The pfSense install was successful, works without a hitch on CAR-2051. Still, I wasn't happy about the fact that I couldn't access the BIOS settings - the default <TAB> key for serial console BIOS Setup access didn't work, which meant that serial port console redirection must have been disabled in BIOS. That's a customized setting, commissioned by Lancom R&S, as the CAR-2051 User Manual implies that it should be "Enabled" by default. Just to be clear - I was getting the console output (running minicom terminal emulator on laptop), but only after OS bootloader would take over the boot process. So I hooked the console cable to the internal COM port header, just to check if port redirection is "Enabled" for "COM1", and ... voila! - got the pre-boot environment on the screen, showing BIOS splash and prompt, and this time the <TAB> key was working ... until the BIOS password login window smacked me in the face.
I contacted Lancom, then R&S Cybersecurity, but none of them was keen to help, if I don't count the officially unavailable CAR-2051 User Manual, subsequently sent by R&S tech guy ("off the record" courtesy). I begged and moaned for either a factory set BIOS Administrator password or the original unmodified BIOS file, but all the pleas were to no avail. As a last resort I decided to contact the "source"; I knew from before that Caswell was not offering B2C level of customer support (as a rule of thumb), but I had nothing to lose. After third attempt I finally heard from them, but their answer was pretty much as expected ... "contact Lancom or R&S Cybersecurity, as we only cater for B2B businesses ...". Oh well, nothing new under the sun, been there countless times before. I was persistent though, politely of course, and it paid off - a Caswell tech guy sent me the original, unmodified CAR-2051 BIOS .bin file. In retrospect - it was a blessing with a hitch ... I was told that the serial port redirection on COM0 was "Enabled" (that's the front panel RJ45 Console port), but I was also advised that BIOS Administrator password was "Enabled" (can't fathom why, if it's "bare metal" BIOS file...), same as in Lancom R&S modified BIOS in my appliance. I didn't want to sound ungrateful and complain about it, but the thought did cross my mind ... "what's the point of having the serial port redirection on primary COM, if I can't get into BIOS (?!)".
While waiting for a batch of empty SPI Flash SOP8 chips (Winbond 25Q64FVSIG) and SOP8-DIP8 adapter to arrive (I have a Batronix BX40 external USB programmer), purchased as it didn't seem prudent to attempt flashing the original SPI Flash with the file I got from Caswell, risking to brick otherwise perfectly functional device, I've been jumping through hoops to remove that BIOS admin password on my own. Here's the summary of my efforts:
> Tried all the CMOS reset recipes in existence (removing battery - half an hour, then classic CMOS reset jumper method ...), but none of them worked. It did occur to me to try out the cmospwd tool, but to be honest - I was and still am questioning it's magic. If things were so simple, BIOS-es would be hacked remotely for fun by the bad guys. I also came across a rather exotic approach that I've never heard of before, in official Intel document:
Title: "How to Clear the BIOS User Password and the Administrator Password on Intel Server Systems"
Article ID: 000039555
Link: https://www.intel.com/content/www/us/en ... oards.html
NOTE: I have to say that I'm a bit sceptical about this procedure, as I can't see how the slightly different approach would make a profound difference, compared to widely known methods of clearing CMOS. Moreover, it may be working on Intel branded server boards, but somehow I doubt it can be (successfully) used on any random 3rd party Intel platform.
> Installed headless Ubuntu Server on another SSD, which is what I currently use in my CAR-2051 appliance, just to have an access to various BIOS tools that are either loosely supported or not even available for FreeBSD.
> Ran dmidecode command, which gave me lots of hints about onboard BIOS. It appears to be AMI Aptio platform, BIOS revision 5.6. That would be Aptio V, if I'm not mistaken, ran on CAR-2051 in Legacy mode, but is otherwise UEFI 2.3 compliant. I'd like to note that "ROM Size" reported by dmidecode is 6 MB, while current BIOS (backup made with flashrom) and the one I got from Caswell are both 8 MB.
> Backing up the existing BIOS with flashroom tool was a real pain; the tool refused to execute even the basic flashrom --programmer internal command (to identify BIOS chip), complaining about incorrect SMBIOS tables and warning me that I may have an unsupported laptop, which required a modified version of command - flashrom --programmer internal:laptop=this_is_not_a_laptop. After running the modified command, BIOS chip was identified ("W25Q64.V"), but I still couldn't read BIOS and save its content to a file ("Warning: SPI Configuration Lockdown activated.", followed by "Reading flash... FAILED"). Then I remembered there was an "SPI Flash Descriptor Security Override" jumper header on CAR-2051 board (JP3, open by default). I put a jumper on it, then flashrom finally agreed to read BIOS content and save it to a file, albeit still complaining about "SPI Configuration Lockdown activated".
> I examined two .bin files - the one I retrieved from onboard BIOS with flashrom, and the one I got from Caswell - with AMIBCP v5.01.0014 on Win XP 64-bit PC (as I couldn't find a reliable source for Linux version of AMIBCP). Everything looks fine there - no gibberish text in the Settings menus, all menus displayed as expected (compared to printscreens in the CAR-2051 User Manual), all settings - Optimal and Failsafe - set to DEFAULT. I did try to search for the strings, that would give me a hint about the set Administrator password, but I couldn't find anything. Either password is stored somewhere else (the Caswell guy claims it's on BIOS, definitely not on TPM module, which I removed from appliance till it's ready for deployment), or I don't see all the BIOS regions with AMIPCB tool. On the "Setup Configuration" tab there are "Setup", "Recovery" and "IntelRCSetup" parent folders; the "Setup" folder contains a "Security" subfolder, with settings for "Administrator" and "User" passwords (all values set to DEFAULT). That's it, there's absolutely nothing related to ME region and SPI Flash Descriptor protection settings.
I haven't heard from that Caswell tech guy ever since, as if my short lived pro bono unofficial B2C courtesy has expired ... in the blink of an eye. The way I see it, even if I do everything right with the AMIBCP tool (all the right settings changed to USER, on all the relevant PARENT and CHILD levels), then flash successfully the empty SPI Flash with an external programmer, I'll be still hitting the wall for not having the admin BIOS password. I'm hoping to generate some interest on this forum, in case anyone is keen to have a go at "cracking the nut" - finding/extracting the Administrator password from Lancom R&S BIOS .bin file, or offering a fresh approach at disabling it, without running Aptio Setup Utility. I believe I provided all the relevant files (see Caswell CAR-2051 folder in my Dropbox), but I'll gladly relay additional information, if requested.