-2

I am new to decoding techniques and have just learnt about base64, sha-1, md5 and a few others yesterday.

I have been trying to figure out what "orkut" worms actually contain.

I was attacked by many orkut spammers and hackers in the past few days, and there is a similarity in the URLs that they send to us.

I don't know what information it contains but I need to figure it out.

The problem lies in the following texts:

Foo+bZGMiDsstRKVgpjhlfxMVpM=
lmKpr4+L6caaXii9iokloJ1A4xQ=

The encoding above appears to be base64 but it is not, because whenever I try to decode it using online base64 decoders, I get raw output and it doesn't decode accurately.

Maybe some other code has been mixed with base64.

Can anyone please help me to decode it?

Enamul Hassan
  • 5,266
  • 23
  • 39
  • 56
N-J
  • 25
  • 1
  • 3

5 Answers5

3

It's part of an orkut worm. This page has some details. Notice it mentions the JSHDF["Page.signature.raw"] variable you're finding these strings in.

It's a SHA1-hash of the page it was found on. This page shows the decoded form of it.

geocar
  • 9,085
  • 1
  • 29
  • 37
2

The encoding above appears to be base64 but it is not, because when-ever I try to decode it using online base64 decoders I get raw output and it doesn't decode accurately.

What makes you think that the decoding is incorrect? Typically you'd base64 or hex encode binary content so that it can be transported as text. You wouldn't base64 encode text so it isn't surprising that decoding the strings you've provided above results in ASCII gobbledygook.

user38051
  • 393
  • 1
  • 5
1

Haha, if it was that easy, it would not be worth a hack! You have to try a lot harder than just simply decoding it once.

leppie
  • 115,091
  • 17
  • 196
  • 297
1

They could be merely hashes.

If they are hashes, "reversing" them is algorithmically impossible if the original content is over a certian size, because after a certain source data size, hashing becomes a lossy compression function.

Eimantas
  • 48,927
  • 17
  • 132
  • 168
Kent Fredric
  • 56,416
  • 14
  • 107
  • 150
0

Often times Foo+whatever is the result of a salted hash. It is common to store hash results with salt, and the salt can be stored in the clear. To separate the salt from the actual hash value, a + sign is commonly used.

Base64 is used, so that the binary result of the hash can be stored in text. You can tell that the last part of those strings might be valid Base64 because Base64 content will always be a multiple of 4. It outputs 4 valid ASCII characters for every 3 bytes of input. It pads the end with "=" signs.

So, for Foo+bZGMiDsstRKVgpjhlfxMVpM=, this may be the result of taking some input, be it a message of some sort, or whatever, and applying the salt "Foo", and then hashing the result. The string value bZGMiDsstRKVgpjhlfxMVpM= likely is the binary result of some hash function. An online Base64 decoder shows that the value, in Hex, instead of Base64, is { 6D 91 8C 88 3B 2C B5 12 95 82 98 E1 95 FC 4C 56 93 }. Yes, this is not ASCII text.

Base64, binary, hexadecimal, decimal, are all ways of representing values. Think of the part after the + as just a number. The above 136-bit number may be the result of a 128-bit hash, and an 8-bit CRC, for example. Who knows? I don't know why you're getting spammed, or why these spam messages have these strings attached to them, but this may be some insight into the nature of the structure of the strings.

maxwellb
  • 13,366
  • 2
  • 25
  • 35