This is my understanding of whats going on.

Hello! I'm the author of the article and I actually did look into that. I used windbg and stepped through the process of windows booting up to the point of expecting a password. I also looked at what happens when you trigger bitlocker in a way where it requests a recovery key.

I really only did this so I could verify when/whereish the key ends up in memory, so I didn't follow along every single step of the way. I can tell you that SymCrypt succeeds in zeroing out the key multiple times in several places. Thats why I was shocked to find the key left over completely intact in ExAllocatePool allocations, but what I'm guessing is that Microsoft is not accounting for every possible place the key can end up when they're destroying secrets.

Based on previous attacks like this I suspect that Microsoft also employs some "security through obscurity" tactics when they modify BitLocker. What I mean by that is I think there is a lot of just moving the key around so its a little harder to find...

Nice. This might be eligible for a bug bounty for you (if you want to deal with it). I think it’s not by design.

Hello everybody, I'm the author of the article. If you have any questions, please feel free to message me on this account. I had a lot of fun working on this and I really appreciate all of the engagement.

This is an excellent write-up. It's short and to the point, with links right where I would want them.

Thank you so much for your compliment, and for reading it. I tried to make it as thorough and informative as possible.

Hey I'm the author. I did this on DDR4 RAM. Specifically, it was F4-3600C18D-32GVK in two slots and MD16GK2D4320016AXR in the other two.