IBM i's QSYRUPWD password API traced to an AES cipher

QSYRUPWD (Retrieve Encrypted User Password) is an IBM i API that hands back a user's password material in encrypted form to authorized callers; IBM documents it as part of the security API set that supports password synchronization, migration, and similar administrative work, without exposing the cleartext password. IBM i is IBM's integrated enterprise platform descended from the AS/400 line, still widely used for ERP, finance, logistics, and manufacturing workloads.

During an IBM i penetration test, a researcher (writing on the security firm Silent Signal's blog) noticed the client's server had the QPWDLVL system value set to 2. IBM documents that QPWDLVL 0 and 1 use an older DES-based scheme, levels 2 and 3 use a SHA-1-based scheme, and level 4 introduces a PBKDF2-based verifier model; at level 2, IBM also states the OS keeps compatibility with multiple password-verifier forms instead of dropping the older ones. John the Ripper ships dedicated IBM i cracking formats, as400_des and as400_ssha1, for the legacy DES and salted-SHA1 material. In the researcher's testing, QSYRUPWD output from systems at QPWDLVL 2 through 4 no longer matched what those John the Ripper formats expect, while the legacy QPWDLVL 0-1 case still worked. The researcher is explicit that this is an empirical finding from testing and tooling analysis, not something IBM publicly documents as the exact returned structure for those levels. Practically, that meant even a caller holding the *ALLOBJ and *SECADM authorities required to invoke QSYRUPWD at all could no longer use the API for real password-strength testing.

To dig into why, the researcher wrote a small CL program, PWDDUMP, that calls QSYRUPWD with the UPWD0100 format and a 4000-byte receiver buffer and prints the raw returned data. They then used IBM i's STRTRC tool to capture a call trace of PWDDUMP's execution and wrote a scraper to turn the raw spool-file trace into a readable call sequence. That trace showed QSYRUPWD's execution passing through internal routines in QSYSERV and QSYMIUTLS before reaching two functions whose names pointed to cryptography: qsy_cipher (in QSYMIUTLS) and qsy_aes_decrypt (in QSYCODEUTL's QSYAESFNC).

To see what those functions actually do, the researcher used System Service Tools (SST), IBM i's low-level diagnostic interface, to dump the disassembled machine code of the QSYMIUTLS, QSYCODEUTL, QZLSRTPW, and QSYRUPWD service programs. Reaching SST requires *SERVICE authority on the OS profile plus a separate set of SST-specific credentials, independent of the normal operating-system logins. Reviewing the disassembly of qsy_cipher and qsy_aes_decrypt, the researcher looked specifically for recognizable block-cipher rounds, key-schedule generation, or calls to documented cryptographic APIs, and found none of it there; the functions instead appear to hand the sensitive work off to lower-level routines. The write-up, as captured for this piece, breaks off partway through an assembly listing of qsy_cipher and does not state a final conclusion about where that delegated cipher work actually happens, or whether the researcher ultimately produced a working way to crack QPWDLVL 2-4 password hashes.

Key facts

A penetration tester found a client's IBM i server set to QPWDLVL 2, where IBM's own documentation places the OS on a SHA-1-based password-verifier scheme (level 0-1 is DES-based, level 4 adds PBKDF2).
John the Ripper's as400_des and as400_ssha1 formats, built for legacy IBM i password material, no longer match QSYRUPWD's output at QPWDLVL 2 through 4, even though the QPWDLVL 0-1 case still works.
Even with the *ALLOBJ and *SECADM authorities that QSYRUPWD requires to be called at all, the API could no longer be used for practical password-strength testing on such systems.
A custom CL program (PWDDUMP) calling QSYRUPWD, plus an STRTRC call trace, showed the API's execution passing through a qsy_cipher routine and a qsy_aes_decrypt function before returning.
Disassembling those routines via System Service Tools (SST), which needs separate *SERVICE credentials, turned up no visible block-cipher rounds or key-schedule code: the actual cryptographic work is delegated further down, into code the write-up (as captured) does not resolve.

Why it matters

IBM i systems descended from the AS/400 line still run core ERP, finance, logistics, and manufacturing workloads at many organizations, and QPWDLVL is the setting that decides which password-verifier scheme those systems use. IBM's public documentation does not spell out QSYRUPWD's exact output structure once QPWDLVL reaches 2 or above, so a security team auditing password strength on such a system loses its working tool (John the Ripper's IBM i formats) without an IBM-documented replacement, which is exactly the gap this research set out to map.

Who it affects

IBM i administrators and security teams running password-strength audits on systems at QPWDLVL 2 or higher, and penetration testers who relied on John the Ripper's as400_des/as400_ssha1 formats against QSYRUPWD output and found it stopped working.

How to use it

This is a documented investigative technique, not a released tool or product. Reproducing it needs a CL program that calls QSYRUPWD with the UPWD0100 format (as the *ALLOBJ and *SECADM authorities that QSYRUPWD itself requires), IBM i's STRTRC command to capture a call trace of that program's execution, and System Service Tools (SST) to disassemble the relevant *SRVPGM objects, which in turn requires *SERVICE authority on the OS profile and a separate SST login. No pricing or licensing applies; nothing here is a shipped crack of QPWDLVL 2-4 hashes.

How solid is it

This is a single practitioner's account of one engagement, and the researcher is explicit that the mismatch between QSYRUPWD's output and John the Ripper's formats is an empirical observation from their own testing and tooling analysis, not something IBM publicly documents. The write-up, as captured here, breaks off mid-disassembly and does not state a final conclusion about what the qsy_cipher and qsy_aes_decrypt routines ultimately delegate to, or whether a working crack of the newer hash format was achieved.

Risks and caveats

The text does not name the researcher, their role at the firm, or the client or industry involved in the original penetration test, and gives no date for when the test or the follow-up analysis took place. There is no CVE, vendor advisory, or stated IBM response tied to this finding, and the underlying question of what QSYRUPWD actually does at QPWDLVL 2-4 is left open rather than answered in the material available.

“This is an empirical observation from our testing and tooling analysis, not a claim that IBM publicly documents the exact returned structure for those levels.”

— the researcher, in the Silent Signal write-up