Didactic Feedback Cipher Long 3

[miyako]

i really hate asking for hints, but i'm really stuck
with this one. i'll try to keep it as vague as possible:

obviously a simple brute force won't do the trick
due to the ernormous runtime, so checking subsets
seems to be imperative.

i'm quite sure i have a working peace of code that
checks for "valid" charakters in the rendered
plaintext. but it doesn't find sufficient amounts of
them.

should i expect the deciphered text to be clearly
readable as in the other challenges before?
could anyone give a little hint?

miyako

[miyako]

ok, i found the mistake ...

[MerickOWA]

Yes, the decrypted text should be clearly readable like in the other problems.

If you're not finding sufficient amounts of valid characters, its possible you're interpreting the encrypted text wrong.

Its possible that you're treating the encrypted text as 4 bytes of a "little-endian" integer instead of 4 bytes of a "big-endian" integer ( or its visa versa, again i can't remember exactly ).

Try doing things the other way and see if that helps.

[MerickOWA]

ok, i found the mistake ...

Great!

[Andr3w]

I cannot solve this challenge ...

So I hope anybody can give me a hint ...

I was trying to solve it with C++ ...

is there a way to handle integers greater than 4 bytes long ?

handle means + ^% and so on ....

by the way i'm an absolute beginner in C++!

thank you

[Allosentient]

use "long" instead of "int" for 8-byte integer storage.

[Andr3w]

you're right, but in this challenge i need more than 8byte integers ...

% 0x100000000 is slightly more than 8bytes =(

[Karian]

IF you need more then 8 bytes, you will have to use something for using bigger integers. In most programming languages, there are packages for using integers of 'infinite' length.

I'm mainly a java programmer so I can't help you to the package for c++. In java you have the BigInteger class to do this.

But offcourse, these packages are a bit slower then the default types, so you better check that you really need them. Maybe their is a way around using it.

[Andr3w]

^^ thanks

i will try to found a c++ class to deal with bigger integers ...

[m!nus]

you're right, but in this challenge i need more than 8byte integers ...

% 0x100000000 is slightly more than 8bytes =(

% 0x100000000 is 4 byte if i'm not totally mistaken

[MerickOWA]

If you use int's or unsigned int's in C++ theres no need to do a % 0x100000000. This is what is done automatically by the CPU using integer math. Example: 0xffffffff + 1 == 0

The only reason the example code has a "% 0x100000000" in it, is that it is written in python, which supports "big numbers/integers" which allow for exact precision on numbers which can be as big as the memory will allow, therefore it wont wrap around like C++ ints will.

[Andr3w]

This hint is really helping me

great ... thanks

[Pita]

5 bytes are the right answer. The one is excatly after the 4 bytes. So when you do % 0x100000000. It's the same as a bufferoverflow with 4 bytes

you're right, but in this challenge i need more than 8byte integers ...

% 0x100000000 is slightly more than 8bytes =(

% 0x100000000 is 4 byte if i'm not totally mistaken

[Felicia]

'% 0x100000000' is equal to '& 0xFFFFFFFF', which is 4 bytes
if you want to handle integers greater than 4 bytes, you may use 'long long'

[nto]

use "long" instead of "int" for 8-byte integer storage.

That depends entirely on the compiler used. In my environment sizeof(long) is 4 bytes. You should use a long long if you want a guaranteed size of at least 8.