PSpice is Cadence's SPICE simulator. Vendors encrypt component models with it, which locks them to PSpice and prevents use in NGSpice, Xyce, etc. Modes 0-3 and 5 derive keys entirely from constants in the binary, so those are straightforward once you extract them.
Mode 4 is the interesting one. It's the only mode with user-supplied key material and uses AES-256 in ECB mode. The key derivation has two base keys: a 4-byte short key (originally for DES) and a 27-byte extended key (intended for AES). The code passes only the short key to the AES engine -- it looks like a copy-paste from the DES path that was never corrected. The short key gets null-terminated and zero-padded to 32 bytes, so 28 of 32 AES key bytes are known. Effective keyspace is 2^32, brute-forceable in seconds with AES-NI.
The first encrypted block after every marker is a metadata header with a known plaintext prefix, which gives you a crib for validation. Once you recover the 4-byte short key, the full user key is also recoverable from the decrypted header.
This has likely been shipping since PSpice 16.6 in 2014. Fixing it would break every encrypted model created in the last twelve years.
The blog post linked above walks through the full details. The repo also has specifications documenting all the encryption schemes: https://github.com/jtsylve/spice-crypt/tree/v2.0.1/SPECIFICA...
And a 27-byte key for AES-256 is also slightly undersized. Far from catastrophic but, like brown M&M's in the green room of a Van Halen concert venue, it's a strong signal that something is off...
And the idea for the AES key seems to have been: 27-byte key, 4-byte version, 1 byte null terminator for a total of 32 bytes.
TFA mentions that AES is used in ECB mode, which is infamous for being literally visible[1]. It would be interesting to see if the circuit encoding exhibits this.
The Bug
Mode 4 uses AES-256 in ECB mode ...
They did use AES-256 though, because using keys that go to 11 for your insecure encryption looks good in the marketing materials.
Back in the day we wrote a simple byte-level nonce + delta obfuscator for a terrible Node-RED-like programming environment so that we could tick a "must not be human-readable" requirements checkbox.
If the cryptography, proper or not, has been written for DRM purposes, no legal department is going to permit digging into implementation details even with a ten feet pole.