The malicious code was written and debugged at their convenience and saved as an object module linker file that had been stripped of debugger symbols (this is one of its features that made Fruend suspicious enough to keep digging when he profiled his backdoored ssh looking for that 500ms delay: there were no symbols to attribute the cpu cycles to).

It was then further obfuscated by being chopped up and placed into a pure binary file that was ostensibly included in the tarballs for the xz library build process to use as a test case file during its build process. The file was supposedly an example of a bad compressed file.

This “test” file was placed in the .gitignore seen in the repo so the file’s abscense there was explained. Being included as a binary test file means that the malicious code isn’t in the code on github. Its nowhere to be viewed.

The build process then creates some highly obfuscated bash scripts on the fly during compilation which were executed to reassemble the object module, basically replacing the code that you would see in the repo.

Thats a simplified version of why there’s no code to see, and that’s just one aspect of this thing. It’s sneaky.