hacker.org

Posted: **Mon Oct 05, 2009 4:12 pm**

theStack wrote:
wrtlprnft wrote:Hmm, I probably used the wrong endianness. Here's what I got, without the first four chars (presumably “i ha”) and the last one (probably an exclamation point):
ve to admit, i don`t know how i`d solve this one nyself. not#tiat this is AEl nr amything. but still, gettinf nore!tricky. oh by the way, you!are lonhnng for penguinhcity, noble solver
Easy enough to guess, though, by just trying all chars that are close to “h”
I got exactly the same text, with x = 21 | (254 << 8 ) | (232 << 16) | (19 << 24) = 0x13e8fe15
So we made the same mistake as many others here, choosing Big Endian instead of little endian

I got the same too, but I don't get how endianness solves the problem either. Supposing you mean byte (and not bit) ordering, I don't see how it could change the characters (not their ordering) since each character is encoded by one byte (unless the text isn't encoded in ASCII...). And this seems to be a problem as I get some non printable characters in the "decoded" text for every value of x.
Can someone help me on this one please?

Posted: **Mon Oct 05, 2009 5:47 pm**

cosmos wrote:I don't get how endianness solves the problem either.

Consider the direction of carry between bytes.

Posted: **Thu Aug 26, 2010 3:18 pm**

This one took me so much time.

and it should describe how to evaluate (txt -> txt[i + 3]), using little endian or big endian

Posted: **Tue May 31, 2011 1:32 pm**

I still don't understand the endianness thing:
Would {0, 1, 2, 255} + {0, 1, 2, 3} = {0, 2, 4, 2} as it would if we took 0+0 then 1+1 then 2+2 then 255+3 ignoring the last carry as it is outside the available range
or is it {0,2,5,2} as the 255+3 has carried to the left? Neither of these methods produces perfect output when used in the cipher with either of the keys people have given in the forum; I only get the garbled version using method 2 (the 'normal' method of adding, right-to-left, carrying to the left) and the key {19, 232, 254, 21}.

Posted: **Tue May 31, 2011 6:46 pm**

It's the first method you describe. (BTW: I did the same mistake using the wrong endian, interpolated the answer and later wanted to know how it's working

)
This is how it finally worked for me after breaking the whole thing into bytes and handled the overflow myself:

Code: Select all

#!/usr/bin/perl
$string="insert_crypted_string_here";
$cipher=0x03db992f8; $cipher1=0x3d; $cipher2=0xb9; $cipher3=0x92; $cipher4=0xf8;
$x=0x14fde914; $x1=0x14; $x3=0xfd; $x2=0xe9; $x4=0x14;
$dec_string="";
my $index=0;
$k1=$cipher1;
$k2=$cipher2;
$k3=$cipher3;
$k4=$cipher4;
while ( $index <length($string) )
{
        $chr1=hex(substr($string,$index,2));
        $chr2=hex(substr($string,$index+2,2));
        $chr3=hex(substr($string,$index+4,2));
        $chr4=hex(substr($string,$index+6,2));

        $dec1=$chr1^$k1;
        $dec2=$chr2^$k2;
        $dec3=$chr3^$k3;
        $dec4=$chr4^$k4;

        $dec_string=$dec_string.chr($dec1);
        $dec_string=$dec_string.chr($dec2);
        $dec_string=$dec_string.chr($dec3);
        $dec_string=$dec_string.chr($dec4);
        $index+=8;

        # overflow from left to right
        $k1=$chr1+$x1;
        if ($k1>0x0ff) { $k1&=0x0ff; $k2=$chr2+$x2+1; }
        else { $k2=$chr2+$x2; }
        if ($k2>0x0ff) { $k2&=0x0ff; $k3=$chr3+$x3+1; }
        else { $k3=$chr3+$x3; }
        if ($k3>0x0ff) { $k3&=0x0ff; $k4=$chr4+$x4+1; }
        else { $k4=($chr4+$x4); }
        if ( $k4>0x0ff) { $k4&=0x0ff; }
}
print "result=$dec_string\n";

Posted: **Mon Sep 03, 2012 11:20 pm**

the little endian hint helps me to get the right answer thx@gfoot.

Posted: **Thu Apr 24, 2014 5:29 pm**

I didn't even think about endianness here

Also I now realize that I although I did solve the challenge, I didn't get the right x.

I kinda ignored the fact that the key is 4 Bytes and worked the whole thing Byte by Byte. Meaning I also gave a shit about the carry

So what I considered to be x was 0x14E9FE15

Java:

Code: Select all

final char[] challenge = {0x54,0x99, ... ,0xa2,0x80};
		char[] x = {0x14,0xe9,0xfe,0x15};
		String result = "";

		//didn't bother calculating k, so obviously the first 4 Bytes have to be cut off, 
		//so we start with i=4
		for(int i = 4; i < challenge.length; i++){
			result += (char) (challenge[i]^((challenge[i-4]+x[i%4]) % 0x100));
		}

		System.out.println(result);

Posted: **Tue Apr 07, 2015 5:27 pm**

At least he admits that he can't even solve it himself :D

At one point I figured out that for example the lower 8 bits of the key modifier (x) are responsible for every 4th char ... so I tried all 0-255 and looked at them ... one looked good, next higher 8 bits ... and so on :D

But for the next challenge, that's probably not gonna help.

hacker.org

Didactic Feedback Cipher Long 2

Like archeology...