I've recently reverse engineered a bunch of commercial software we pay for. They encrypt values in text configuration files and leave no way for us to template

I've recently reverse engineered a bunch of commercial software we pay for. They encrypt values in text configuration files and leave no way for us to template the configuration files with configuration management (Chef, Ansible, etc). Most of the time I'm working with Java. I've noticed several common patterns: 1) Typically obfuscation is not used, but even when it is used, it's easy to find what you're looking for. They're going to be using JCE or BouncyCastle for encryption. Look for the relevant classes. 2) The key is nearly always hard coded as a string constant that is not unique to the installation or customer. Super easy, and often discoverable with just the 'strings' command line utility. I would find your concats of chars and other silly schemes if you did that, but it would slow me down a bit. 3) IV is never used correctly with AES. It's always a static value, usually 0. 4) License keys are usually encrypted with the same scheme, but their format of entitlements takes some extra effort to discover. I occasionally must reverse engineer this as well to understand the limitations. For example, stupid licenses lock to IP address or a BIOS uuid, complicating a disaster recovery plan. My favorite encounter was a class file, in the spirit of OOP, dedicated to licenses (ie License.class). It was not obfuscated in any way and had both the load() and save() methods included. All one must do is write your own Java class (or use Groovy interpreter), include the vendor jar in your classpath, set your license entitles and call save(). A real WTF is that SAP will encrypt the contents of _your_ database with simple substitution ciphers. If you want to query it for insight, you're going to need their simple character shifting/replacing scheme.