v2 Adds support for PSpice, which should hopefully cover the TI models. Let me know if not. https://github.com/jtsylve/spice-crypt
182 karma · joined August 15, 2016
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...
- This is currently solved by inference pipelines. - Models and techniques improve over time.
The ability for different agents with different specialties to add additional content while being able to take advantage of existing context is what makes the pipeline work.
Storing that content in the format could allow us to continue to refine the information we get from the image over time. Each tool that touches the image can add new context or improve existing context and the image becomes more and more useful over time.
I like the idea.
“A student asked, ‘Yeah, but do the wrinkles always form in the same way?’ And I thought: I haven’t the foggiest clue!” said German, a faculty member at the Thomas J. Watson College of Engineering and Applied Science’s Department of Biomedical Engineering. “So it led to this research to find out.”
Gains were even more impressive when adding some simple loop unrolling: https://jtsylve.blog/post/2022/12/24/Blazingly-Fast-er-SIMD-...
Sorry to offend.
GPL is by definition more restrictive than Apache and BSD, since there are more requirements to use the code, so asking if the developer is willing to consider a less restrictive (not "better") license shouldn't be met with hostility.
My motivation for asking is simply because the project looks interesting and potentially useful; however, the proprietary nature of my current work means that GPL licensed code isn't really an option for me. I absolutely wouldn't hold it against the author if they chose GPL for this or any other reason.