Does SPIR-V bytecode provide obfuscation?

Question

It is straightforward for a reverse engineer to attach a graphics debugger to an OpenGL application to extract the shader source code. It is my understanding that Vulkan, on the other hand, uses SPIR-V bytecode, rather than passing plaintext shaders to the graphics API.

Does SPIR-V bytecode obfuscate the shader source, or is it fairly easy to decompile?

Answer 1

There is an entire specification explaining, in explicit detail, the behavior of each and every SPIR-V opcode. That's kinda the opposite of obfuscation. But there's more to it than that.

SPIR-V, despite being "assembly", retains a rich amount of information about the source program. It contains structure definitions, function definitions with parameter and return types, looping and conditional constructs, etc. Writing a decompiler for SPIR-V is not at all difficult.

SPIR-V also can optionally contain fragments of text that annotate various SPIR-V definitions. This is more of a function of the environment that compiled to SPIR-V, but the output SPIR-V can contain variable names, structure names, and etc. These OpName decorations can all be easily culled if you wish.

But even without names, all of the important structural information is there. So the security gains from SPIR-V compared to raw GLSL is rather minimal.

Answer 2

It doesn't do any real obfuscation. The only thing it could really do is strip the variable names.

If the application is not willing to complicate the actual calculation then that's about it.

It cannot do much with control flow because vulkan requires structured control flow. Where each conditional branch must have a merge block and every loop has a strict structure.

Answer 3

SPIR opcodes behaves like bytecodes in Java:

• it creates a neutral meta-operators, the opcodes, closer of machine raw codes, to easy Spir driver translation to raw GPU code.
• as advantage, the opcodes avoids the distribution of plain source codes, and the compiled spir opcodes should have compile issues, as typo or syntax errors - it is already compiled;
• a disadvantage is the reversibility of binary representation to plain source code again.

There is no easy workaround to the reversibility of opcodes to plain code. Some solutions used in Java field are:

• obfuscation - like ProGuard does for Java's bytecode - not sure if this is possible with SPIR;
• code encryption with symmetric key - the key is hardcoded in your C code.
• code encryption with asymmetric keys - private key comes from web, after login to server.