+HCU papers

---

courtesy of fravia's page of reverse engineering
10 June 1998

---

SLH's sixth paper
The iron fist

---

       


> THE IRON FIST
>
> There is a story that comes from the sixties which pertained to the "right"
> way to program an IBM system 360/370 mainframe. If all else failed, you
> could always fix it in Fortran and if that didn't work, you could always
> fix it in assembler and if that did not work, there was something wrong
> with the problem.
>
> These pioneers had the reputation of being able to live patch a crashed
> mainframe by doing a core dump and entering hex from the front panel, give it
> a boot and off it went until next time. Programmers who did not know how to
> do these routine forms of software maintainance were referred to as "quiche
> eaters", a reference to their lack masculinity for not knowing how to do the
> things that men needed to know.
>
> Now its not to say that these guys didn't have a heart, if you grew up
> knowing the words to Elvis Presley's HeartBreak Hotel, wore Gene Vincent's
> Blue Suede Shoes, could rock and roll to Bill Haley and the Comets and had
> tears in your eyes when Buddy Holly, Richie Valens and the Big Bopper were
> killed in a plane crash, you probably made it as a human being. Its just
> that a man's got to do what a man's got to do.
>
> Now if this sounds like an episode of "Happy Days" you not far off where
> the action was with these guys, traveller from a different piece of space/
> time who helped to shape the world of computing as we now know it.
>
> The word is that "Men who wrote in Fortran" were beer drinkers, it seems
> that good malt was real hard to get back in those days, yet it did not stop
> them from being the architects of guidance systems for the ICBMs of the cold
> war or the number crunchers for the effort to put man on the moon. Its just
> that the world changed and some of these things went out of fashion.
>
> Just one word of warning, try out this approach on any of your female
> colleagues out there punching numbers in assembler, C or whatever and you
> run the risk of getting you brains beaten out with a spare debugging monitor
> or an empty scotch bottle (you wouldn't waste a good one), so it is not as
> if you have not been warned.
>
> While we are truly blessed by not needing an air conditioned boiler room to
> house one of these technologic marvels of the sixties, complete with reel
> to reel tape, front panels with flashing lights and banks of hard disks that
> were eight feet tall, there is just a kernel of truth in the disposition
> that if you want to keep things going well, you need to understand what is
> happening at low level in a computer.
>
> For the modern software warrior who has crafted a sword worthy of legend
> which is hardened, tempered, light and beautifully balanced, there is just
> a little honing of the edge to do and this is in the area of function
> design.
>
> One analysis of the difference between the European Knights and the Saracen
> Knights who did battle in the crusades was that the Europen Knights relied
> on the strength of their arms to weild their swords where the Saracen
> Knights depended on the sharpness of their swords. This distinction should
> not be lost by the modern software warrior.
>
> One of the things that nearly drives the windows programmer "nuts" is the
> almost endless shovelling through interface components and keeping track of
> what has been used and what must be de-allocated. We have already explored
> the method of using bitmap buttons and producing the correct background
> colours from the system colours.
>
> Now we produce the function that does it all in one place, make the buttons,
> change the colours when the user does something so vulgar as change the
> system colours while your program is running and finally trash all the
> bitmap handles on exit.
>
> It is a standard 3 way split using two If blocks to deliver the three
> options,
>
> 1. create the buttons at startup.
> 2. delete the old bitmaps and create new ones when the colour is changed.
> 3. delete the bitmaps on program exit.
>
> Something that is important, the bitmap handles MUST be global values
> othwise they will not be "seen" next time you call the function and you will
> end up with a pile of dead bitmaps so put them in the header file.
> ----------------------------------------------------------------------
> FUNCTION Toolbar_Buttons(Opt as LONG) as LONG
>
>     ' Opt = 1  Make Em      called at startup.
>     ' Opt = 2  Change Em    called from WM_SYSCOLORCHANGE message.
>     ' Opt = 3  Trash Em     called from WM_CLOSE message.
>
>     If Opt = 2 or Opt = 3 then
>       rv1=DeleteObject(hBmp1)
>       rv2=DeleteObject(hBmp2)
>     End If
>
>     If Opt = 1 or Opt = 2 then
>       hBtn1=BmpButton(0,0,29,29,hWnd,110)
>       hBmp1=LoadBitmap(hInstance,"BMB1")
>       hBmp1=SetBmpColor(hBmp1)
>       SendMessage hBtn1,BM_SETIMAGE, 0, hBmp1
>
>       hBtn2=BmpButton(29,0,29,29,hWnd,111)
>       hBmp2=LoadBitmap(hInstance,"BMB2")
>       hBmp2=SetBmpColor(hBmp2)
>       SendMessage hBtn2,BM_SETIMAGE, 0, hBmp2
>     End If
>
>     FUNCTION = 0
>
> END FUNCTION
> ----------------------------------------------------------------------
> Once you have this one up and running, all you need to do is write 4 lines
> of code to to create a bitmap button in the second If block and one line of
> code to delete it in the first If block and you can add buttons to your
> heart's content without having to worry about a nightmare of hard coded
> allocations and de-allocations.
>
> You make the function call to create the buttons after the CreateWindowEx()
> call in your WinMain function so that you have the handle but before the
> ShowWindow() call so that you don't see the yukky flashes as they are
> created. The second and third calls are processed in the WndProc function
> as normal messages.
>
> A little secret if you wish to make the Display Properties dialog box very
> sick and unhappy is to call a system dialog box in your function to test the
> return values of DeleteObject(). It locks up and needs a three finger salute
> to select it and close it and it does not display properly until the next
> restart of Win Doze. Stunning OS design you may say.
>
> To retrieve the client area co-ordinates of a control should be a simple
> function call but M$ did not bother to write one so the programmer must
> write their own. It is a good example of how to get 4 values back from a
> single function call by passing the address of a RECT structure.
>
> With the following function you set up the rectangle structure / data type.
>
>     RECT Rc; ---- in C
>
>     LOCAL Rc as RECT ---- in basic.
>
> Then call the function,
>
>     void=GetCtrlRect(hCtrl1, Rc)
>
> Once the function has returned, you have the four value in the rectangle
> structure / data type. Note that C and Basic are slightly different in
> their notation for both RECT and POINT structures.
> -----------------------------------------------------------------------
> FUNCTION GetCtrlRect(hCtrl as LONG, Rc as RECT) as LONG
>
>     LOCAL Rct as RECT                    ' Rectangle for GetWindowRect().
>     LOCAL Pt  as POINTL                  ' Point for ScreenToClient().
>
>     GetWindowRect hCtrl, Rct             ' Get co-ordinates in Rct.
>
>     Pt.x = Rct.nLeft                     ' Top x & y co-ordinates in Pt.
>     Pt.y = Rct.nTop
>
>     ScreenToClient GetParent(hCtrl), Pt  ' Convert to client co-ordinates.
>
>     Rc.nLeft   = Pt.x                    ' Put client area co-ordinates
>     Rc.nTop    = Pt.y                    ' into RECT structure / data type
>     Rc.nRight  = Pt.x + (Rct.nRight - Rct.nLeft)
>     Rc.nBottom = Pt.y + (Rct.nBottom - Rct.nTop)
>
>     FUNCTION = 0
>
> END FUNCTION
> -----------------------------------------------------------------------
> If you like doing cheeky things with an application's interface such as
> dynamically moving controls around, you can use these co-ordinates in a
> MoveWindow() function to re-position the control.
>
>   ref=1
>
>   label:
>     void=MoveWindow(hCtrl1,Rc.nLeft + ref,Rc.nTop, _
>                            Rc.nRight + ref,Rc.nBottom,%TRUE)
>         tc=GetTickCount()
>         do
>         loop until GetTickCount() > tc + 10  '10 millisecond delay
>     ! inc ref
>     ! cmp ref, 200
>   ! jne label
>
> This code fragment will move your control 200 pixels to the right with a
> ten millisecond delay between each move so that the movement can be seen.
> MoveWindow() is another one of the fast low level functions that is very
> useful in arranging things on the screen. SetWindowPos has the additional
> capacity to set the Z order (buzz term for top to bottom windows) but it
> is not as fast.
>
> The point of addressing function design is that you will write many of them
> in your time and it is how well you write them that will determine how
> useful they are when you need them. One thing you will find working with
> windows APIs is just how "ad hoc" they are with some passing ascii Z strings,
> others passing pointers to ascii Z strings and with many other unpredictable
> variations.
>
> The notion of function cracking is alive and well working with windows APIs.
> Get used to the idea that they do not always behave as they are documented
> and have to be experimented with to get them to work properly and this will
> tune you to writing you own with much greater consistency.
>
> One of the plusses in shovelling through the endless boredom of interface
> design and layout is the familiarity that you gain with using the windows
> API functions. As more and more of this stuff sinks in, the task of reading
> your own assembler dumps will start to become a lot easier as you recognise
> the function by its name and understand what the parameters are that are
> being pushed onto the stack.
>
> The Resurrectionists
> ~~~~~~~~~~~~~~~~~~~~
> Knowledge of human anatomy is an area that was hard won against the flow of
> historical social values in many different societies over time. Many
> different cultures over time have placed restriction on the handling of
> human remains for a multitude of different reasons.
>
> This did however place boundaries on those who undertook one of the truly
> noble tasks of history and that was healing the sick and injured. In the
> late eighteenth and early nineteenth centuries, the demand for knowledge of
> anatomy gave rise to the practice of grave robbery, not for any artifacts
> that may have been interred with the deceased but for the actual physical
> remains.
>
> In the eighteen twenties, the Royal College of Surgeons in Edinburgh were
> paying the extraordinary sum of about ten pounds for a servicable (?) body
> that could be used by the students to learn anatomy. Those who practiced the
> trade of robbing graves which was known as "resurrectionism", (raising the
> body from the grave), had an easy source of income if they could keep up the
> supply of bodies.
>
> While this conjures up macabre images of desperate men scouring the burial
> places of Scotland in the blinding rain and freezing cold in the middle of
> the night to fuel this trade, it fades into insignificance in comparison to
> the practices of Burke and Hare who were willing to assist the living in
> their demise to supply the trade.
>
> The murder of Mary Docherty was their undoing and when the police started
> questioning, Hare ratted on Burke to save his own neck and confessed to
> sixteen other murders that he and Burke had committed that year. Burke went
> to the gallows in January 1829 and his own body was used for an anatomy
> lesson the following day.
>
> The great loser was Dr. Robert Knox whose career was ruined through the
> actions of Burke and Hare yet in the longer term, the knowledge that was
> gained in the field of anatomy was the basis for modern surgery where
> routine reconstructions of near miraculous proportions occur on a daily
> basis.
>
> The Surgeons of "Sick" Software
> ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
> The anatomy of binary software structures is an important area of knowledge
> that has been hard won by pioneers in the field of reverse engineering and
> it has not been without considerable risk. Reverse engineering commercial
> programs brings cries of "Piracy" yet as most know, the majority of this
> stuff is like learning anatomy from the bodies of the dead, even if the
> vendors of this junk don't want to admit it.
>
> Use of this type of knowledge to steal a competitor's product and try and
> sell it for a profit as Microsoft did with the Stacker product is a clear
> case of software piracy whereas making the same accusation about programmers
> learning from this knowledge to design better and more robust software is
> nonsense.
>
> A program that will run on a computer is "cracked" every time the operating
> system's loader places it in memory and this is the basis for the normal
> process of reverse engineering, if it didn't run, it would be far more
> difficult to "crack" but then it would not be of any use. The difference
> between a good protection scheme and a bad one is an equation based on "how
> long" it takes to crack it, not whether it can be cracked or not.
>
> It is hard to overstress just how important it is to understand what your
> program looks like in assembler. Without that knowledge, your program is
> dead in the water waiting to be "hacked", not even "cracked". Any hacker can
> open your program in a hex editor and rewrite trivial data.
>
> Rule number one, never, never, never put a protection scheme in a function,
> this is a 5 minute crack. Grace it through your favourite "software in
> circuit emulator" and when the security test is made, you grab the address
> in the module and its name.
>
> Dump the module with your favourite dis-assembler and locate the function
> and the game is just about over. Don't even bother to read the function, go
> to the end of it and look at the return value in eax. If it says something
> like [ mov eax, 1 ], open the module in a hex editor, do a search using the
> opcode pattern close to the instruction and when you find it, twiddle 01h
> to 00h.
>
> Save it and more often than not, when you run the program it will say,
> "Thank you for registering our product... platitudes, bullshit, grovelling,
> etc".
>
> From a well known piece of liturgy comes the phrase,
>
>    "From thence he shall come to judge the quick and the dead"
>
> If you protection scheme is written like this, your dead.
>
> Mid function comparisons don't fare much better, same trick finding the
> function, look for,
>
>    mov reg, value1
>    cmp reg, value2
>
>   look at the jump instructions after it and you will see what the choices
> are, if it is a [ je label ] then twiddle it to [ jne label ] and its all
> over. Everything except your password / key will then work. There are
> variations but the logic is the same.
>
> This type of programming qualifies for membership in the Mickey Mouse Club.
> There is in fact a much better way and it has more to do with understanding
> other human beings that writing amateur hour protection schemes. Most learn
> that the pursuit of "Mickey Mouse Club" style protection schemes is a market
> driven process from those who wish to sell you some junkheap envelope system
> for money.
>
> The truly uncrackable program is one that has nothing in it to crack. If
> you have a product that you think is worth selling, compile two versions of
> it, the "lite" demo version and the "full" version. For the cost of some
> additional coding to use the conditional compilation instructions, you can
> use the same code and simply dial in the functionality of the full version.
>
> The person who could get the additional functionality out of your program
> would not be cracking it, they would be re-writing it.
>
> Marketing Your Program
> ~~~~~~~~~~~~~~~~~~~~~~
> When a user downloads you demo application, if they like it, they will keep
> using it where if it squawks at them and shows nag screens, it will most
> probably get reverse engineered in the most efficient manner by converting
> your program to free disk space with the delete key. If it is well written
> and not offensive to the user, you have a good chance of them wanting to
> purchase a version with more features.
>
> Its worth looking at what the economics are of the technique of getting some
> pile of junk onto a shovelware CD, conning a user into trying it out with a
> collection of inflated claims and when they get it up and running, it shows
> nag screens, beeps, time delays/limits and function crippling.
>
> What they are doing is cutting down their distribution costs, getting their
> junkheap onto a user's machine by stealth and using coercion to try and
> force a user to part with hard currency for a program without them even
> knowing whether it runs properly. This type of marketing is sheer stupidity.
>
> If you offer a user a fully functional "light" version that is actually
> useful, they get to see your program a lot of times and you will find that
> an honest and open approach is far more appreciated by a prospective
> customer than the ugly and insulting approach that is used by the trashy
> end of the market.
>
> Identify yourself with an end user and you will better understand what the
> deal is. When somebody clicks on a link or runs a setup from a junk CD, they
> do so with some expectation that they may find something that is actually
> useful to them. We have all done this and found that after running the setup
> that you have some crippled heap of junk that has messed up you registry,
> squawks desperate money grovelling messages at you and does not run properly.
>
> If you can identify with this problem, don't do it to other people or they
> will treat your program as you treat programs like that, with distain and
> the most rapid removal technique possible. Always remember that it is
> another human being that you are dealing with and they deserve the respect
> that you expect for yourself.
>
> Use a non offensive About Box and make them a real good offer to upgrade to
> the full version and you have hit the market about as well as it can be
> done. Pressure cooker coercion is a good way to shoot yourself in the foot,
> offend the user and they will delete you program and use something else,
> even if it is not as good as your program. Exercise goodwill with your
> prospective customer and it will be returned to you.
>
> The Cost
> ~~~~~~~~
> There is a phenomenon in economics called "elastic demand", effectively
> the idea is that if a product or commodity is within the price range of a
> purchaser, they may purchase it if they think they have a use for it or like
> it. As the price increases in relation to their purchasing capacity, the
> demand drops on a priority basis.
>
> When you try and sell a product, take the big picture about the market and
> learn from it. In a world where there are tetrabytes of software to try out,
> overpricing your product is a garranteed way to kill it. Selling a thousand
> items at ten dollars generates more income that selling ten items at a
> hundred dollars and you have a lot more happy customers.
>
> The alternative to elastic demand is called "in-elastic demand", the types
> of products that no-one can do without. Food, fuel and electricity are
> examples of necessary commodities that have an in-elastic demand.
>
> The trouble that Microsoft is just starting to get into with the action
> being taken against them by the Department of Justice is based on the method
> by which it has manipulated an "elastic demand" into an "in-elastic demand"
> by using illegal means to destroy their opposition in what is supposed to
> be an open market.
>
> This is leverage marketing which is illegal under many jurisdictions around
> the world. A good example of how the problem should be fixed is the case
> where Intel were not allowed to exercise monopolistic control over the
> processor market. By allowing Cyrix and AMD to compete on the market, Intel
> has remained a viable and competitive company and the winners are computer
> users around the world.
>
> This is in fact the model that will have to be inflicted on Microsoft as
> they have made it clear that they will fight to maintain their monopoly
> status by any means posible. If Bill and the boys and girls at Microsoft
> got off their butt and started to write good software again, they may even
> save Microsoft from the trouble that they are in but it would not be wise
> to hold your breath waiting.
>
> Keeping The Crackers Amused
> ~~~~~~~~~~~~~~~~~~~~~~~~~~~
> Fore those who really and truly want to give the crackers something to do on
> a cold night when they have nothing better to do than watch television or
> catching up on their sleep, start by looking for a compressor, they are
> starting to hit the market for win32 programs. By themselves, you only get
> temporary relief as there will always be a decompressor developed for it.
>
> The next trick is to check the length of the file. Write the code to either
> read the directory listed file size or simply open it and read the length
> and then hard code the length of the compressed file into the code. This
> means that if it is decompressed, it simply will not run if you write the
> code to do so because the length is wrong. This is also useful as a type of
> virus protection.
>
> The next trick is don't tell the cracker that they have failed, let the
> program crash so that they have to work out why. Give some thought as to
> the sequence of what the instruction pointer follows, if your length check
> is immediately followed by an instruction to terminate the program, it can
> easily be nop'ed out (90h), trash it further down the instruction sequence.
>
> At its basics, an executable program is one big bag of binary where a lot of
> the numbers are critical to its operation. Interlock you reference numbers
> into the critical numerical data in the program and if the reference numbers
> are wrong, the program will crash without a "trashit" instruction. The
> options are nearly limitless, particularly if the methods are ideosyncratic.
>
> This produces an increase in the order of complexity needed to crack the
> program. If the design is good enough, you may even force the cracker to
> take the dead listing approach but it is here where your program gets into
> trouble as a patient and skillful eye will follow the code until they find
> what is happening.
>
> If you provide the cracker with a couple of hours of amusement, they will
> respect your efforts for actually having written some good code but your
> win is that the amateur "hacker" will not have the talent to steal your
> program. There is in fact, no formula that works as everyone would learn it
> and it would not work any longer.
>
> Originality and complexity are what you have going for you if you choose to
> use it for if it takes years to break it, it won't matter by then. While
> the rush has been towards RAD front end generators, the type of code that
> they generate is not adjustable at the low level that is required to protect
> software from relatively low skill "hacking".
>
> The Velvet Glove
> ~~~~~~~~~~~~~~~~
> Now for a special class of ancient warrior, all those "femme fatales" out
> there who have done it hard in the complex arenas of operating system level
> assembly, application programming in C or whatever else, never underestimate
> the value of your knowledge and years of experience for you have much to
> offer to a new generation of software warriors.
>
> The models of history serve the "femme fatale" warrior well, Boedicia left
> her mark in history as many roman legionnaires found out, the Vedic period
> literature of ancient India had an incarnation of deity called Shiva, the
> Destroyer and Renewer which was also known in the feminine form in the
> Goddess Kali.
>
> Joan of Arc, the french patroness, was a warrior so formidable that when she
> was captured by the Burgundians, she was sold to the English and was later
> burnt at the stake at the age of nineteen for a trumped up charge of heresy.
>
> For those "femme fatale" warriors who have spent years hardening their
> formidable skills as software woriors, pass Excalibur as the Lady of the
> Lake passed it for the quest is a noble one that is worthy of your effort.
> The modern warrior who understands the iron fist that wears the velvet glove
> will write well balanced and better software for the effort.
>
> THE IRON FIST
>

---

+HCU papers

---

homepage links anonymity +ORC students' essays academy database
antismut tools bots & agents reversing cocktails javascript wars search_forms mail_fravia
Is reverse engineering illegal?