Decoding algorithm(s) for encoded disk sectors (ADOS)

[andreas]

Yeah coders, I'm a bit stuck in this...

You know SADDAM virus, which finds it very entertaining to occasionally replace the $00000008 long word by 'IRAK' at the beginning of a block, and then EOR (or like some other virus: EORI-)encode the rest of the block.

I wouldn't need to open this thread, if my assembly knowledge was good enough - but unfortunately I feel more at home in high-level languages

Mr. Schneegold's fantastic 'VT-knows' file (which, by the way, has meanwhile spawned some wiki-like sites on the net, but you can still see it's HIS work!) tells about the algorithm used, but all this register stuff is Greek to me:

The following snippet was taken from an infected Colossus Chess disk ($6FE000 ff.; 0x4952414b = 'IRAK')

49 52 41 4B  00 06 FD 7D  00 06 FE 01  00 06 FF E8

00 06 FC FD  5C 1E 74 E6  AC 35 01 FE  00 06 DE 2D

19 05 FC 00  06 07 C9 4B  03 00 FE D8  00 30 B4 01

05 06 FA 00  3F 54 FF EE  00 FD FE 36  2D 04 14 00

Schneegold explains the algorithm, but in assembly:

eor.b d0,(a0)+
subq.l #2,d0
dbra d1,loop

Can anyone "translate" me this gobbledigook into C speak please?
Id Est: what do I have to do to decode this block?!

[a4k-oerx]

Not exactly an answer about the algo, but if you try to find "SIEGFRIED Antivirus Professional" somewhere, it contains an "IRAK-Recover" module...

[Kalms]

Literal asm-to-C translation of that code:

int d0 = ???;
int d1 = ???;
int offset = ???;
char* buffer = ???;
do
{
    buffer[offset++] ^= d0;
    d0 -= 2;
} while (--d1 >= 0)

So you need to figure out which portion of the bootblock is to be decrypted, and what the starting value in d0 should be.

[andreas]

Originally Posted by Kalms

So you need to figure out which portion of the bootblock is to be decrypted, and what the starting value in d0 should be.

Thanks Kalms!!
First of all, this is NOT a boot block but a DATA block, where the T_DATA identification long word has been overwritten by the virus with its 'IRAK' signature.

At any rate: I have my doubts that tools which can decode these blocks can wildly test through all starting values there are?
Maybe the 'IRAK' word *is* the starting value already?!

Well, I'll have to try it out.

Thanks so far.
Only problem I can see is finding out how to get the value for d1?!

Originally Posted by a4k-oerx

Not exactly an answer about the algo

Why did you post then?
If I wanted a tool to decode these blocks, I'd have picked "Apps req", not this programmer's corner.
I need the 'HOW', the technique - that's why I'm here.

[Kalms]

Originally Posted by andreas

First of all, this is NOT a boot block but a DATA block, where the T_DATA identification long word has been overwritten by the virus with its 'IRAK' signature.

Originally Posted by andreas

Only problem I can see is finding out how to get the value for d1?!

Well, from what you said before:

You know SADDAM virus, which finds it very entertaining to occasionally replace the $00000008 long word by 'IRAK' at the beginning of a block, and then EOR (or like some other virus: EORI-)encode the rest of the block.

-- that sounds like: skip over the first 4 bytes (there you have the "IRAK" marker) and then run the loop over the remaining bytes in the block.

So the problem then is how to find the starting value for d0. It might either be a constant (0 .. 255), the same for each block on the disk, or the starting value is generated in some fashion. (perhaps from the block number)

One way to find this out is to create a blank disk, get it infected, and make it encrypt a bunch of blocks. Then you know that the payload part of each block was originally all zeroes, so you should see a pattern like FE FC FA F8 F4 F6 F2 F0 EE ... etc there, and then it may become evident how the starting value is calculated for each block.

[andreas]

Originally Posted by Kalms

One way to find this out is to create a blank disk, get it infected, and make it encrypt a bunch of blocks.

Pointless, since the virus is clever: it will ONLY infect DATA blocks and sometimes file headers! So if there is no file at all on the disk: no infection! (ok except for the bogus disk validator, but it's questionable whether this is relevant in this case)
OK, FWIW, I've done a hardcopy from my disk editor with the virus-encoded block on the upper half, and the decoded clean block on the lower. I hope this rings some bells now...

To fit on the algorithm found on the info-file, the values seem to diverge too much IMHO...

HOWEVER, it really pops into the eye that the MSB and LSB of every long word is untouched!!
So the virus does not encode *every* byte. (at least it seems so)

[mosfet]

All of the encrypted longs in that block are simply XORed with $0078c00 (which is why the first and last bytes are unaffected).

There were many variants of Saddam, are you sure you're looking at a description of the same one that's infected your sample block? This one just seems to be using a straight XOR.

The infected disk-validator is relevant, because that's where the decryption key will be stored (when Saddam is memory-resident, it decrypts infected data on request, so the data still looks valid on an infected system). The different Saddam variants each had slightly altered decryption schemes to confuse virus checkers, so there's no way of decrypting just looking at a single block - you have to examine disk-validator.

So in other words: the "decoding algorithm" you posted is the algorithm used by one variant of Saddam to decode its own infected data, and the running virus already has the key needed to perform the decryption - it's not an algorithm that you can use to decrypt infected blocks (unless you know which particular encryption scheme has been used, and have retrieved the encryption key from disk-validator).

[andreas]

Ah, thanks so much mosfet!!

Yes, I think I understand.

Yet it seems we can do without the disk validator (at least here, that is)!

Your XOR hint led me on the right path.
It's SO SIMPLE!

After checking 5 infected disks, I'm pretty sure: only FIRST DATA blocks get infected with IRAK!
SADDAM looks at the first entry in the file header and infects the block where it points to, so it's even more simple than I thought:

- First data blocks must have sequence number 0x00000001.
- So seemingly I just need to subtract 1 from the encoded 3rd long word (#2) and I have the long word for decryption right there; thus the only thing left to do is merely XOR'ing the remaining long words with the long word I found!!!
(- And if I want to be on the safe shore, I could XOR the encoded file header ptr with the decoding long word and check whether the first data block pointer in the file header block [77th long word; #76] is identical to the current block number! Coolish!)

Caveat though: It must be proved whether all the SADDAM variants can be handled the same way. This can only be achieved by trial and error: write decoded disk image, and recheck for errors. Heh, at least I'll be busy for the next days then!

[mosfet]

Yes, that will work

Even if it infects random blocks and the header is trashed, this gives a brute-force method for finding the key: if you have some infected blocks but don't know the sequence-numbers, you can try each of the few thousand valid sequence-numbers, work out which xor-key matches that sequence-number, decode the block then see if the block checksum is valid. A lot easier than trying all 4 billion possible 32-bit numbers...

[thomas]

- So seemingly I just need to subtract 1 from the encoded 3rd long word (#2) and I have the long word for decryption right there

You should XOR with 1 rather than substract. Imagine an encryption key of 0x23456789. The encrypted 0x00000001 is 0x23456788. If you substract 1 you get 0x23456787 which is not correct.

[andreas]

Point taken, thanks.