Shism's Bugger v.7
| Download bugger_v.7.zip, 7 kb (password: crackmes.de) Browse contents of bugger_v.7.zip Finally, got a new version released.... I've been busy with life and a protector I and DAXXOR(FREAKDROPPER Author ) are working on. Which a crackme protected by it will be released possibly by the end of this month.
Difficulty: 3 - Getting harder | Send a message to Shism » View profile of Shism » |
Solutions
There are no solutions to this crackme yet. Have you solved it? Please write a tutorial and submit it here!
Discussion and comments
| Shism Author 13. Sep 2005 | Well need the key to defeat this crackme :).... Anyway, PM me a mini tutorial how to defeat the checks and Ill give you another hint if you give me a detailed mini-tutorial. |
|---|---|
| Oorja-HalT 14. Sep 2005 | Thats a swell crackme. Surely looking forward to its solution . I am sure i would have something to learn |
| Shism Author 02. Oct 2005 | The key is in the data of the container.... which holds the exe and txt file. The key is crc32 hashed ..... Someone give a solution already jeez. |
| Shism Author 03. Oct 2005 | The container is the rar file.... |
| pants 02. Jan 2006 | Crackme is broken on some versions of Windows/SPs - either not working at all or (worse) further screwing up the (already broken) key schedule. HINT: http://webster.cs.ucr.edu/Page_win32/WindowsAsmPgm/html/Ch03.html#1005288 I'd be very interested to know if the author sucessfully managed to bf this him/herself in a reasonable timeframe (without _any_ knowledge of format of src key) - I'm strongly suspecting not... |
| Shism Author 02. Jan 2006 | The key schedule is not broken.I just didn't implement a check for the correct key and it was implemented that way.If you keep pressing go ... A messed up key will show up. You'll have to restart the program.I left two solutions to the crackme,one way is bruteforcing the Rc6fish or cracking the crc32 which is hidden outside the crackme itself. After cracking the crc32 hash, you get the password to input. You will know the key,if you a readable english word.... |
| pants 02. Jan 2006 | Thanks for the quick reply ---> The key schedule is not broken. It is broken on some versions of Windows (see above). Without guessing it's impossible to know, with certainty, which pbox value was used and hence the resulting key schedule seed. I don't think you'd be giving too much away if you were to state the values of all registers POST-movemem - you'd just be fixing one of the bugs. ---> I left two solutions to the crackme,one way is bruteforcing the Rc6fish or cracking the crc32 which is hidden outside the crackme itself. I'm aware of both, but both are dependent on a 'working' key schedule - one directly, one indirectly. I have been concentrating on the rc6 bruteforce as the 'crc' clues were extremely vague and appeared to be an afterthought. RC6 Rc6 dictionary attack - over 100 dictionaries didn't shown anything. Each was tried as AllUpper, AllLower, UpperFirst, Leet and natural. Rc6 bruteforce attack - been running for 2 days now. Day one was a collection of _feasible_ key sets and key sizes. Day two+ is all useable chars. Sucessful bruteforce attack is looking less likely the longer the search goes on, hence my original question - given the src key, is it reasonable to continue with a bf of the rc6 _alone_? Of course, both dictionary and bf would be screwed up if the wrong register values were guessed when fixing the key schedule... CRC The information provided is extremely vague, but it's looking increasingly like this is the only feasible way to solve this. Exploiting weaknesses in CRC would reduce required bruteforce range significantly (^4), making keys of 8-12 digits feasible (bf of x digits produces x+4 digits of output, once you've calculated a correcting crc). Whilst writing this I hacked up a quick CRC crack+bf - ~10% if all 12-digit [a-z] == ~5 million CRCs that match - therefore the rc6 decryption/validation stage will still be required (aasuming dictionary attack failure was genuine) - which takes us back to the broken key schedule... To recap: _How_ to crack this crackme is known. Bruteforcing rc6 doesn't take much thought, just lots of electricity. 'Cracking' CRCs is well documented and the math is cheap. What _isn't_ known, with any confidence, are the register inputs to the key expansion routine on which both are dependent. It might work on your machine, but it certainly doesn't work on mine.... :( |
| Shism Author 02. Jan 2006 | what os are you using? |
| Shism Author 02. Jan 2006 | Here are the registers right before the call. of movemem eax = 0 ecx = 77F59037 edx = 00140608 ebx = 0 esp = 00B4FF84 ebp = 00B4FFA4 esi = 7FFDD000 edi = 7FFDF000 |
| pants 03. Jan 2006 | ---> what os are you using? One that respects Intel/Win32 ABI register conventions. I'm not trying to be funny - that's the only answer that's relevant. If this answer makes no sense to you then I'd suggest you take a look at the link provided above. ---> Here are the registers right before the call. of movemem Thanks, but I truly hope you can see why they are irrelevant. There were a number of questions in the previous post that remain unanswered. So I'll be more specific:- [1] What are the values of eax and ecx IMMEDIATELY AFTER the call to RtlMoveMemory? [2] Can you see why these values might be different on other versions of Windows/SPs? [3] Can you find other instances where you've made similar assumptions in this crackme? [4] Can you see how they would hinder attempts to solve this crackme? [5] Can you see that the RtlMoveMemory one means some users will have to guess the inputs to the key expansion? [6] Have you successfully bruteforced this yourself (rc6 alone) without knowledge of the source key? [7] Given this particular source key, is a bf of rc6 alone even _feasible_? [8] If you don't consider it's too much of a clue, roughly what kind of keyspace and/or alphabet are we talking about? Question [8] is the only one that involves any kind of 'hint' - I'd prefer not to ask, but having no confidence in my 'guessed' schedule I'm left with little choice. I gave in and added a CRC 'crack' stage to speed things up, but I'm still not seeing much love from the bruteforcer. Either the keypace is insane or I guessed the wrong fix... A good deal of effort has gone into this over the last 2 days - not just computational. Unfortunately, the stumbling blocks have really had nothing to do with any kind of protection. I'd prefer it if others didn't have to suffer as much as I have getting the thing to work - particularly when it had so much potential. |
| Shism Author 03. Jan 2006 | [1] What are the values of eax and ecx IMMEDIATELY AFTER the call to RtlMoveMemory? eax = 1048 ecx = 0 [2] Can you see why these values might be different on other versions of Windows/SPs? Yes, I understand [3] Can you find other instances where you've made similar assumptions in this crackme? ??? Don't understand. [4] Can you see how they would hinder attempts to solve this crackme? Yes [5] Can you see that the RtlMoveMemory one means some users will have to guess the inputs to the key expansion? Yes [6] Have you successfully bruteforced this yourself (rc6 alone) without knowledge of the source key? Rc6 no... Crc32 hash yes [7] Given this particular source key, is a bf of rc6 alone even _feasible_? No, the bruteforce of crc32 yes. [8] If you don't consider it's too much of a clue, roughly what kind of keyspace and/or alphabet are we talking about? *16 characters ok let me reduce your keyspace by alot. Numbers = 1-5 ( no 0,6,7,8,9) Only 2 numbers 5 Lowercase letters 8 uppercase letters 1 special character= * There is your huge clue :) |
| pants 04. Jan 2006 | ---> [1] Aha! Thanks, now I can correct the rc6 stage... :) ---> [2] [4] [5] Excellent! ---> [3] e.g. ebx in the dialog (as used by the CreateThread calls) ---> [6] [7] Good to know, but unfortunate. Without your posts in this thread I don't think I'd have connected the everything-is-byte number with 'crc32 of the key'. Interesting that you confirmed you've personally bf'd at least the crc stage - that gives me hope... ---> [8] ...And the hope turns to despair... :( You gave a far bigger clue than I was expecting, but - now that I see it - I'm glad you did. Assuming we can 'guess' the 2 numbers, and assuming the special char is (literally) '*' and assuming we have a magic computer that can process 1 billion keys per second, then it would take something like 222 billion years to cycle through that key space. Thankfully, reducing the key space by expoiting the crc reverse brings this down to a much more reasonable 24,000 years. Well, that was fun! If anyone has need for a working bruteforcer for this then let me know... :) All joking aside, and as painful as this was, I'd still like to say a big thank you for putting this crackme together - it was a nice coding and research excercise. Good luck, and a happy New Year! /pants. |
You may leave your comment, thoughts and discuss this crackme with other reversers here.
Acting childish will not be tolerated.
HTML and such will be left as-is, so don't try.