Cenzic 232 Patent
Paid Advertising
sla.ckers.org is
ha.ckers sla.cking
Sla.ckers.org
Whether this is about ha.ckers.org, sla.ckers.org or some other project you are interested in or want to talk about, throw it in here to get feedback. 
Go to Topic: PreviousNext
Go to: Forum ListMessage ListNew TopicSearchLog In
An encryption algorithm
Posted by: ZX
Date: September 04, 2007 10:09AM

Hello there,
Im not sure this is the right section, but feel free to move the topic.

The thing is, I came across an algorithm and it appears to be a custom. Since I have nothing better to do I've decided to try figure it out, but with no success.

Here are the strings and the result after the encryption:
123 = 278F98
1235 = 278F98E3
1234567890 = 278F98DBD882B5F084A8
qwerty = 5F065405015A
* result is in hex

Looking at the first three it seemed, well, easy, but.... you know...
Hope someone could help me.

Cheers and thank in advance.

Options: ReplyQuote
Re: An encryption algorithm
Posted by: Anonymous User
Date: September 04, 2007 11:01AM

Looks like some sort of custom Railfence Cipher =>http://www.math.temple.edu/~renault/cryptology/railfence.html

Most custom ciphers are based on very simple ones that involve xoring bytes.

Options: ReplyQuote
Re: An encryption algorithm
Posted by: thornmaker
Date: September 04, 2007 04:25PM

55555555555555555 = ?
0123 = ?
321 = ?

Options: ReplyQuote
Re: An encryption algorithm
Posted by: Gareth Heyes
Date: September 04, 2007 08:40PM

I suggest using the photoshop colour picker. That should "decrypt" it lol.

Options: ReplyQuote
Re: An encryption algorithm
Posted by: ZX
Date: September 05, 2007 04:01AM

55555555555555555 = 4F35F7F3C94A1AF7CE4A2C94691FDEE8F224
0123 = 6B9A4899
321 = E18D5C

Options: ReplyQuote
Re: An encryption algorithm
Posted by: auron
Date: September 13, 2007 06:49AM

Right now, the only thing I can see from the codes is that probably there's a linear dipendence from the previous char. This means:

c_n = f(m_n,n)+m_(n-1) mod(256)

c_n = n char of the crypted string
m_n = n char of the message string

that's because 8f-8d = 2 = 3-1 , and we can see that the coding function has not dipendences from the next char cause in 123 and 1235 the first 3 chars are the same.
for a deeper investigation, i think it would be required much time...

Options: ReplyQuote
Re: An encryption algorithm
Posted by: ZX
Date: September 26, 2007 03:15PM

That is the reason I thought it could be reversed without the actual encrypting function, but I've ran out of ideas.

Options: ReplyQuote
Re: An encryption algorithm
Posted by: rsnake
Date: September 27, 2007 10:44AM

id had a good idea, and I ended up building a quick test to see if I could find out for you but alas, it was none of the usual suspects (I haven't built salting into my program):

$ perl hashmasher.pl
Missing vars!
Needs to be in the format hashmaster.pl <password> <hash>

Goodbye.
$ perl hashmasher.pl 55555555555555555 4F35F7F3C94A1AF7CE4A2C94691FDEE8F224
Welcome to the hashmaster! Written by RSnake (http://ha.ckers.org/)
Trying MD2... Nope!
Trying MD4... Nope!
Trying MD5... Nope!
Trying SHA1... Nope!
Trying SHA224... Nope!
Trying SHA256... Nope!
Trying SHA384... Nope!
Trying SHA512... Nope!
Trying CRC... Nope!

Done (none found, sorry).

My test included the following: md2 md2_hex md2_base64 md4 md4_hex md4_base64 md5 md5_hex md5_base64 sha1 sha1_hex sha1_base64 sha224 sha224_hex sha224_base64 hmac_sha256_hex sha256_hex sha256_base64 sha384 sha384_hex sha384_base64 sha512 sha 512_hex sha512_base64 crc32 crc16 crcccitt crc crc8

So either it's using a salt (you can probably verify that by typing the same password over and over again and see if it comes out at something different) or it's using something other than one of the usual suspects.

- RSnake
Gotta love it. http://ha.ckers.org



Edited 2 time(s). Last edit at 09/27/2007 10:46AM by rsnake.

Options: ReplyQuote
Re: An encryption algorithm
Posted by: Anonymous User
Date: September 27, 2007 12:05PM

You can rule all those out RSnake,
since all hashing algorithm have fixed length.
The first post shows presumely a custom XORing cypher, c.q. transposition because the length varies on entered data.

To be conculsive he just has to generate multiple strings and try to see the XOR pattern, then it could use a salt/key and then you'll you know where the salt or key returns only if you generate multiple strings and compare where XORing returns. You could solve it in the end since it is highly likely that XORing / transposition is used.

Like:
H . . . O . . . C . . . S
. E . L . S . A . K . R . 
. . L . . . L . . . E . .

The only way to know it isn't an encryption algorithm or block cypher like AES, is to watch if every input generates a different result, then you are probably screwed. If it stays the same you will have more luck. What also can be used is to try exotic chars, beyond the [0-9][a-z] since most XORing cyphers don't use them, or are padding them.

My best bet until now is that it looks like a RC4 cipher since it generates a different cyphertext length each time:
http://en.wikipedia.org/wiki/RC4

Anyway, goodluck.

Options: ReplyQuote
Re: An encryption algorithm
Posted by: DanielG
Date: September 29, 2007 02:11PM

I too have had troubles with finding the hash algorithm used for a password stored in a cookie.
I've been trying to see if they used part of a hash because I couldn't find alot of hash algorithms which produce this particular output length (8byte).

I was wondering if hashmasher also checks if the <hash> provided is only a part of a known hash algorithm.

These are examples of the hash:

aaaa = DE78DA47D9BAAAC6
aaab = 40676C887DEFCEBA
baaa = E3D3B1E3E6BF6464
test = EDD2A1D1B747B0BD
aaaaa = 039C3D6F2B6C8F81
soho123 = 7B90FCED97DF5011

Maybe instead of just showing "Nope!" you could display the calculated hash for the <password> string.

--
Yeah i'm Dutch, sweeeeeeeeeeet.

Options: ReplyQuote
Re: An encryption algorithm
Posted by: rsnake
Date: September 29, 2007 02:49PM

Btw, I expanded and released my program in case anyone else has this problem. Granted, it was unable to solve your problem, but maybe in future revisions it may be able to: http://ha.ckers.org/blog/20070929/detecting-hashing-algorithms/

- RSnake
Gotta love it. http://ha.ckers.org

Options: ReplyQuote
Re: An encryption algorithm
Posted by: Ghozt
Date: September 29, 2007 05:42PM

Just so I don't have to start a new thread, does anyone know of an algorithm that's 40 characters long? I ran it through hashmaster and it didn't come up with anything.

TestPassword - 52BF31F50EABC35D14D1D91D3DC7D0B8BB955971

- Ghozt

Options: ReplyQuote
Re: An encryption algorithm
Posted by: Spyware
Date: September 29, 2007 05:53PM

Sha-1 is 40 chars long: http://en.wikipedia.org/wiki/SHA_hash_functions#SHA-1_hashes

Options: ReplyQuote
Re: An encryption algorithm
Posted by: id
Date: September 29, 2007 06:24PM

sha1 of TestPassword is db97dde4c15810646b3ac15fcc1b8a25dc4c7fcb

any *NIX box should have md5 and at least sha1 installed, easy to test.

-id

Options: ReplyQuote
Re: An encryption algorithm
Posted by: Mordred
Date: October 07, 2007 04:30PM

ZX Wrote:
-------------------------------------------------------
> 123 = 278F98
> 1235 = 278F98E3
> 1234567890 = 278F98DBD882B5F084A8

From this I can guess it should be trivial to break any such encrypted string with a known plaintext attack, if you have a reliable way of doing it. Sometimes knowing the actual algorythm is not needed ;)

Options: ReplyQuote
Re: An encryption algorithm
Posted by: id
Date: October 07, 2007 08:19PM

btw, I take that back, I had a new line on that.

SHA1 ("TestPassword") = 6250625b226df62870ae23af8d3fac0760d71588

-id

Options: ReplyQuote
Re: An encryption algorithm
Posted by: buherator
Date: November 27, 2007 09:29AM

123 = 278F98
1235 = 278F98E3
1234567890 = 278F98DBD882B5F084A8
qwerty = 5F065405015A

You simply can create a table like this to decode anything you want:
\|pos.1|pos2|...
1|27 |? |...
2|? |8F |...
.
.
.

Options: ReplyQuote
Re: An encryption algorithm
Posted by: thornmaker
Date: November 28, 2007 01:24AM

123 = 278F98
1235 = 278F98E3
321 = E18D5C

Note the 2 in the 2nd position does not get encrypted the same on the third line. So a table like you are suggesting does not work in this case. It appears that the preceding characters affect how each character is hashed but not any of the subsequent characters.

[Edit:] I do find it curious that 2 maps to 8F on the first two lines (when preceded by a 1) and 2 maps to 8D on the third line (when preceded by a 3). Perhaps 22 hashes to __8E ? Unfortunately, not having access to the algorithm (even as a black box) means it's next to impossible to test such things...



Edited 1 time(s). Last edit at 11/28/2007 01:33AM by thornmaker.

Options: ReplyQuote


Sorry, only registered users may post in this forum.