PDA

View Full Version : Gridcase 1520 hardware password after RTC clock replacement



Dagwood
March 1st, 2020, 01:25 PM
Interesting thing happened today. I finally bought a brand new Dallas RTC and installed it in my GridCase 1520. Everything went fine until I went to power it on... Time/Date not set, Press F1, yeah, yeah, ENTER PASSWORD... wait, what? Of course I tried entering a variety of generic guesses but nothing worked. I had already ripped into the BIOS awhile back so I jumped back in and examined the password parts. After about an hour the best I found is the following...

1. It checks CMOS for a password flag

2. It then seems to check the CMOS values where an encrypted password would be stored, just in case there's a password but no flag set. (I could be wrong on this but at quick glance it appears to be the case). This section of code is very obviously obfuscated so one can't just search for the port 70h and 71h CMOS giveaways. It reads the value 70h from some place in RAM to DX, then increments and decrements during loops without ever clearly exposing the value.

3. If there's a password it prompts for input and reads it to memory.

4. It 'encrypts' (more like encodes) the password by XOR'ing it against a static datatable of 8 values (password is max 8 chars)

5. It then reads the CMOS password 8 bytes into memory and compares against the encoded input.

6. It either boots or says wrong password and the machine resets.

I wonder if the BIOS is coded to understand if the RTC clock is not running and implements a factory or custom defined end user password to prevent system access by replacing the RTC chip? I tried to discover this but daylight was wasting so I just patched the BIOS to bypass the password stuff all together and life is good (one whole byte, only had to program the Even EEPROM).

At this point I'm just curious if anyone else has run in to this? I think step 2 might be the key because it contains a lot of funny business.

Dagwood
March 2nd, 2020, 04:18 AM
After sleeping on it I concluded that uninitialized bytes of the new CMOS chip might be 0xFF (default new values, like a blank EPROM). I dumped the CMOS values to confirm was the case. I then reverted to the stock BIOS, calculated the decoded ASCII codes for an encoded password of (hex) FF FF FF FF FF FF FF FF then entered the password as ASCII codes (because most of the resulting characters don't exist on the keyboard). This worked. I never considered that new CMOS chips might need to undergo an initialization procedure prior to installing. I'll do that.

Paralel
April 5th, 2020, 09:50 AM
That's wild stuff. Without a manual (or possibly the manual doesn't even mention it), that kind of stuff is basically a guessing game. Glad you figured it out. It's not exactly intuitive. All systems these days that need to be initialized would ask "Enter NEW Password" so it could be initialized from a blank value, not expect you to enter a blank value to start. It guess it shows that older system essentially worked differently, or that the expectations of users was different so they just expected one to know you would start with a default password since that was common at the time. Of course, one would argue these days, all interfaces should be inherently intuitive, no context needed for understanding.

SParent
August 21st, 2020, 06:07 AM
I replaced the Dallas chip of my 1520 a while ago. I got the "Enter password" too. I didn't get as far as you on the troubleshooting, but I found that clearing the Dallas chip's memory with 0x00's before inserting it in the 1520 is working fine. No password required and the bios initialization process fills the memory with correct data.