courtesy of reverser's page of reverse engineering
10 June 1998
SLH's sixth paper
The iron fist
"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."
SLH is back again with another (the sixth) of his small masterpieces: You would be well advised to read
all the preceding parts of what is going to be a DEFINITIVE HCU MANUAL INTRODUCING
WINDOWS DISASSEMBLING: it's a concentrated very good
course about the UTMOST IMPORTANCE of assembling
in everyday windows (or whatever) programming. This will help you, among other
things :-) in order to
the purposes (and the power) of what we are all doing here...
|08 May 98||
The supression and resurrection of assembler programming.
|16 May 98||
||The Bridge: In Pursuit Of Lost Knowledge
|21 May 98||
||THE QUEST: Building the launch pad
|29 May 98||
||Software warriors through the warp
|05 June 98||
||The Eye Of The Warrior (a "graphical" windows' paper)
|10 June 98||
||The iron fist (Keeping The Crackers Amused)
And here you go... Enjoy!
> 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
> 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
> 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
> End If
> If Opt = 1 or Opt = 2 then
> SendMessage hBtn1,BM_SETIMAGE, 0, hBmp1
> 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.
> void=MoveWindow(hCtrl1,Rc.nLeft + ref,Rc.nTop, _
> Rc.nRight + ref,Rc.nBottom,%TRUE)
> 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
> 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
> 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
> 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
> 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,
> 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
bots & agents reversing
Is reverse engineering illegal?