"Paul" wrote:
Apd wrote:
"Paul" wrote:
This smells funny...

CF CF CF CF CF CF CF CF CF CF CF CF

It smells like spaces!

XOR the base64 with 0xEF and you have plain text with a single
linefeed terminating each line. It's an XML report. Here's a line from
your second example, krdeicar.txt (wrapped for ease of reading):

Event1 Action="Detect" Time="132042218823887019"
"
Info="EICAR-Test-File" /

Yup. Even when the problem switched from "encryption"
to "encoding", I still couldn't see it. And I've had
trouble spotting XOR() related patterns before too.
It's a disease.

Often when you see the high bit set in every byte in data which has a
pattern is a clue that there is XOR present. A simple guess as to what
might be a character sequence, like the spaces in this example, gives
you the key.

I tried to implement the function in gawk, but the conversion
from substr() to number insisted on doing the wrong thing when the
msb of a character is set. So I had to punt and use C instead.
For which, somebody already wrote our program for us. Just change
the XORBYTE constant, and it's ready to compile.

My own code is much the same but I also pass the XOR constant as
a command line argument. I pass it as a variable (even) length hex
string since sometimes more than one byte is used in the key. The code
is a little more involved in checking for valid hex, etc.