hacker.org

Ah, little endian ...

My first try was like:
"01234567" => 0x01234567

And isn't there garbage at the end?

I got garbage all through, and not even at four-character intervals, but no doubt I got the key wrong or something.

what values did you guys get for key and x?

I didn't keep the values, but it's easy enough to run through again. So these might not be the same as last time...

I didn't bother solving for k, but I got x = 0x13e8fe15. For k I just use 0.

Oh, I see, it's endianness again - I did it backwards, and the overflows were flowing the wrong way. I just did it again the other way around, and the text looks fine now (x=14fde914, k=0), but with junk at the start (expected) and end (not expected).

I went the very same way as gfoot did.
First, big endian, x=0x13e8fe15, k=0, the text results in a bit broken.
Next, little endian, x=14fde914, k=0, the text has 4 byte garbage at the end.

tails wrote:I went the very same way as gfoot did.
First, big endian, x=0x13e8fe15, k=0, the text results in a bit broken.
Next, little endian, x=14fde914, k=0, the text has 4 byte garbage at the end.

There isn't garbage at the end, the text is 3 bytes too short to make a full 32 bits. If you trim your answer to the same number of encrypted bytes the garbage goes away.

This one was a little tricker to solve than the others, but still not terribly difficult.

Using little endian, the first two bytes of X have to be 0xe914. The 3rd byte could be 0xfa to 0xfe, but only 0xfd made the string have less "unusual" symbols (those symbols in the 32-126 range)
and last byte could have been 0x14 or 0x15. 0x14 was an obvious sentence .

MerickOWA wrote:There isn't garbage at the end, the text is 3 bytes too short to make a full 32 bits. If you trim your answer to the same number of encrypted bytes the garbage goes away.

Ah that's right. I carelessly miscounted the length and felt sure it had no odd bytes. Thank you for pointing it out!

hmmn, this cipher has the great property of working for any possible k if you have the right x -- you just lose the first four bytes. shows the danger of trying to make up new ciphers =)

adum wrote:hmmn, this cipher has the great property of working for any possible k if you have the right x -- you just lose the first four bytes. shows the danger of trying to make up new ciphers =)

All the of the latest xor challenges have been like that.

You either xor encrypted with encrypted[i-1] to figure out the value

or

guess "x" and xor encrypted with ( encrypted[i-1] + x ).

Makes it even easier to guess "x" if you assume that all values will be between 32 to 126, and if you get anything outside that range, then 'x' is wrong.

Well, just use original values instead of encoded like this :

for (i = 0; i < len(txt); i += 4)
c = (txt[i] -> txt[i + 3])
c_encoded = c ^ k
print c_encoded
k = (c + x) % 0x100000000

That's very vulnerable to a dictionary attack. Factoring in the previous key by addition would be hard though.

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”

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 also got the garbled text, though I'm not sure how endianess figures into this.

I basically broke the problem up into four sub-strings, and ran the cipher on each of those. The only trick was to make sure to carry a '1' where appropriate.