Protecting Cuda Code


Iv’e been developing an imaging application written in CUDA for commercial applications on Windows. Before I distribute the code (as a dll) I would like to verify that it is somewhat protected (I realize that everything can reverse engineered …). I run IDA pro on the dll it self and was surprised to find all of the CUDA file-names in the strings list (that doesn’t happen with regular CPU code).

Is there a way to obscure/remove the strings related to CUDA (I know on Linux it’s possible to use the strip command but on Windows it’s a different story).


So the goal is “security through obscurity”?

I understand that securing a code is an endless chase. My goal is to prevent the code from being completely exposed. Any advise?

(1) Rename the files in final release trees. Decades ago, I used this to obfuscate the source file names embedded in executables, for a project comprising about 50 modules. You would want to automate the renaming of the files along with an any source file and makefile references. I think I used a Perl script for that.

(2) If, beyond that, you are concerned about symbol names leaking (other than for entry points obviously), apply a source code obfuscator to the final release tree. I considered this but didn’t follow through.

Ok, I wrote a script that does exactly that. Looking into the strings section with more attention (now that the major functions are out of the way) I see that all the variables are also visible in the strings section (!). It seems that I need a complete obfuscation to handle that but I’m worried about the performence of the kernels.

This behavior is a standard CUDA behavior? This makes reverse engineering much easier compare to CPU code.

Apparently I was looking at the dll in debug mode, In release mode after the simple obfuscation much more details are hidden. For now I think it will do. Thanks for the help!

I think your observations are mostly due to the behavior of Microsoft’s tool chain rather than anything that CUDA does. Clearly debug builds will be “symbol rich” for obvious reasons.