Dear readers, I'm proud to introduce the Millennium strainer, for the +HCU 2000 courses. I know that we are late: due to the problems that are listed elsewhere we have had a three-months delay in the presentation of the strainer this year. I would tehrefore propose that all your answers for admission should be presented either to +Aesculapius, to +ORC, to +Greythorne, or to me BEFORE THE 15 December 1999, so that you will have four months and two weeks to solve the strainer and we will have some time for the evaluation of all results. We hope that +ORC will send his contribute very soon, but we will anyway publish the fourth challenge of this strainer before the end of August.
+HCU "Millennium" Strainer (Strainer 1999) By Aesculapius ------------------ Aspirant HCUckers around the world, welcome back. This is the part of reversing that I mostly like, because I have the opportunity to make some statements and be sure I'll be heard by the best reversers worldwide. Before I begin with the technical part, I want to express my gratitude and commitment to the +HCU's members, specially to those who make possible its existence and who also are, the primer teachers & students of this academia, among them, +ORC, Fravia+, +Greythorne, +Sync) and the rest of the +HCUkers. Last year's Strainer fulfilled some of my expectations, but it would be dishonest from me to say it was all I expected. One of the Strainer objectives was to stimulate investigation in certain fields where there were lack of knowledge, in this regard, the Strainer was designed to create a favorable situation for the study and research of Win32 assembly and Demo reversing. As it turned out, there was an important boost in win32 assembly field, in part (although modestly) due to the Strainer challenges. Although the findings and demonstrations of every participant were excellent in regard to demo reversing, this field did not seem to be boosted at all. +ORC wanted to enhance our knowledge in this field, and it was my intention to help him achieving this goal, however, life does not always evolves as we want, but I'm sure there will be time for demo reversing very soon. Ok, enough chatting, now, is time to get some heat. This year, I'm not going to hide the general objectives of the Strainer. Basically, I want to kick off the field of modern anti-debugging techniques and Server authenticated protections reversing. It'll be divided in four sections or challenges (as before), but I will include additional rules to ease the presentation and delivery of the answers. In regard to the limit date to deliver the answers, I don't know, +Fravia will decide how much time you need to comply with the four challenges. CHALLENGE I: Anti-debugging & Decompiling Techniques ---------------------------------------------------- Target: aescul.exe Location: aescu_mi.zip aescul.exe is a little demonstration of how we can cripple any debugger even if it runs as a device driver like SoftICE (R), or dwells in the silicon world as an application-level one, like the rest (except TRW). There are some documents about anti-debugging in the web, nonetheless, most of the proposed techniques are outdated and beyond that, easily overwhelmed by modern debuggers running in privileged memory far away from any possible influence originated in the constrained Ring 3 world. Changing IVT vectors, disabling the keyboard interrupt, setting some INT3 instructions in the code, PIQ, altering the stack in the debugee process, will do little or no harm at all to modern debuggers. Moreover, knowledge in this field has become an exclusive field belonging to guru coders, which rarely have enough popularity as to let them publish updated books (regular wannabe programmers who buy them simply doesn't understand they higher language). The rest of today's protectors don't care enough (or know enough in some cases) as to develop effective techniques in this regard. Fortunately, for most crackers, effective techniques require solid knowledge of assembly language which has become in a sort of "the latin of programming". Used wisely, anti-debugging is very effective, but in most cases, the performance impact when used in already over bloated applications is striking. Making your code more difficult to trace has a price, slow performance and "hard to find" bugs among them; the common scheme is to shield only the sensitive parts of the protection leaving the unimportant code alone, it is a waste of CPU time, obviously, any attempt to protect sections of code&data not related to the protection. In Win32 world we have to face with yet another problem like making our protection shield only the parts of the code we wrote and not the API functions called from within inside the protected area. For the CPU, a code is a code, no matter if it is inside a common library or not. Although we can provide some additional functions to detect code running at an unexpected high address in memory (like API functions) and save some CPU time based on this, still we need to provide code to check constantly for such situation. Intel architecture intrinsically failures to provide enough features as to make this last distinction easy to perform without affecting the CPU usage. The version of Aescul.exe I provide for reversing with the Strainer is a limited one, several functions were eliminated to make it more cracker-friendly; the original version and source code (which will be released only for members of the +HCU) is very aggressive and will strike your system in such a manner that it will come down in hurry at the slightest cracking attempt. Recently, I have developed a function which will detect and gain access to any debugging or decompiling process dwelling even if it is running in its own protected address space and trash their memory at once, this function was highly efficient in matter of CPU time when tested in the newer PIII processor but I can't assure equal performance in lower CPU's. Now in regard to how Aescul.exe was created, I want to discuss it in a little bit more of detail: Aescul.exe, in particular is a very small protection, there is no overhead in it to "hide the sensitive locations"; it should be, therefore easier to grasp if compared with a 5 Mb executable using the same techniques, so don't forget to picture that when you're reversing it. The whole program (in case you still don't get it) is a protection, so one of the first steps in cracking (locate the protection) is not necessary, because the whole thing is a protection. Notice the performance impact that it exerts in your system. It was created using only assembly and a Resource Editor for the fancy presentation, nothing else. Some functions are repeated over the code (to confuse a little the wannabe's) and some API calls are not strictly necessary (I can't tell you which of them at this time because that would spoil the fun). In part, the idea behind these failures (which I'm portraying for you beforehand) is to see how far can you go to improve it. I suspect the Key algorithm will produce strange looking keys in a WinNT system (I can't explain why for obvious reason, at this time), I am not sure because the NT system where I test was not available when I coded it, however, this is not strictly necessary to solve the strainer if you understand how it works. Well, boring preambles are always important, now the objectives: To successfully approve this challenge, the participant must: 1. Decompile Aescul.exe and explain prolixly how it works. The better you explain the higher you qualify in this challenge. 2. Improve Aescul.exe or write something better than it. 3. Create a Key Generator for it (this final step is compulsory to approve). CHALLENGE II: Server Authenticated Protections... ------------------------------------------------- Target: CuteFTP v. 3.0.2 Location: ftp.cuteftp.com CuteFTP is one of the best FTP clients available worldwide. Its protection is worthy of careful analysis. The author of CuteFTP requested me the possibility of a "Tough Protection Award" being granted to it after a failed attempt (on my part) to crack it. I did a crack for it, which is certainly not 100% perfect but it provides more stability than most I have seen in the web. Soon after, I achieved the perfect crack for it (which will be published only for +HCUkers because I think a good protection deserves respect). The possibility of a Tough Protection Award is interesting and I'm sure +Fravia will consider it as long as CuteFTP resists the Elite of reversing world reading and accepting the challenges in our Strainer. Basically, the protection performs multiple self-integrity checks and based on this decides on whether to proceed cleanly or lead the execution path to a routine (disguised as something harmless) that will generate a GPF. To approve this challenge the participant must: 1. Explain the key algorithm used in CuteFTP. How it is decrypted, where it is stored and tested, description of the code involved in the process, etc. 2. Explain the self-integrity check system used in CuteFTP, how and why it crashes, possible solutions. 3. Explain the server authenticated part of the protection. 4. **Optional Item** Create a crack with FTP capabilities to download an updated set of patching locations from a web site in case of updates for CuteFTP disable your patching locations. **Hints:** Knowledge about WinInet API set will be of great help. 5. **Optional** Answer this question: Is there a way to crack this protection without patching it? Explain in detail. CHALLENGE III: Anti-debugging & Anti-Decompiling, some more... ------------------------------------------------------------- Target: CodeSafe v. 3.1. Location: http://www.geocities.com/SiliconValley/Park/9031 Its a product to enhance the security against cracking in commercial software. It features advanced anti-debugging and anti-decompiling. It offers a decent compression engine too. Sadly, not too popular among lazy programmers (the author is giving away the source code, apparently) who search for an easy way to maintain their products far from our claws, but brilliant indeed. To successfully approve, the participant must: 1. Explain how Codesafe loader is attached to the target. 2. How does the loader locates the target ImageBase. 3. How does the loader locates kernel32 ImageBase. 4. How does the loader locates API entry points. 5. Describe the decryption process. 6. What kind of anti-debugging and anti-decompiling is used. Explain as much as possible. 6. **Optional** Create a crack for it. CHALLENGE IV: Yet to come... ---------------------------- Left empty on purpose. +ORC has not contacted me lately but I hope he will soon. I will respect his rights to collaborate with the Strainer contents. If he doesn't communicate, a fourth challenge will be published before the end of August. Final words: Although it is not noticeable at this time, all challenges and targets in the Strainer are strongly related, is up to you to discover these links and expose them to us. I'm sure nobody will miss this strainer because it will greatly enrich our knowledge in the field. INSTRUCTIONS: From our experince in the last year's Strainer ------------------------------------------------------------ 1. Not compliance with a single one of these rules == Forget About the +HCU. 2. Answers will be valid ONLY if they are delivered on time (before 15/12/99) to: +Aesculapius +Fravia +Greythorne +ORC NOBODY else is authorized to receive answers and NOBODY else except for an +HCU teacher can accept you as an +HCUcker. 3. Cheating == Death Penalty. 4. Publishing answers in the web, USENET or any other public media before the time for delivery is up, will disqualify the participant(s). 5. About the procedure to deliver the answers: a. Only zipped or RAR files will be accepted. b. The participants *MUST* include both their sources and executables, with a detailed explanation on how they were compiled. c. If the participant used personally modified includes or header files, these should be delivered too. d. No sources == Get Lost! e. Every Challenge will require a complementary ESSAY explaining in detail all of the challenges solutions. These essays will be published when we decide who enters and who don't. 6. Once you deliver your answer, a confirmation email will be sent to you in other to assure you we got it. 7. Asking me to give hints for taking advantage will get no answer. 8. Asking for the password to enter the +HCU classroom will get no answer. 9. Answering all challenges != I'm an HCUcker. We will perform a selection to accept only the better answers. 10. Bugs will greatly hit your scoring. 11. Last but not list: Items marked **optional** are not compulsory, but if answered, will award more value to your score and even compensate for wrong or incomplete answers in other challenges because these items are considered of higher difficulty. However, how the value of an optional item is weighed against a wrong answer, is a decision belonging to the +HCU teachers only, and not to the participants by themselves. Please, be "academic", good luck and happy reversing. +Aesculapius.
|Download aescul.exe here: aescu_mi.zip||Back to the Introduction page|