How can we encrypt RPG Source?
Us programmers can be a secretive bunch. If you see a programmer running screaming from a meeting, clutching a program listing, with a frantic panicked look in their eyes – they have probably just been asked to show their to code to someone else (or even *shock* provide it for code review)
We all know that using IBM I’s neat inline *SOURCE debugging tool we can look at source code for most programs… unless of course, they have been compiled in secret squirrel mode. But sometimes we want to send programs to a third-party with the default being “hide this code” but we can also add the option to “show the code” if they know the password. The secret squirrel password.
Secret Squirrel Mode – Debug Encryption
Anyone that has command line access can use debug (STRDBG) and use the option to display source code. So, IBM added three very nice choices for us at compile time:
1 – no source included in view
2 – full source included in view (a couple of different flavours here but basically it means “show the source if its requested”)
3 – full source included but only if they know the password
This third option is gradually being adopted by most software houses.
So how does it work?
Password controlled source distribution is controlled by the Debug Encryption Key (DBGENCKEY). This is a parameter in CRTRPGMOD, CRTCLMOD, CRTBNDRPG and CRTBNDCL: allowing us to encrypt our software’s embedded debug views. Or in other words, we can distribute fully debuggable code but sleep easily knowing that the code is not viewable by default.
Using the DBGENCKEY parameter tells the debugger to we want to include the source code but to encrypt it. We enter a debug encryption key (aka case-sensitive password) and the source code is bundled up, encrypted using Advanced Encryption Standard (AES), a private key-based block cipher encryption methodology, using the IBM i Cryptographic Services APIs and attached to your object. It is embedded within it and makes no significant increase in size. Obviously its slightly fatter – just like you would be if you ate a AES doughnut with your morning cup of tea.
Once the debug source view is encrypted and attached, it’s as secure as a secure thing.
Note: You must be on IBM I V7.1+ to use debug encryption. If you are on V5 or V6 then you don’t care anyway. Since the older operating systems are unsupported and pretty bloody insecure in comparison – I don’t think source encryption is on your list of priorities. So leave this blog now and go and read about getting the latest and great version of IBM i.
Don’t get too clever with your passwords because you don’t want code page problems if you are trying to view source on a foreign machine with a different code page. I generally stick to upper and lowercase A-Z and 0-9. They key can be up to 512 characters long so I think that gets passed most security obstacles.
So, how do I view embedded source code if its encrypted?
On the STRDBG command you can use the DBGENCKEY to enter decryption key ( password ) that your software vendor supplied.
When you do this, the source code is displayed in your debug session window. You can step through line by line of code just like any other source code member.
Is there a way to enter the decryption key when debugging from RDi? I get a “CPF957E Decryption error occurred” when debugging a program that has a debug decryption key. There is no prompt for entering it that I can find.
Great questions.. and erm… the answer is “I don’t know” 🙁
I’ve never tried to debug an encrypted source program using RDi. Please let me know if you figure this out!