AS/400 System Passwords

From Your Next Level of Support
Revision as of 20:26, 4 May 2026 by Jgeorge44 (talk | contribs) (known technical details of as/400 system password generation)
(diff) ← Older revision | Latest revision (diff) | Newer revision → (diff)
Jump to navigationJump to search

In the AS/400 World, what is a "System Password"?

TODO: Brief Summary of what a password is, and what it's used for.

What we know about the password mechanism, and the triggers. Taken from one of many Discord Chats where I've explained what I know.

Don't think of "system passwords" as passwords in the normal context. The mechanism is basically a quorum check at IPL - the machine compares a known set of parameters (the system model number, serial number, load source disk serial number, and processor type) against three places where that information is stored - the MFIOP/SP, the control panel, and the load source disk. As long as at least 2 out of the 3 locations match, the machine assumes it hasn't been tampered with, and IPLs properly (and makes sure the 3 locations are in sync, if one was different). This allows you to replace one of those components in a machine repair without triggering the quorum failure.

The "password" used here is generated by IBM in response to values the machine shows that you need to give to IBM to reset this condition. The password isn't really a "password" like in normal usage, it's not stored anywhere, but when you enter this password into the machine, the machine validates the password against the system values in the machine (model, serial, etc) and then "resets" the 3 locations to the current system configuration and un-flags the system password prompt.

Basically the system password is a hash of the model, serial, and so on, and the machine validates that hash and presumes if IBM gave you that password back that you have satisfied whatever criteria IBM needed to give you the password (paying for a new processor class of OS license, or something else monetary back in the day). Nowadays you CAN wheedle a password out of IBM if you trigger one on a machine but it's slow (several months) and somewhat fragile of a process (lots of emails, explanations, and some praying to a good $DEITY or three)

Way Back When in the "Way Back When Days™" you could upgrade AS/400s simply by replacing processor boards, 3rd party marketers would, well, do precisely that, and then IBM would get shorted the upgrade costs and typically OS license costs, so they implemented the system password mechanism to more or less punish people from doing this, or at least make sure they paid IBM a fee for the privilege - system passwords used to cost money. The processor card serial number is actually not used in the password triggering mechanism (as far as I've ever been able to tell) but it's listed there so IBM could look up the original source of the processor card (by what machine it went into when it was first built) to determine how "gray" the gray market was that the sketchy upgrade came from.

I know a lot about how this process works because the reseller I used to FE for was the largest source of 3rd party AS/400 upgrades and was largely the reason these system passwords were put in place in the first place 🙂

Q: do we know more about how that hash (or whatever) and where exactly it is stored inside MFIOP/SP, the control panel, and the load source disk? like... in the control panel, is it a simple EEPROM or something more intricate?

This "hash" is never stored on the machine, the data used to trigger the password is stored pretty much plain text in all locations - the hash uses that data, and some encryption key hidden in SLIC somewhere - to validate the configuration. Think of it more as a digitial signature - hash(input data) is generated within the machine (at that screen above) and compared to the password provided by the user. if the hashes match, then everything is reset. the hash itself is never stored anywhere. We know (well, I'm 99.999% certain we know) THAT its stored in those three places, but WHERE exactly isn't completely known. The control panel has battery-backed RAM in it (in addition to the TOD clock) so presumably the data is stored in that RAM. We have no idea where it's stored in the MFIOP/SP because it's not documented really well enough for us to know, and there's no visible flashprom chip on any of the boards that we've seen. It's stored on the load source disk, and there are a couple of places where the data can be found, but no real experimentation on if those values could be altered successfully.

In theory you should be able to alter that data on the load source disk, and in the control panel RAM, and upgrade hardware without triggering a password, but there's not been any attempt at that as far as I know because you basically get one chance to do it right before you trigger the actual password mechanism, and I know IBM can be wheedled out of a system password once, but I'm pretty sure they wouldn't do it for the same machine for multiple attempts

Anyhow, thats all anyone knows about the system password functionality that are willing to speak publicly about it 👀

Comment: It must have some way to restore the data into the control panel then because I had 0000BBBB and like 0.3V on the planar battery.

Yes. if the MFIOP and load source disk match the control panel is rewritten without incident also you can replace the load source disk and the system will tell you that the load source disk is different (and give you the OLD serial number, stored in these areas) and let you "approve" the load source change, which then updates the config data with the new serial number you can replace any one of those 3 componets, one at a time, without triggering the password

What makes CISC machines notoriously more touchy about this is that older OSes with the first incarnations of the system password trigger were WELL known for false triggers, and sometimes would trigger a system password on the machine from OS upgrades, or from other non-trigger hardware upgrades (memory, more I/O, etc) because the trigger mechanism was buggy and overly paranoid by the time RISC machines came about the triggers were less paranoid, and mostly legitimately triggered when they were needed, though not always - but significantly less than the number of false triggers in CISC machines and like V2R2 and V2R3

Comment: You know, this is deserving of a blog post of some sort

jgeorge: I should write it down somewhere instead of typing it all up all the time