Skip navigation.
Home

New Storm Strand Encryption key??

|

I've downloaded and analyzed the last strand of the storm worm and as many of you know, the p2p payload it's encrypted now.

I'm mostly interested in its network behavior, so has anyone of you found what the encryption key is? I would really appreciate this information or a link to some article that talks about it.

In case nobody knows: how would you proceed to find the key in the disassembled code? Any ideas on the techniques/tools to be used?

Thx

encryption

"(..) the p2p payload it's encrypted now."

Not just now, it already was.

There 's not much detailled information available about the encryption, used by Storm, but maybe following links can help you further:

According to Dancho Danchev 's blog it is a typical MPack style XOR-ifying javascript obfuscation.

Joe Stewart, from Secureworks.com wrote in october 2007 "they use a 40-byte key to encrypt their Overnet P2P traffic. This means that each node will only be able to communicate with nodes that use the same key."

Also Lisa Vaas (security.ithub.com), wrote an article about the 40-byte encryption on traffic running with the Overnet peer-to-peer protocol.

If you're mostly interested in the network-behaviour, I recommend you to contact this guy. He is analyzing the Storm-trojan since last christmas and is still working on it.

I hope this links can help you.

Chato Flores

storm key

The key referred to in that blog post is for something else.

The key you are asking for is the one they are "encrypting" all UDP/overnet packets with. The encryption function is nothing more than an XOR with a 40-byte key.

for(x=0 to packetsize)
enc_packet[x] = packet[x] ^ (key[x] % 40)

You can find it in the binary itself using memory analysis techniques or through statistical analysis.

One of the Encryption keys

The key for samples, 7142c19d72816003af1f02648470a3f0 and 7b509c4ca97fd0373390f1cc76c483a8, is:

f3 aa 58 0e 78 de 9b 37 15 74 2c 8f b3 41 c5 50 33 7a 63 3d e6 13 df 6c 46 ca be 9a 77 48 94 02 c0 f3 66 49 ee 87 21 bb 9b

It's located 0x18744 bytes (That's ".data:00028744") into "7142c19d72816003af1f02648470a3f0/WINNT/system32/clean79e4-2488.sys"

Since there are nine whole bytes of known plaintext in every UDP packet this thing spits out, it took me less than five minutes with a pen and paper to crack. I'll write up the details if anyone is interested.

These other Storm/Peed samples are NOT using any encryption:

15362ba7c244b409e18b0ed2fa9dcbfd
43650f4b6d2d124b0c2f48e308b20e52
6b9721d5bde2b987b593f6306d6b049c
94af7e370156298525bcb3e8b3830c5e
e8a0b134e8be2fb175c0efd00ee05d66
f58f8e1941f1d152e7a73ed38edca3e1
f792130e8a61593188782dee1d12d187
fe606f76fa6a0723ab8a93fabea28ab1

I don't have data on any other Storm/Peed Bot/Worm samples currently. Point me to any others you want the key for.

-- 
X5O!P%@AP[4\PZX54(P^)7CC)7}$EICAR-STANDARD-ANTIVIRUS-TEST-FILE!$H+H*

Key

Thx! I had found the key eventually and to the best of my knowledge it is the only one around at the moment.

As you did, I cryptoanalysed (XORing the known parts of the packets) some bytes of the key but after i just googled them! sic!

Anyway your approach seems very clever and easy. But what if next time the key is not stored in one contiguous buffer of data? But spread, scrambled and reconstructed at run time? Some serious reverse engineering must be done in that case.
What do you think?

Thx again!

Set some on-access hardware

Set some on-access hardware breakpoints on the to-be encrypted buffer. Also, set breakpoints on the functions used to send the encrypted buffer. (ws2_32!send, perhaps :o)). You will most likely wind up in a loop that accesses the source data. After walking through the loop a few times, you should see the plaintext data being extracted a byte/word/dword at a time, the encryption key extracted, a math operation like XOR between those two pieces, the result written to a buffer, and lastly pointer increments to move on to the next piece of data.

If you're lucky, they'll end up writing the encrypted data back to the same buffer as the original plaintext data. If you can't find the loop due to too many read breakpoints firing, try to determine where the buffer that is passed to send() is allocated. Once you find that, you can set break on the allocation function, then break on writes to that buffer which should put you in the encryption loop or something like memcpy().

A slightly faster method

The first two bytes of the XOR key are really easy to find. Then just take a snapshot of memory and search for it. It stands out quite nicely. Besides, storm does debugger checks in all the versions I've tried it one.

Perl Xor decrypter for Storm Udp packets

Hi everybody,

i've written a small perl script to decrypt the payload of the messages exchanged by Storm Worm peers.
What it does is a simple XOR.
The script takes a dump in pcap format and decrypts the eDonkey fields writing the output on a new pcap dump file.
It doesn't recalculate the Udp checksum, so you are going to have wrong checksum alerts.

I hope it can be useful.

This link is going to be available for one week:
http://senduit.com/1193b8

After that don't hesitate to write to me at:

dan (d0t) perito (4t) gmail (d0t) com

Sample of p2p strom worm

i am looking for a p2p strom worm for research purpose .So Could you please inform me where to get a sample binary of strom worm?

Kind Regards