I will post the solution here in one month if nobody figures it out.
It could be that a constant has been added to all characters
#QBdg%HGILH&R9vch)NBTAt5.X3oWb\BxMbn5,GR0wTQ*0xuHBc=
Looks like any other NOTAM to me.
Funny thing how we are all thinking in the same direction. I looked at the hexdump as well, then at base64 (obviously wrong) and uudecode (fits at least the character set). It’s also not xface and doesn’t look like Ceasar cipher. What I noticed: There are always four to six alphanumeric characters enclosed by a special character.
If this is made up by Dimme the number of possibilities is huge.
The base64 assumption is not wrong.
The thing you noticed is also useful.
The special char may be a space but its value changes each time, so if it is an encoding for a space it is not trivial.
23 25 26 29 2E 5C etc
What message format is delimited by # = might be worth a look.
Base 64 and the other encodings for binary data all expand the number of bytes so you don’t get a 1:1 relationship, so to have any chance of working it out, the encoding scheme needs to be established first.
That’s not how base64 works, look it up. No it’s not a space.
42
Base64 decodes to basically garbage, which could be anything
base64 copies 6 bits of the input data into one byte and then translates this byte into the printable ASCII range. The first part is what Peter meant. It obfuscates any regularities so the pattern of special characters wouldn’t make sense.
The mapping table of base64 also does not fit because most of the special characters aren’t used in base64. Also not in base85.
