I find it frustrating that the Mach guys have this great write up, but don't just say what the "signing" is.
Anyone paying attention in the article to that point knew it had to be some basic hash or similar, where even in your worst case someone has to reverse engineer some assembly.
After all that effort, just out Microsoft, particularly when we're talking about opensource code that anyone that cares to can just dig through and find (thanks for that, msk!).
> I find it frustrating that the Mach guys have this great write up, but don't just say what the "signing" is.
I think it's for plausible deniability in case M$ ever comes after them for RE reasons. They probably want to be able to say that they didn't use the proprietary blob in order to implement their own code signing.
If that is indeed the reason, I won't blame them. I wouldn't want to upset Microsoft either. If they decide to come after you with an army of lawyers, it doesn't necessarily matter if what you did was legal. And I think it probably was legal in most jurisdictions. Reverse engineering for purposes of interoperability is generally allowed. Of course they could still try to get you on copyright if you didn't do a clean room re-implementation.
Yeah. It's easy to say you got it from some other open-source project that did their own clean-room reimplementation, unless there's clear evidence on your very own website that you looked at their proprietary code anyway, which would allow them to make the case that your knowledge was tainted and your implementation couldn't have possibly been clean-room.
But copyright doesn't care about "tainted", it cares about whether there's substantial similarity between the two works. Copying only the system/mechanism but not the exact code is legal, even if you admit you used the actual decompiled code as a direct guide.
Just for my own understanding, why was it obvious that it has to be a basic hash? At least it wasn't obvious to me, but I have very little experience in this area.
This is the part of HN I really like. People who can look at random C code working with memory and be like "yep this looks like modified X". Pretty amazing (to someone like me who mostly works in high level languages).
With the phrasing of the article, I immediately thought it must have been something simple/dumb. I quickly thought MD5 so I looked at the magic numbers in the C code and looked them up on wikipedia. Then I noticed the four F G H I functions. Still I’m not sure it is (maybe it’s something common in hashes?) and I still don’t know what the change is
"dxil.dll is closed-source, so we cannot simply patch it in the same way. To fix
this, we outright disable runtime loading of dxil.dll and silence warnings related
to it not being present / the final binary not being code signed. Instead, once
the compiler would emit a compiled shader blob, we perform our own code signing
algorithm (Mach Siegbert Vogt DXCSA) which results in a bitwise identical compiled
shader, and thus dxil.dll is no longer needed to perform code signing of shaders."
That "signing" has always been bullshit security theater. You'll note that every other graphics API manages just fine without it. I'm glad somebody posted the "signing" algorithm out in the open.
Putting a pseudo-MD5 hash in your file header sounds like someone got confused and wound up caught between over-elaborate integrity check and half-hearted security measure.
It sort of works if your signing tool is part of a private console SDK, but the DirectX SDK was always freely available.
1: https://github.com/hexops/DirectXShaderCompiler/blob/4190bb0...