Script Obfuscation
-
I am writing some scripts in VBA (Access 97 would you believe) and I know that they are going to be taken away and copied all over the world without my consent. They are all reasonably WTF-free and properly commented with my name in the header, creation date, update history etc. I would prefer my name NOT to be associated with the inevitable disaster when previously innocuous code such as "drop table Temp" deletes 6 months of someone's work with no backups.
My preferred solution is to put an expiry date into the script - something like:
if now() > "2006-12-31" then msgbox "This script has expired - please call Qwerty on 123456 to get it reactivated"
(Followed by some kind of "end" or divide-by-zero.) This way I can find out who is using it and what they are using it for.
The problem is that the likely users of this sort of thing are quite adept at the script-kiddie level and can easily find the IF statement and delete it. Can you guys suggest what the next level of obfuscation should be, to make the script kiddie say "WTF!" but not actually prevent a real programmer from using the code? Something that will survive the deletion of the "obvious" error message line? VBA is not capable of suporting any extreme obfuscations like overloading the + operator, so I'd prefer submissions in VBScript, JScript or JavaScript. PHP doesn't $count because that's already fairly obscure.
-
I'm not sure obfuscation of VBA is truly possible since its my understanding it is not compiled.
I'm not sure if this will fit your needs, but if you want to lock down the end-users from modifying the VBA code you can convert the database to MDE (tools -> database utilities). This will essentially lockout the end-user from viewing/modifying the source. The development version will still be a regular MDB so that the programmers can still read/modify the code. The upgrade of existing databases gets a little more tricky in this scenario, but doable with a third migration database that pulls data from the original to the new version.
If you want to allow end-users to view/modify the source that gets a little more tricky because you essentially gave away the keys. In this scenario, perhaps the best approach would be to externalize the unmodifiable code.
-
Of course giving access to the source is giving away the keys. I just would like to try something to make the future "programmer" stop and call me first. It's not going to be public - it's just within the same company.
One trick I quite liked for hiding HTML code was to put 100 carriage-returns at the top of the file. If you use view-source, you get a Notepad window that appears to be blank. This stopped me for a minute the first time I saw it.
-
Lock the VBA code down with a password: Tools > Project Properties > Protection (Tab).
Only give the password to "real" programmers.
-
@Albatross said:
Lock the VBA code down with a password: Tools > Project Properties > Protection (Tab).
Only give the password to "real" programmers.
The way I read this, he needs to give access to "programmers," but they're all of the sort that write code that shows up here ...
<flame-retardant underwear mode="on">
This falls into the "right tool for the job" realm. I'm presuming that since you're using Access '97, there's a logical reason, and any of the "use a better tool" comments are pointless... The job is to drive screws, so try to make the best of that screwdriver; don't reach for a hammer.
Were I in your (hugely uncomfortable) shoes, I'd probably take all of the things that I don't want getting misused, and wrap 'em in a VB6 DLL. The differences between VBA and VB6 aren't huge ... Of course, that might be a WTF in its own right. It's a bit more difficult from the "VBA programmer's" perspective to call a DLL than to use the code modules in the MDB, but it would at least prevent the script-kiddies from deleting random bits of code, and you could easily leave your date check in place.
Or do they need to actually change parts of it? If that's the case, your best bet is to scrub all references to yourself from the code, and hope that it never comes back to haunt you. Of course, you'll still know, but at least no one else will.
<flame-retardant underwear />
Good luck.
-
@Sgt. Zim said:
@Albatross said:
Lock the VBA code down with a password: Tools > Project Properties > Protection (Tab).
Only give the password to "real" programmers.
The way I read this, he needs to give access to "programmers," but they're all of the sort that write code that shows up here ...
<flame-retardant underwear mode="on">
This falls into the "right tool for the job" realm. I'm presuming that since you're using Access '97, there's a logical reason, and any of the "use a better tool" comments are pointless... The job is to drive screws, so try to make the best of that screwdriver; don't reach for a hammer.
Were I in your (hugely uncomfortable) shoes, I'd probably take all of the things that I don't want getting misused, and wrap 'em in a VB6 DLL. The differences between VBA and VB6 aren't huge ... Of course, that might be a WTF in its own right. It's a bit more difficult from the "VBA programmer's" perspective to call a DLL than to use the code modules in the MDB, but it would at least prevent the script-kiddies from deleting random bits of code, and you could easily leave your date check in place.
Or do they need to actually change parts of it? If that's the case, your best bet is to scrub all references to yourself from the code, and hope that it never comes back to haunt you. Of course, you'll still know, but at least no one else will.
<flame-retardant underwear />
Good luck.You can easily fix the "difficulty in calling a dll" by distributing a wrapper module. However, if he builds a COM dll in VB6, it is very easy to call it from VBA. So easy that building a wrapper module would seem silly.
