millen1.htm: +HCU Millennium Strainer Anti-debugging techniques inter alia

+HCU Millennium Strainer: 26 July 1999 "Here it is!"
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