"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):
>>
>> > 
Object="@Filesystem[65ba0377-31a7-52e4-8e5b-5415b3a73f12]/Downloads/EICARAntiVi
rusTestFile.com"
>>  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.


--- NewsGate v1.0 gamma 2