the xor key is an output of an lsfr most of the cases, with params chosen so that it has large period.
It would be nice to write code to find out parameters of the lsfr for an actual pattern, then we could generate it without the need of recovering the whole pattern from the target device, probably a small part would be sufficient...

Would it make sense to use the LBA as the seed? Then you wouldn't need to store it.

Wouldn't that result in different XOR for each LBA?

I was addressing "okton's" point about unique seeds for each LBA. I have no idea whether this is really the case, or why it would be necessary.

BTW, a hardware implementation of LSFR is surprisingly trivial. For a 16-bit implementation, you just need a 16-bit shift register (4 x 4-bit) plus a quad XOR gate.

https://en.wikipedia.org/wiki/LSFR

https://upload.wikimedia.org/wikipedia/commons/a/a8/31_bit_Fibonacci_linear_feedback_shift_register.webm

Maybe I should have avoided that word, but if we XOR block of zeros with XOR key or block, do we not increase entropy? AIUI storing very similar data close is more prone to corruption and to avoid this XOR is applied to introduce noise and avoid worst case patterns. I assumed this increase in noise leve translates to high Shannon entropy. But I am no expert on the matter, it's what I read everywhere (NAND Flash Data Recovery Cook Book and other places / documents). If we look at typical XOR-ed block of repeating bytes in VNR we see



Which seems to me higher entropy data than a repeating pattern. If the same is already accomplished by some form of encryption XOR scrambling seems like an un-needed extra step. So maybe reasoning is, encryption gives us required noise AND we can position/market encryption as a feature. I do not know, I am simply guessing, thinking out loud.