Caswell CAR-2051 (SPI Flash) - BIOS admin password

Greetings everyone,

a newcomer on Win-Raid forum, 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. Also, be merciful 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 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 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 2B2 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.

  • 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 retreived from onboard BIOS with flashrom, and the one I got from Caswell - with AMIBCP tool 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 (according 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…), 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 “Admisitrator” 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. I uploaded all the relevant files into Caswell CAR-2051 folder in my Dropbox, but I’ll gladly provide additional info, if requested.

Link:

Kind regards,
Bostjan

Open the dumped image in UEFIToolNE, if the password info is stored in the bios it’s almost 100% in NVRAM or a non-empty padding.

Thank you ‘lfb6’,

I see three different tools in the GitHub repo LongSoft (prebuilt packages) - UEFIExtract_NE, UEFIFind_NE and UEFITool_NE. If I get it right, I’m supposed to use … the third one ?

First I’d like to try the Linux 64-bit version, to see how it goes, unless you have a valid argument to have a go at Windows version instead. Will the 32-bit Windows version work OK on the Win XP 64-bit ? I’m not taking this for granted, hence my question.

This guide … Recovering the BIOS password from a Panasonic CF-U1 mk2 (AMI Aptio UEFI) … looks promising. Is there any other tutorial that you would recommend instead ?

Before I forget - beside the two BIOS images - the original Caswell .bin and Lancom R&S (current) version .bin, I also have a nvram dump, which I made with dd command. Looks awfully small in size though (mere 114 bytes), compared to 8MB of those two .bin files.

It’s a steep learning curve, admittedly so, once you cross the threshold of routine SAS HBA flashing and such, and venture into vast and intricate space of today’s BIOS-es scheme of things …

From 2019 onward AMI started to migrate BIOS passwords to TPM module, which did came plugged in the CAR_2051 board in my appliance (Infineon SLB 9655 TT 1.2, currently not plugged in), but luckily my Caswell appliance predates that AMI change.

AMI Announcement

Kind regards,
Bostjan

[UPDATE] None of the Win 32 version worked; tried A62 first, then older 0.28.0. Win XP 64-bit complained about both, reporting not valid 32-bit app (?!).

Tried with Linux A62 on Xubuntu 18.04.6, worked like a charm (no wonder … things have changed since days when Linux was a scary place for novices). I opened the Lancom R&S .bin file, and … have mercy ! It’s like sitting in the cockpit of Space Shuttle, trying to figure out which one among hundreds of buttons to press.

Found another tutorial with XOR-ing magic, with reference to article on GitHub. This XOR-ing wizardry may be easy-peasy task for those in the know, but it’s definitely out of my league. I really wouldn’t mind to be walked through with some “plain-English” step-by-step instructions, as for now I feel kind of “lost in the woods”. Everything I’ve been doing so far was a cakewalk compared to this …

Kind regards,
Bostjan

Well, there’s more ways to store a password…

But your bios setup indeed references AMITSESetup, if you use Universal IFR Extractor on the setup- see attached textfile, search for pass and you find that i references VarStore 0x6 which is “VarStore: VarStoreId: 0x6 [C811FA38-42C8-4579-A9BB-60E94EDDFB34], Size: 0x51, Name: AMITSESetup…”

Unfortunately all occurences I can see in NVRAM or defaults are zeroed.

So somthing is hard coded in one of the modules, or a password flag is set another place with no password stored, or some information in NVRAM is corrupt, or…

Easiest way to start would be emptying NVRAM and see how the system reacts.

Section_PE32_image_Setup_Setup_body IFR.zip (33.7 KB)

I see … had a look at the text file you attached, I won’t pretend I have the slightest clue how to interpret that data (the text and associated HEX values, found with “Admin” as the search string). Is this where the XOR magic would come handy ? The way I see, I can only hope that someone else will chime in …

Flushing the BIOS … would that refer to one of the CMOS reset methods, or do you mean something else ? The only tricks I haven’t tried yet, are the aforementioned cmospwd tool and the slightly odd ball Intel’s approach, described in the article “How to Clear the BIOS User Password and the Administrator Password on Intel Server Systems”. If you know some other hardcore “Swiss Army Knife” tools that are lesser known but effective, please do share …

Kind regards,
Bostjan