It may also be that you're rotating by 0x8000 and this code is not. It's creating a mapping that's restricted to non-control, non-surrogate, non-whitespace characters and rotating by half the size of that mapping.
https://github.com/rottytooth/rot8000/blob/master/Rottytooth...
This will break, i.e. two consecutive rotations will no longer be the identity, if the number of valid characters in the BMP ever becomes odd. And there are still a few unallocated code points in the BMP. There is also an overflow in line 39 because of the check i <= BMP_SIZE in line 37 which, I guess, previously used Char.MaxValue instead of BMP_SIZE. But it does no harm here, U+0000 just gets filtered out twice.
There's a test for BMP characters being even: https://github.com/rottytooth/rot8000/blob/master/Rottytooth...
More critically, if the # of valid chars changes, previously rot-8000'd text will no longer be reversible through the tool
Re:Rot8000
by hyper_reality on Tuesday November 20, 2018 @02:07PM
(#18496683)
I also had a similar idea a few years ago for a CTF challenge, coming at it from a "modern Caesar cipher" perspective: https://laurencetennant.com/unicode-shift-cipher
Also a crude "modern Bacon cipher" using Punycode characters as the B's and ASCII-range characters as the A's.
It comes with presets for various different areas of Unicode, and some example text, although the intended use case was very different, I looked at it from a steganography perspective rather than an honours-system obfuscation perspective.
https://incoherency.co.uk/mojibake/
I initially thought it would be able to decode the rot8000 output without any modification but I think the utf-8 escaping that my tool expects (from its own output) gets confused by the output from rot8000.