+HCU Millennium Strainer: 26 July 1999 "Here it is!"
hcu.gif
A delayed strainer
by Fravia+

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.



 


You'r deep inside fravia's pages of reverse engineering
red

Download aescul.exe here: redaescu_mi.zip
    
Back to the Introduction page

red

redhomepage red links red anonymity red+ORC redstudents' essays redacademy database redbots wars
redantismut redtools redcocktails redjavascript wars redsearch_forms redmail_fravia
redIs reverse engineering illegal?