can YOU do it
I'm trialing some new forms of encrpytion.
they are composite enryptions using existing algoritms… well teh first few will be any.
I'm going to post them here, anyone who cracks them will go in my sig for 2 weeks.
I'll edit this post to add new ones periodically.
the first one is!:
NTQ2ODY5NzMyMDY5NzMyMDYxMjA3MzYxNmQ3MDZjNjUyMDczNzQ3MjY5NmU2NzIwNjQ2NTczNjk2NzZlNjU2NDIwNzQ2ZjIwNzQ2NTczNzQyMDZkNzkyMDY1NmU2MzcyNzk3MDc0Njk2ZjZl
Number 2!:
=,^),^)')')( \V 7=,9 '& ^ 4Z 6?
Number 3!:
$.'-3 =,18X R.#%\ 824/1- ;' 7;*_220!<<2. %S!>UX ENJOY! i realise that there are non ASCII. also the newlines are important.
edit: just disabled smilies to make it… you know… possible
Initial String: NTQ2ODY5NzMyMDY5NzMyMDYxMjA3MzYxNmQ3MDZjNjUyMDczNzQ3MjY5NmU2NzIwNjQ2NTczNjk2NzZlNjU2NDIwNzQ2ZjIwNzQ2NTczNzQyMDZkNzkyMDY1NmU2MzcyNzk3MDc0Njk2ZjZl
Base64: 5468697320697320612073616d706c6520737472696e672064657369676e656420746f2074657374206d7920656e6372797074696f6e
Hex Chars 54,68,69,73,20,69,73,20,61,20,73,61,6d,70,6c,65,20,73,74,72,69,6e,67,20,64,65,73,69,67,6e,65,64,20,74,6f,20,74,65,73,74,20,6d,79,20,65,6e,63,72,79,70,74,69,6f,6e
Decoded: This is a sample string designed to test my encryption
EDIT: Cool… just spotted my name on your sig :ninja:
I looked at it and it was pretty obvious it was Base64 (the mix of uppercase, lowercase and numbers with no spaces)…. the only thing missing was the '=' at the end of 'most' base64 strings.
I already have a tool that I coded to decode base64….. I made a tool to do base64, morse, binary, hex/dec/ascii decoding etc in MASM ages ago when doing hackits.de/bind-dice/bright-shadows.net.
Decoding the Base64 gave me a load of hex chars so again, it was easy to spot and decode.
If you had done something extra to the hex chars (say simple atbash/caesar/transposition cipher) it would have made it a little trickier but then you need somewhere to take enc 2 :)
Looking forward to the next ones :)
korg i can get people to take the answers down if you want.
most of them wil be variations on it though, i'm just inputting random shit.
and yes, the first one was VERY easy…. i forgot how to convert decimal to hex efficiently in python so i had to skip a few steps.
ha ha the next one should be a lot trickier
ha yeah sorry korg, since they weren't REAL challenges in the points sense i figured people might want to work backwards from the answer later on.
but yeah, thanks for the positive feedback. for the purpose that this is going towards (secret enyption stuff lol) i'm not going to update with anew one till someone gets the old one.
so get crackin!
richohealey wrote: f so that i know which ones are crackable.
just to say that you cant get an uncrackable encryption, it actually breaks the laws of physics to be so secure. if you REALLY want an uncrackable encryption check out this
thanks heaps, new one is up.
i think this one should be pretty uncrackable.. well, you know… with the available recourses i doubt anyone will crack it.
if no one has it in a week i'll release a hint. this one is VERY difficult.
and spyware, yes i agree that long strings are better, BUT this is testing for a purpose, and these are realistic sized chunks, although quite unrealistec sentences
Ok… had a brief look at it. Without giving too much away, I'm guessing the first part is similar to the first part of number 2, but I need a key word?
I've tried a load of things which don't seem to help. If I'm right about the keyword, is it something guessable (or dictionary?) as otherwise I think you're right about it being almost uncrackable?
Or am I completely wrong? :)
ive also make a quick lil encryption, you can find it at noobschallenges.org/textencrypt.php :) enter between 1 and 10 characters and itll spit out a binary. bet noone can decrypt this string : 00000000000000000000000000000000 00000000000000000000000000000000000000000000 00000000000000000000000000000000000000000000000000 000000000000000000000000000000 000000000000000000000000000000000000000000 000000000000000000000000000000000000000000000000000 0000000000000000000000000000000000000000 000000000000000000000000000000000000001100000111110 00011111000111111110000000000000 00000000000000000000000000000000000000000000111 0000110001100110001100000000110000000000000000 00000000000000000000000000000000000000001 111000000000011000000011000000011 0110000110001111000110000110001111100110 11110000111100000011000000000110000000110000 0001100110000110011001100110000110011000110011100 1100110011000001100000001110000001110000000 1100011000011011000011011000011000000 011001100000011000011000011000000000110000000 110000011000011000011011000011011000011001111111001 1000000111111110000110000000000110000 00011000110000011000011011000011011000011011000 01100110000001100000000001100000000001 1000000011001100000001100111001100110001100111011 000111001100000001100011000011000011000 1100110001100110000000001110110001111000001110 11001111011001100000000111110001111110 0011111000011111000110000000100000110000000000 000000000000000000000000000000000000000 00000000000000000000000000000000001111110000000 0000000000000000000000000000000000000 000000000000000000000000000000000000000
(the newlines are there to conform to hbh's layout, its not part of the encryption :P)
P.S. its reversible(obviously) and its not to do with the binary itself, more what it represents :P
@mr noob: "you are 1337".
Very clever… I liked that one!
Just been playing around a bit more. Just one point to note:
I think that if you copy and paste the chars from the forum post, your decoder would fail. This is due to tabs and carridge returns.
The forum doesn't allow tabs (0x09h) and treats them as spaces (0x20h) which obviously screws up the text when some of the chars are 0x09h. Similarly, where there are any 0x0Ah or 0x0Dh, the forum treats them as carridge returns so when you copy the text, you always get two bytes : 0x0Dh and 0x0Ah. Again, this obviously screws up the text when you have either 0x0Dh or 0x0Ah bytes in the text.
Its also impossible to determine what should have been there because any 0x20h byte could actaully be either 0x20h OR 0x09h (same with 0x0A and 0x0Dh).
The initial Third encryption (which you replaced) has no problem because there are no 0x09h, 0x0Dh or 0x0Ah bytes. The new one however could not be decoded by your decoder.
Hope that makes sense? The way to get around it would be to process the output string (after encoding) and to replace 0x09h, 0x0Ah and 0x0Dh with unique bytes so that a decoder could replace them before going on to the next stages e.g. replace all 0x09h with 0x99h; all 0x0Ah with 0x9Ah and all 0x0Dh with all 0x9Dh.
That would make it tough to crack too.
I need to actually do some work now or I'm gonna get sacked.