I posted SpiceCrypt (https://github.com/jtsylve/spice-crypt) a few days ago for decrypting LTspice models. It now supports all six PSpice encryption modes as well.
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.
A baseless claim may come (and if so, I'll write about it), but this use case is the textbook example of why these exemptions exist, so I can't see how any legal threats could be actionable.