2

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?

Nicol Bolas
  • 449,505
  • 63
  • 781
  • 982
plátano plomo
  • 1,672
  • 1
  • 18
  • 26

3 Answers3

5

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.

Nicol Bolas
  • 449,505
  • 63
  • 781
  • 982
3

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.

ratchet freak
  • 47,288
  • 5
  • 68
  • 106
1

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.
Alex Byrth
  • 1,328
  • 18
  • 23
  • 3
    code encryption is not going to work, the vulkan's layer system lets the user grab the actual spir-V code that the application sends to the driver which needs to be valid spir-V (unless an extension says otherwise) – ratchet freak Sep 02 '16 at 16:22
  • 2
    Agreed. Code encryption may protected the spir codes on disk, as a resource fille, but not if someone intercepts it between application and driver, like debuggers do. – Alex Byrth Sep 02 '16 at 17:08
  • 3
    @ratchetfreak: You don't even need layers for that. A good old fashioned DLL injection / API hook would give you all the information you ever wanted. Anyone who is determined enough to reverse engineer SPIR-V bytecode could easily create such a hook, with or without an API designed with this in mind ;) – Andon M. Coleman Sep 03 '16 at 03:08