+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?