_
L×# û# ƒ$5 <"""" B2 ^Z ÄX
äX PZ PZ PZ PZ
¬A.... 8 PZ
Howto42
The little boxes you see in the left corner wind Microsoft's explorer down :-)
HOW TO CRACK, by +ORC, A TUTORIAL
Lesson 4 (2):Time protections, part 2
A little Micro$oft bashing :=)
[MS-WINPROJECT] [MS PUBLISHER 97] [MS-MONEY 94] [MS MONEY 97]
(Hic sunt tabulae: Best viewed with good old Courier New 8)
Well well well, my dear friends, it's April, the "opening"
month, when trees unfold and the womb of nature opens with young life...
about time we start with the REAL work, and what I mean is that we
begin damaging Microsoft interests... the real ones. I will therefore
teach you here how to crack Microsoft's ubiquitous "trial version
time protection".
The typical Micro$oft's trial limit (of three months) is a
clever marketing approach per se: I'm speaking of the "trial" version
of their programs that you are supposed to use and enjoy for 90 days,
until a screen reminds you that you WILL not be able to use it any more,
coz the 90 days are over, please pay. Note the clever touch of 90 (instead
of 30) days: three months are more than enough to get you real hooked on a
program, especially huge monstrosities of the complexity of MS overbloated
applications... it's a much better period than the usual "30 days"
flavour that we find around in common shareware.
Since Micro$oft makes the bulk of its money from software
sold to corporate executives, senior sparer and assorted yuppies, it
suits us well to crack as first example of this lesson, Microsoft PROJECT,
one of those ridiculous "yuppie" programs that allow you to "plan"
and "schedule" an activity or a project of your "team"... as if we
were all time-slaves like those idiots... besides I may as well use this
crap to program the nice "activities" of my +HCU's cracking units :=)
I'm therefore cracking here the 90 days trial version of
MSOFFICE WINDOWS PROJECT Version 4.1 of august 1995 which has the
protection hidden inside the monstrous WINPROJ.EXE (4.240.896 bytes of
overbloated bad programming). The error and protection messages dwell inside
winproj.DLG (overbloated dialogues of 1.179.822 bytes).
We'll begin with this somewhat "older" example of the ubiquitous
"MS-trial" protection scheme (from 1995), since, as I have already told
you elsewhere, the *history* and the *evolution* of protection schemes
are powerful additional WEAPONS, that a cracker can use to defeat
more complex schemes that may not be so evident if you cannot recognise
their "physiognomy" at the first glance (or if you do not yet "feel" them :=)
We'll crack in this lesson a Microsoft program from 1994, another one from
1995 (this first one) and two from 1997. I believe this should give you a
wide enough palette of MS-protections, and that with this knowledge you
should be able to crack every single piece of software Microsoft may throw
at you in the next couple of years (at least :=)
You'll see for instance that the "cmp eax,ecx" instruction
at the heart of some of these MS-schemes is a constant characteristic,
that you'll meet again and again, which differs from the typical "beggar off
on bad flag ax" setting that the shareware authors usually use.
A SMALL THEORETHICAL DIGRESSION
First of all, before entering the guts of MS-cracking, a small "theoretical"
digression.
From a cracker's point of view, the new "trend" to give away full time
limited versions of a software packages is extremely interesting:
once you defeat the time checking routines (... plural coz there may
be much more than one inside the same program) your work is done and
you'll immediately enjoy the full application.
The reason behind this trend (from password to time-trial)
is quite simple: password-serial number protections are useless on a Web
which abounds with free pirated serial number listings (I saw one with 54.000
different serial numbers-registration strings couples!) that anybody with
intelligence level "amoeba" can easily find. I do not like serial number
collectors: they do not teach anything, in my (admittely biased) opinion they
just steal... fact is anyway, that the mere existence of such huge
ready-made password listings has nuked any programmer's confidence in the
serial/string protection approach (whose cracking techniques I have explained
elsewhere in this tutorial), and this is the more true for "commercial"
(i.e. "non toy") applications.
You will find therefore, for big commercial application, the
"Cinderella" protections (you may use this app for 30 days) or
the "quiver" protections (you may use this app 30 times), or a combination of
these two kinds, or a combination of both kinds PLUS the registration
string/serial number protection method.
One of the (minor) problems for us nice crackers is that
with this kind of protections we may have some surprises later on... i.e. you
crack your target and it works fine... well past the date it should have
been crippled upon, WHEN YOU SET this DATE INSIDE YOUR OS but -alas!- it stops
miserably working WHEN THE REAL TIME "of the world" has passed that cap...
this has to do with OTHER protections, checking randomly, for instance, the
date of some UNRELATED FILES on your hard disk.
Obviously this does not concern us much... as soon as this
happen we crack this "second level" protection scheme too, happily drinking
another Martini-Wodka (use only Moskowskaja and add some Indian tonic
Schweppes and a zest of lemon if you want to taste something
that's really good) and forget the whole incident... but I had
to mention it right now because I honestly DO NOT KNOW YET if
some of the programs that I'll crack in these lessons do have or
not such additional protections, nor have I the time to feel if
there are other protections inside overbloated 5 million bytes
horrors once I have already found the first (and maybe only) one,
nor have I envy to wait 90 days just to see if something else
snaps... should it happen (which I DO NOT believe, seen how
primitive MS-protections look like) I'll then simply add the new
crack to this section, we'll see.
---------------------------------------------
Some elementary MUST KNOW when you crack time protections:
Date and Time stamps in the root directory (old flavour)
The root directory (in DOS) is a simple table of 32-byte
entries, defining each file on the root directory. Bytes 0-7 have
the file name, 8-10 have the file extension, 11 hydes the
attribute flags, 12-21 are at times used for other protection
tricks, 22-23 have the *TIME* stamp, 24-25 have the *DATE* stamp,
26-27 the starting cluster number and 28-31 the file size.
The date and time stamps can record any date from January
1, 1980 through December 31, 2099. The time stamp is accurate to
two seconds. The date and time stamps are each 2 byte values that
are recorded by using the following equations:
DATE = DAY+64*MONTH+512*(YEAR-1980)
TIME = SECONDS/2+32*MINUTES+2048*HOURS
In the time entry, the hour occupies the first 5 bits, the
minutes the next 6, and the second the last 5. The seconds are
actually stored as the number of seconds divided by 2, so the
clock is accurate to 2 seconds. In the date entry, the year
(subtracted from 1980... that is 0x7bc) is stored in the first
7 bits, the month in the next 4 and the day in the last 5 bits.
How do we recover these values? Here the commonest tricks:
seconds AND byte 22 with 11111; then multiply by 2
Minutes AND byte 23 with 111; then shift left 3 and
add byte 23 shifted right 5
Hours Shift byte 23 right 3
Day AND byte 24 with 11111
Month AND byte 25 with 1, Multiply by 8 and
add byte 24 shifted right 5
Year Add byte 25 to 1980 (0x7cb) and shift right 1
I hope you have the intelligence to understand by yourself
why these methods work... the point is that as soon as you see
something like that going on in the code you are examining, you
will know that they are fiddling with date or time stamps (may
be necessary, for instance, in order to reset the date and time
stamps of an opened file without leaving any trace behind).
How does a programmer fetch the date? He uses the _dos_getdate
function.
The _dos_getdate function uses system call 0x2A to get the
current system date. The date information is returned in a
dosdate_t structure pointed to by date.
Synopsis:
#include [dos.h]
void _dos_getdate( struct dosdate_t *date );
struct dosdate_t {
unsigned char day; /* 1-31 */
unsigned char month; /* 1-12 */
unsigned short year; /* 1980-2099 */
unsigned char dayofweek;/* 0-6 (0=Sunday) */
};
-------------------------------------------------------
AND NOW RUB YOUR HANDS: TO WORK!
And now rub your hands: to work! Fetch your copy of the
time limited version of Winproj.exe (you'll find it on the
web... many magazines in Europe have published it on their cover
CD at the beginning of this year... The one I use here is taken
from a second-hand French magazine I found in Basel some time
ago: PCMAG n.108)
Well how do we proceed?
As usual: Let's dead list everything (but you could get pretty
quickly to the "hollow" point of your target through winice, is
a matter of aesthetic choice, I prefer dead listing because it
is more "relaxed" but you may use a combination of both
approaches or whatever you like most).
First thing you notice is that the dead listing is HUGE:
more than 50 megabytes of text. You'll need a good wordprocessor
to handle that... Microsoft's last one, word version 7.0 does not
even accept such files, but look! Word 2 (the old version of
Word, 1992 vintage) does run them (almost) without problems (you
would not -obviously- have such problems under dos or linux).
It's quite ironic, I believe, that Word 7 cannot open such a
file, but on the contrary Word 2 ('92 version!) is capable of
doing it... this confirms what I always supposed: huge
overbloated programming is getting worse and worse... humanity
has probably already entered one of its many phases of decadence
:=)
LET'S SURPRISE THE PROTECTION SCHEME FROM BEHIND
We can get to the protection scheme of this target in many ways
(and there are yet many more... almost as many as you fancy).
Usually, to defeat these protections the traditional approach is
to set the OS date past the trial period, run the target,
individuate the nag screen as soon as it snaps, get the maximuml
information about it (comprised its pixel dimensions) and then
breakpoint it using some of these data) for instance (with
winice) bpx on MessageBox (MessageBoxA to be exact). Remember
that with Godot (Winice 3.0), you can use CONDITIONAL
EXPRESSIONS! Say that the hwnd command gave you 09017E as handle
for the nagscreen (this value will be different EVERY time you
run your target), then you can selective breakpoint on it with:
:bpx MessageBoxA IF ((ESP->4) == 09017E)
since all Win32 applications pass parameters on the stack
enetering a function and the first parameter has a positive
offset of 4 from the ESP register.
Then you track back to the responsible code and so on and so
on... since the protectionists are aware of these obvious "weak"
points in their schemes, their "defences" will be all
concentrated on this "path" (encrypted date compares far away
from the messagebox call, bogus jumps, fake routines etcetera)...
they'll try to defer people reverse backtracing to the protection
scheme from the nag screen.
We will therefore hack our way to these protections sneaking
in from more hidden, less used and and less obvious doors, like
(in this example) GetLocalTime or (as we'll see later) through
the various "Write and read" file routines (i.e. the _open,
_lseek and _read routines that the protection schemes use to
fetch from the registry (or from somewhere else) the encrypted
date of installation. The point is to take our target's
protection schemes by surprise, from "behind" :=)
OK: First of all... we have to do with a time protection,
duh, therefore GetLocalTime is a first bait we can jolly use,
let's see if we fish anything thattaway:
------------------------------------------------
* Referenced by CALLs at Addresses:
|:05024FBE, :05024FF0, :05035A05, :0506489C, :0511A2A4,
|:05167F6A, :05167FC1, :051F9E77, :05204C54, :05223F14,
|:05223F81, :05224013, :05271A72
|
:05024E77 55 push ebp
:05024E78 8BEC mov ebp, esp
:05024E7A 83EC10 sub esp, 00000010
:05024E7D 8D45F0 lea eax, [ebp-10]
:05024E80 50 push eax
:05024E81 FF15905E3C05 Call dword ptr [053C5E90]
*GetLocalTime,(Kernel32-E2h) ;HERE!
------------------------------------------------
PARAMETERS inside Windows' FUNCTIONS
After this call the program must save the time parameters: for
those of you that do not know anything, the typedef structure is
the following one... (VERY IMPORTANT FOR TIME PROTECTIONS! Learn
it by heart! It's used in many other various FileTime routines
too):
------------------------------------------------
WORD wYear
WOED wMonth
WORD wDayOfWeek
WORD wDay
WORD wHour
WORD wMinute
WORD wSecond
WORD wMilliseconds
------------------------------------------------
Why did we seek GetLocalTime? Because the protectionists have
to know somehow if the program run over the allowed time and,
while there are many other methods to do this, one of the most
simple is a check through good humble GetLocalTime... so we'll
begin from here, ready to check all other possibilities only if
we do not fish anything with this bait.
Examining the savings of the return values from this routine, as
with many other time routines, you'll find in your dead listing
something like this:
------------------------------------------------
CALL [KERNEL32!GetLocalTime]
mov dx, [EBP-10] that's the year, will be something like
7CD=1997
mov dl, [EBP-0E] the month... lower part of a register is enough
mov al, [EBP-0C] that's the day of the week, ditto
mov al, [EBP-0A] that's the day
mov dl, [EBP-08] that's the hour
mov al, [EBP-06] that's the minute
mov dl, [EBP-04] that's the second
and if somebody would care, you would have had also
mov dx, [EBP-02] that's the millisecond, but few time
protections care for that (which is stupid to say the least,
since so many ideas come immediately to the mind :=)
------------------------------------------------
I said "something like" the above, but things could differ
a little coz the count [EBP-xx] could be flawed by pushes and
then you would have something like -say- the year in [EBP-34]
and, accordingly, the month in [EBP-32] et cetera... anyway the
SERIE will always be respected, therefore you could also crack
these protection in a completely different (and easy) way, that
good old +ORC will now let you glimpse... simply set a breakpoint
on a user routine (study this part of winice documentation
WELL... you'll be able to crack almost ANYTHING with your own
breakpoint routines)... say when the target loads for instance
7D5h on ax OR on dx (you will not know which of both registers
the protection scheme use).. then simply run the program with the
changed os date 2005 (which is 7D5h) and see what happens...
you'll breakpoint smack in the middle of the protection scheme
:=)... Why use 2005 instead of 1997? Easy: we wont use the
current year (7CD=1997) nor the next couple of years, because the
protectionists oft use other unrelated variables with those same
values (say current year of release and a couple year more) *on
purpose*, to block these very attempts. But, as I said, we do
not need to use winice to crack this cram... bear with me and
see.
Let's be more technical: you have reached a level where you
have the right to UNDERSTAND exactly how to access parameters
(i.e. the fixed values that MUST be passed to a function) and
local variables (i.e. the values that the protectionists have
decided to use, say in order to compare or manipilate) inside
windows calls:
- If you set a breakpoint at the exact function address, for
example, :BPX GetFileTime, use ESP+(param#*4) to address
parameters, where param# is 1, 2, 3, or whichever parameter that
function calls... Since BOOL GetFileTime(HANDLE hFile, LPFILETIME
lpCreation, LPFILETIME lpLastAccess, LPFILETIME lpLastModified)
you'll easily know what is what.
- If you set a breakpoint INSIDE a function body (after the
full prologue PUSH EBP, MOVE EBP,ESP, SUB ESP,size (locals) has
been executed)use EBP+(param#*4)+4 to address parameters.
- Once the space for local variables is allocated on the
stack, the local variables can be addressed using a negative
offset from EBP. The first local variable is at EBP-4... with two
pointer local variables (typically dword sized) one will
therefore be at EBP-4 and the other will be at EBP-8.
Comprendes?
Enough... back to our calls to GetLocalTime... see how the
"centralised" call approach of windows helps us a lot... all the
calls of the program to this routine are here under our eyes...
look at the 13 CALL references, once more, (THIS IS IMPORTANT)
look at WHERE they come from:
* Referenced by CALLs at Addresses:
|:05024FBE, :05024FF0, :05035A05, :0506489C, :0511A2A4,
|:05167F6A, :05167FC1, :051F9E77, :05204C54, :05223F14,
|:05223F81, :05224013, :05271A72
|
:05024E77 55 push ebp
:05024E78 8BEC mov ebp, esp
:05024E7A 83EC10 sub esp, 00000010
:05024E7D 8D45F0 lea eax, [ebp-10]
:05024E80 50 push eax
:05024E81 FF15905E3C05 Call dword ptr [053C5E90]
*GetLocalTime,(Kernel32-E2h)
A LITTLE ZEN: FEELING THE CALLS OF THE SEA
Ok, let's see which sectors of our target do actually call our
bait GetLocalTime... look at the call references above! Out of
13 calls, Sectors "024F" and "167F" and "223F" call it twice,
whereby Sectors 035A, 0648, 11A2, 1F9E, 204C, 2240 and 271A call
it only once.
This may not mean anything, of course, but hey! on the other hand
it could be very interesting... clearly we'll examine FIRST what
happens in these "time-intensive-calling" parts of the code:
Let's begin.
1) "Sector 024F" calls GetLocalTime twice, why?
:first_call_snippet_(called_from_:0504A3F7)_calls_at_024FBE
:05024FA4 55 push ebp
:05024FA5 8BEC mov ebp, esp
:05024FA7 83EC0C sub esp, 0000000C
:05024FAA 53 push ebx
:05024FAB 8D45F4 lea eax, [ebp-0C]
:05024FAE 8B1D04452C05 *** mov ebx, [052C4504] ;get holyloc
:05024FB4 50 push eax
:05024FB5 885DFE mov [ebp-02], bl ;create holylow
:05024FB8 887DFF mov [ebp-01], bh ;create holyhigh
:05024FBB C1EB10 shr ebx, 10 ;create holyshr10
:05024FBE E8B4FEFFFF *** call 05024E77 GetLocalTime ;FIRST CALL
:05024FC3 8A45FE mov al , [ebp-02]
:05024FC6 3845F6 *** cmp [ebp-0A], al ;month=holylow?
:05024FC9 7512 jne 05024FDD ;flag 1
:05024FCB 8A45FF mov al , [ebp-01]
:05024FCE 3845F7 *** cmp [ebp-09], al ;day=holyhigh?
:05024FD1 750A jne 05024FDD ;flag 1
:05024FD3 66B80000 mov ax, 0000 ;flag 0
:05024FD7 66395DF4 *** cmp [ebp-0C], bx ;year=holyshr10?
:05024FDB 7404 je 05024FE1 ;keep flag 0
:05024FDD 66B80100 *** mov ax, 0001 (flag 1: day or month
or year differ)
:05024FE1 5B pop ebx
:05024FE2 8BE5 mov esp, ebp
:05024FE4 5D pop ebp
:05024FE5 C3 ret
:second_call_snippet_calls_at_5024FF0
:05024FE6 55 push ebp
:05024FE7 8BEC mov ebp, esp
:05024FE9 83EC08 sub esp, 00000008
:05024FEC 8D45F8 lea eax, [ebp-08]
:05024FEF 50 push eax
:05024FF0 E882FEFFFF *** call 05024E77 GetLocalTime ;SECONDCALL
:05024FF5 0FB64DFB *** movzx byte ptr ecx, [ebp-05] ;savepar
:05024FF9 0FB645FA *** movzx byte ptr eax, [ebp-06] ;savepar
:05024FFD C1E108 shl ecx, 08
:05025000 0BC8 or ecx, eax
:05025002 0FB745F8 *** movzx word ptr eax, [ebp-08] ;savepar
:05025006 C1E010 shl eax, 10
:05025009 8BE5 mov esp, ebp
:0502500B 0BC8 or ecx, eax
:0502500D 5D pop ebp
:0502500E 890D04452C05 *** mov [052C4504], ecx ;save in holyloc
:05025014 C3 ret
Quite interesting... a flagging (that could be a green
light) and some parameters saved and compared within a holy
location... why does this "sector 024F" call? Is it just checking
against an holy location IF the time has changed enough to
justify the snapping of other routines? Or is it this the part
of the code that encrypts the date in the holy location
itself?... We could follow this path, and "freeze" the holy
location, or explore who calls this code snippets... this would
bring us to the protection scheme as well of course... but this
kind of work -MADE NOW- would not be methodologically correct...
YOU SHOULD INDEED NEVER GO ASTRAY... KEEP YOUR CRACKING APPROACH
(as long as you do not get obvious signs that you found what you
were looking for), it's like landing a plane... keep the original
approach and DO NOT delve inside everything you happen to notice
that "might" be a treffer! Here we have something "biting" the
hook (our worm is GetLocalTime), but it's not yet time to pull
out our fishing line yet.. let's continue... We were
investigating all sections of our target's code which effectuate
at least a double call to GetLocalTime... let's continue! Let's
have a quick look to the other two "twin" occurrences of
GetLocalTime (167F and 223F) before delving inside any one of
them... maybe we will not need to delve at all. Remember, always
concentrate on ONE approach at a time: multa agendo nihil agens!
Here the second "twin calls" location area:
2) "Sector" 167F calls GetLocalTime, why?
:05167F6A E808CFEBFF call 05024E77 ;CALL GetLocalTime
:05167F6F 66817DF4C007 cmp [ebp-0C], 07C0 ;is 1984?
:05167F75 722F jb 05167FA6 ;go badflag
:05167F77 66817DF40108 cmp [ebp-0C], 0801 ;is 2049?
:05167F7D 7727 ja 05167FA6 ;go badflag
:05167F7F FF75F4 push [ebp-0C] ;save validyear
:05167F82 660FB645F7 movzx byte ptr ax, [ebp-09] ;pushday
:05167F87 660FB64DF6 movzx byte ptr cx, [ebp-0A] ;pushmonth
:05167F8C 50 push eax
:05167F8D 51 push ecx
:05167F8E E84EC10B00 call 052240E1 ;call here
:05167F93 663B45E4 cmp ax, [ebp-1C]
:05167F97 7D0D jge 05167FA6 ;go badflag
:05167F99 668B4DE4 mov cx, [ebp-1C]
:05167F9D 662BC8 sub cx, ax
:05167FA0 66894DF2 mov [ebp-0E], cx
:05167FA4 EB06 jmp 05167FAC ;do not badflag
* Referenced by a Jump at Addresses:05167E13(C), :05167ED7(C),
:05167F1B(C), :05167F64(C), :05167F75(C), :05167F7D(C),
:05167F97(C); lotta routines badflag
here... this is BADFLAG INTENSIVE
:05167FA6 66C745FE0100 mov [ebp-02], 0001 ;BAD FLAG !!!***
:no_bad_flag
:05167FAC FF75DC push [ebp-24]
:05167FAF FF151C5C3C05 Call dword ptr[053C5C1C];RegCloseKey
:05167FB5 EB25 jmp 05167FDC ;jump 2nd getlocaltime
:only_5167DE5_calls_this_second_GetLocalTime
:05167FB7 66C745EC0000 mov [ebp-14], 0000
:05167FBD 8D45F4 lea eax, [ebp-0C]
:05167FC0 50 push eax ;SECOND GetLocalTime
:05167FC1 E8B1CEEBFF call 05024E77 GetLocalTime ;call it
:05167FC6 66817DF4C007 cmp [ebp-0C], 07C0 ;between 1984...
:05167FCC 7208 jb 05167FD6 ;jump flag_unvalid_year
:05167FCE 66817DF40108 cmp [ebp-0C], 0801 ;...and 2049?
:05167FD4 7606 jbe 05167FDC ;jump_to_valid_year
:flag_unvalid_year
:05167FD6 66C745FE0100 mov [ebp-02], 0001 ;flag "unvalid_year"
:valid_year_almost_everybody_calls_here
:05167FDC 66837DFE00 cmp [ebp-02], 0000 ;valid_flag?
:05167FE1 755F jne 05168042 ;beggar off:unvalid something
:05167FE3 66837DF000 cmp [ebp-10], 0000 ;valid ebp-10?
:05167FE8 750E jne 05167FF8 ;jmp unvalid_e10
:05167FEA 66837DEC00 cmp [ebp-14], 0000 ;valid ebp-14?
:05167FEF 7451 je 05168042 ;beggar off,unvalid
:05167FF1 66837DF000 cmp [ebp-10], 0000 ;sure thatebp-10=0?
:05167FF6 7407 je 05167FFF ;continue ifso
:unvalid_e10
:05167FF8 66837DEC00 cmp [ebp-14], 0000 ;check if e14valid
:05167FFD 7543 jne 05168042 ;no? be damned!
:valid_e10_and_e14
:05167FFF 0FBF4DF2 movsx word ptr ecx, [ebp-0E] ;e10 and e14 true
:05168003 66833D58192C0501 cmp dword ptr [052C1958], 0001
:0516800B 1BC0 sbb eax, eax
:0516800D 83E05A and eax, 0000005A ;pretty obvious
:05168010 83C05A add eax, 0000005A ;isnt it?
:05168013 3BC1 cmp eax, ecx ;HERE********
:05168015 7C2B jl 05168042 ;beggar off
:05168017 66837DF21E cmp [ebp-0E], 001E ;0x1E = 30
:0516801C 7F4A jg 05168068 ;good guy jump
:0516801E 8D45F4 lea eax, [ebp-0C]
Well, that's was it actually... we notice two consecutive
locations with 5Ah (90 decimal) there... as if they had written
"OUR TIME LIMIT IS HERE, PLEASE REMOVE AND USE FOR EVER AND
EVER". Maybe Micro$oft wants exactly this... I mean, they give
away their (bugged) web browser for free just in order to
bankrupt Netscape, why shouldnt they as well give every software
away for free (bad protecting it on time limits and spreading
everything on all cd-rom covers of the planet) until they have
bankrupted every concurrent and do effectively held every user
on the planet "pillado por los huevos"?
Maybe in cracking this protection scheme I'm only helping
Gates... the more people use its programs the more they will
spread... the more he will dominate the market... yet I could not
care less about Micro$oft's own stupid plans... programming the
way they do, they will never be able to dominate a portion of
halfbacked potatoes in my humble opinion... therefore let's crack
this crap black and blue and let's hope Micro$oft loose a lot of
money thank us, yeah, that's life! Let's crack a lot of Micro$oft
software from now on! A white flower in our mouth, a computer not
far away, a cold determination in our fingers. Death to Gates!
*** Quick Crack for Micro$oft's Project 95, by +ORC, 04/1997***
search for the string
:05167FA6 66C745FE0100 mov [ebp-02], 0001 ;BAD FLAG****
and change it to:
:05167FA6 66C745FE0000 mov [ebp-02], 0000 ;always good
*** now find some stupid yuppies and give them this app ***
JUST A MOMENT (1)
Well, just a moment... go back to the code "snippets" above,
pupils... why did we not search for
:05168015 7C2B jl 05168042 ;beggar off
in order to noop everything say with an inc/dec:
:05168015 40 inc eax
:05168016 48 dec eax
Why?
Because it would NOT have worked... or, as a matter of fact, it
would have worked only in SOME cases... this is an example of a
"protectionists' bait", please examine the code.
You should -by now- know enough our art to be able to
understand by yourself why the crack at 5167FA6 works and the
crack at 5168015 (which is indeed part of the protection) will
not work... a hint for you: change months and YEARS of your os
as you experiment with this stuff. This answer is part of the
strainer of this lesson, therefore work on it and understand the
problem.
And what about the remaining last "double call" location at
"223"? Did I not say we should keep steady on our approach before
delving inside?
Yes and no: "quod satis est cui contingit, nihil amplius
optet" (Horatius, emailing his friends, as you can see you can
always find a proverb to demonstrate what you are saying, even
if you are contradicting yourself :=)
But as soon as you SEE the protection there is NO POINT
(unless you really have to, in order to understand some weird
scheme thoroughly) to continue... the plane is landed, relax,
drink something.
Anyway for such things there are no fixed rules... do
whatever you like and prefer, I personally think that the best
approach is a mixture of iron will and extreme flexibility.
JUST A MOMENT (2)
But wait, since they used the 5Ah byte... could not we have found
the protection just searching for 5Ah?
Yes, and indeed, we would have found the scheme around it
immediately... but that IS NOT the correct approach, since you
should NOT always presume that the protectionists behave REALLY
always that stupid (even if they almost always do :=)
JUST A MOMENT (3)
But wait, could we have not just winiced the working of the
program in order to backtrace as soon as the protection nag
screen snaps?
Yes, and it would have worked... but why ruin your eyes on
screen in a closed and may be dusty room, getting cramps in your
shoulders that not even a good massage will blow away, when you
can crack much more relaxed, sitting quiet in a shadowy garden,
looking lazily (it's April! A beautiful month! Go outside! What
the hell are you doing inside a room?) at a couple of sheets of
paper, feeling the wind among the leaves above you, while a cool
Martini-Wodka fizzles in your hands? If you want to use the
"live" winice approach go ahead... I'll even tell you right now
a couple of things that can be useful in order to crack some
(other) protections: for Cinderellas schemes bpx MessageBox or
bpx GetLocalTime or bpx GetFileTime and look WHO gets the "time"
data a little before the nagscreen snaps... I did not check but
I'm sure that if you do it here, you'll have quite a lot of calls
along the program, whereby the "initializing" calls from our
"sector 24F" will snap at the beginning (and at the end) of the
target life and our protection call (the one we cracked the bad
flag of) i.e.:
:05167F6A E808CFEBFF call 05024E77 ;CALL GetLocalTime in KERNEL
will happen JUST BEFORE the snap... so you can crack thatta way
too... these patterns are always the same.
**************** A little icy digression *****************
This is -after all- a tutorial, therefore for those of you that
do not know anything, here are some useful (and well known) older
winice little tricks and memory addresses discussions. Even if
I do prefer to use as much as possible my "dead listing" methods,
I realise that at times the help of winice is indispensable...
the little tricks below refer to Winice for windows 95 older copy
(before Godot, i.e. 3.0) and you may skip this section if you are
using winice 3.0. which has the IF feature for conditional
breakpoints, the WHAT command and much more. I strongly
reccommand using Winice 3.0. In order to learn how to use it
correctly your best approach is to find on the web the GOOD
documentation of Numega (it's in adobe acrobat's PDFformat) here
you have the names you'll need to find it (and NAMES are the MOST
important thing on the web):
Si30cr.pdf 3.205.000 bytes COMMAND REFERENCE
Si30ug.pdf 1.038.000 bytes USING SOFTICE
Last time I fetched them they were inside the zipped file
Sice3doc.zip, 3.358.000 bytes
read these documents thoroughly. Once you read them you (almost)
will not need my lessons any more.
But some of the simple tricks below can be useful even with
Winice 3.0., and anyway I want ALL of the readers of this
tutorial to know their tools and to use them in the best way,
even those too lazy or too stupid to fetch the above mentioned
files... therefore, here you are... some (older) winice's MUST
know:
BPM DS:xxxxxxxx W GT 1E
Breakpoint first time that the byte at location DS:xxxxxxxx has
a value written to it that's greater than 1Eh (30)
Useful qualifiers are EQ (equal) NE (not equal) GT (greater than)
LT (less than) and M (mask) this last one is pretty complicated
but allows powerful breakpointing for dongles cracking: after
having given your routine command "tss", begin your dongle
breakpointing using, for instance:
BPIO 3F6 R EQ M 11XX xx00
This defines a byte break point on I/O port read, the first time
that I/O port 3F6 is read with ANY value that has the two high
order bits set to 1 and the two lower ones to zero, the other
bits can be any value. The same is valid for BPM (breakpoint on
memory write):
BPM CS:802A2D22 W EQ M 0xxx xxxx xxxx xxxx xx11
you dig it? The mask method is even better than the qualifier one
if you are NOT sure about which value the protection will load :=)
CSIP NOT &F000:0 &FFFF:0
Breakpoint only outside BIOS useful to limit breakpoint snapping
Remember that CSIP and BPM (READ/WRITE) can be very USEFUL to
slow down the execution of a windows program... if you use "heavy
breakpointing" in this way, setting a number of "useless" but
heavy breakpoints that winice will monitor, windows will crawl
(even on a Pentium 200) and you'll be able to breakpoint MANUALLY
exactly at the point where a protection snaps... I still prefer
the "dead listing" method of cracking personally, though.
BPINT 21 AH=0F
Breakpoint on openfile (funny how many INT 21 are execited under
windoze)
(old style, with Winice 3 it's BPINT 21 IF EAX=0F)
BPINT 21 AH=2A
Breakpoint on GetDate
(old style, with Winice 3 it's BPINT 21 IF EAX==2A)
When we are still at it, remember that in 32bit mode there are
only TWO selectors (when you search the whole memory for
instance):
28:0 and 4 virtual gigabytes of CODE
30:0 and 4 virtual gigabytes of DATA and STACK
We saw (cracking DOS) how to get from virtual address to physical
address in 8086 style segment:offset code: multiply the segment
by 16 and then add the offset. In a "protected mode" selector
it's different: linear address is calculated by adding the offset
TO THE BASE ADDRESS FOUND IN THE GDT (or LDT, local descriptor
table is used if bit TWO of the selector is a 1, global DT is
used otherwise... GDT and LDT are "lookup" tables used to
calculate addresses).
At times you must understand a little the physical addresses
structure in order to crack effectively:
00000000 - 000FFFFF Current Virtual Machine (Windows and Windows
Programs)
00400000 - 7FFFFFFF Physical memory (contiguous)
80000000 - 803FFFFF Windows' VxDs
80500000 - 80FFFFFF Windows programs
81000000 - FFFFFFFF DOS VMs
...use the commands "page" and "addr" and have a look around. The
command addr is also very useful to understand in which context
you are when winice pops up.
Remember that each 32 bit task is given the address space from
400000 to 7FFFFFFF, which is called an "address context". This
virtual address space is reserved for 32 bits applications and
private DLLs
And now two MUST KNOW winice commands that will spare you a lot
of wasted time when you delve inside the huge windows codebulks
we have to peruse:
P RET (that's F12 most of the time)
steps out of the current procedure, may take ages if it's very
large
that's step until return
G @SS:ESP (that's F11 most of the time)
throws you at the caller of the procedure you bpxed on
(bpx GetLocalTime and execute F11 (or write G @SS:ESP) as soon
as winice pops up and you'll see what I mean)
A couple of watches like *ds:esi (and ds:esi) and a dex 1 ss:esp
in your ini setting of winice would be a good idea too IMO.
This said, Winice 3.0 allows POWERFUL breakpointin, like for instance:
bpx ntoskrnl!ExAllocatePoolWithTag IF (esp->c == 1) DO "data1;dd eax"
(I will explain all this more thoroughly in the lessons about Windows NT)
**********************************************
Back to our time protections cracking (and Micro$oft bashing :=).
Once more... there are THOUSAND different ways to crack
these applications, and this GetLocalTime "fishing" is only ONE
of them... I will teach you -of course- ALL the methods I believe
are MOST effective... you must be enough crack-able by now to
know when, applying these techniques to OTHER programs (hopefully
Micro$oft ones) you'll have to use slightly or substantially
different approaches... non semper Saturnalia erunt, as you'll
see.
Are these protections always so easy to defeat?
No and yes, may be no... yet there are far more complex schemes.
But time checking from a CD-ROM code is the ultimate doom of the
protectionists... you see: the problem for them is the following:
They are protecting using a "write only once" media (a CD-ROM)...
therefore every time you put the cd-rom in your driver you are
re-installing a perfect "virgin" copy of the protected program...
there is no way a recursive message can be placed INSIDE the
code, telling it to never execute again... I remeber older nasty
"quiver" protections in dos... after the 20ntieth installation
the program formatted as bad a sound sector of the diskette...
that was clever! But that's impossible on a read only media,
therefore let's see... where can they keep track of the
eventuality that you used it before?
1) Inside the intricacies of Windows register, this most
obscure fat abomination (should I write a scary computer fiction
film, I would imagine a windows register growing fatter and
fatter, week after week, and then suddenly grabbing the user
through the a:\ drive in order to eat him :=)
2) Inside an apparently unrelated file or *.dll that gets
"lost" inside the garbage subdirectories c:\windows or
c:\windows\system (by the way, that's exactly the same technique
you should use in order to protect your files at work from
administrator's prying eyes... throw every application inside
windows subdirs and give them funny names, like a6JJJK.EXE... no
administrator on this earth (and no censorship corporate
patrolling software) will come to the idea that that is your
beloved chess program :=).
3) Inside small parts of the BOOT sector of your harddisk that
can safely be used for this kind of tricks without altering the
booting (this is a trick the protectionists have learnt from our
fellows viri-writers... see how even the bad ones have a teaching
function in this funny virtual world. Once more virus code
studying is VERY important in order to crack well.
Alas for the protectionists! All these tricks are pretty easy to
defeat too, and I will show you HOW to do it :=)
For a start here is HOW easily you would have checked your boot
sector with an old DOS system...
1) Run debug (or, better, symdeb)
2) -L 100 2 0 1
(that's Load into memory address Ox100 from drive C (that's
number 2... 0 is A, 1 is B and 2 is C, duh, starting from sector
0 for 1 sector whatever you find there. Here you have the boot
sector of the PC I'm writing on:
-L 100 2 0 1
-d 100 L 200
17D3:0100 EB 3C 90 4D 53 57 49 4E-34 2E 31 00 02 40 01 00 k [.MSWIN4.1..@..
17D3:0110 02 00 02 00 00 F8 9A 00-3F 00 40 00 3F 00 00 00 .....x..?.@.?...
17D3:0120 41 44 26 00 80 00 29 FC-0F 5F 3C 20 20 20 20 20 AD&...)|._[
17D3:0130 20 20 20 20 20 20 46 41-54 31 36 20 20 20 FA 33 FAT16 z3
17D3:0140 C9 8E D1 BC FC 7B 16 07-BD 78 00 C5 76 00 1E 56 I.Q[|{..=x.Ev..V
17D3:0150 16 55 BF 22 05 89 7E 00-89 4E 02 B1 0B FC F3 A4 .U?"..~..N.1.|s$
17D3:0160 06 1F BD 00 7C C6 45 FE-0F 8B 46 18 88 45 F9 38 ..=.|FE~..F..Ey8
17D3:0170 4E 24 7D 22 8B C1 99 E8-77 01 72 1A 83 EB 3A 66 N$}".A.hw.r..k:f
17D3:0180 A1 1C 7C 66 3B 07 8A 57-FC 75 06 80 CA 02 88 56 !.|f;..W|u..J..V
17D3:0190 02 80 C3 10 73 ED 33 C9-8A 46 10 98 F7 66 16 03 ..C.sm3I.F..wf..
17D3:01A0 46 1C 13 56 1E 03 46 0E-13 D1 8B 76 11 60 89 46 F..V..F..Q.v.`.F
17D3:01B0 FC 89 56 FE B8 20 00 F7-E6 8B 5E 0B 03 C3 48 F7 |.V~8.wf.^..CHw
17D3:01C0 F3 01 46 FC 11 4E FE 61-BF 00 07 E8 23 01 72 39 s.F|.N~a?..h#.r9
17D3:01D0 38 2D 74 17 60 B1 0B BE-D8 7D F3 A6 61 74 39 4E 8-t.`1.>X}s&at9N
17D3:01E0 74 09 83 C7 20 3B FB 72-E7 EB DD BE 7F 7D AC 98 t..G;{rgk]>.},.
17D3:01F0 03 F0 AC 84 C0 74 17 3C-FF 74 09 B4 0E BB 07 00 .p,.@t.[.t.4.;..
17D3:0200 CD 10 EB EE BE 82 7D EB-E5 BE 80 7D EB E0 98 CD M.kn>.}ke>.}k`.M
17D3:0210 16 5E 1F 66 8F 04 CD 19-BE 81 7D 8B 7D 1A 8D 45 .^.f..M.>.}.}..E
17D3:0220 FE 8A 4E 0D F7 E1 03 46-FC 13 56 FE B1 04 E8 C1 ~.N.wa.F|.V~1.hA
17D3:0230 00 72 D6 EA 00 02 70 00-B4 42 EB 2D 60 66 6A 00 .rVj..p.4Bk-`fj.
17D3:0240 52 50 06 53 6A 01 6A 10-8B F4 74 EC 91 92 33 D2 RP.Sj.j..ttl..3R
17D3:0250 F7 76 18 91 F7 76 18 42-87 CA F7 76 1A 8A F2 8A wv..wv.B.Jwv..r.
17D3:0260 E8 C0 CC 02 0A CC B8 01-02 8A 56 24 CD 13 8D 64 h@L..L8...V$M..d
17D3:0270 10 61 72 0A 40 75 01 42-03 5E 0B 49 75 77 C3 03 .ar.@u.B.^.IuwC.
[MICROSOFT PUBLISHER 1997]
Time to bash Microsoft once more... how nice! Let's have a
(quick) look at Microsoft Publisher 1997, another "60 days" trial
version protection from Microsoft (60 days, because the DTP
market moves so quickly that they cannot allow to let it loose
for three months)... I'll show you where the protection is, how
it snaps and how to crack it... I got my copy from one of the
MANY magazines that published the 60 days demo version in April
1997... you should be able to find this one everywhere... here
are the relevant data:
MSPUB.EXE 2.476.304 19/04/97 19:19 <--- da target
MSPUB.ALF 34.054.330 17/04/97 20:18 <--- da dead listing
MSPUB.DED 2.476.304 19/04/97 19:19 <--- da copy you need
You should always do a copy of the original target BEFORE
beginning your work on it, you'l need it a lot when you time
deprotect.
To crack this target we'll use a slightly different approach...
let's call this technique "hit and see"... it's one of the most
obvious approaches, and I surely have not invented it...
everybody knows it: you run the program, you let the time
protection snap, you look at the "hardwired" hex differences
inside the body of the target (the "non functioning" copy will
slightly differ from the "functioning" one) and you "reverse
engineer" your dead listing back to the protection scheme that
snapped the differences... pretty easy, isnt'it?
-------- digression: words inside targets ---------------------
If you are interested in another, COMPLETELY DIFFERENT cracking
door, here are the relevant messages [expir] inside our target...
I used SR32exe to fetch them (a very nice fetcher, thanks
fravia! :=), which is much better than my own old C scripts :=(
As a small "extra" for this lesson, crack the protection out of
this fetcher, a program that I'm sure you'll find VERY useful (I
did):
-------------------------------------
Funduc Software search application:
http://home.sprynet.com:80/sprynet.funduc
102372.2530@compuserve.com
SR32 EXE 286.720 13/05/96 0:14 SR32.exe
SR HLP 36.830 12/05/96 3:28 SR.HLP
SR EXE 170.624 12/05/96 23:58 Sr.exe
------------------------------------
Here the results of this program running on "expir"...
------------------------------------
Processing file : C:\PROGRAM FILES\MICROSOFT PUBLISHER 97\Mspub.exe
Offset 0x1ac5e9
- This trial version of Publisher has [expir]ed. To order a permanent
copy, call 1-800-426-9400 or visit the Publisher site on the World
Wide Web at http://www.microsoft.com/publisher/. To uninstall this
version choose Add/Remove Programs i
Offset 0x1ac6f4
- This trial version of Publisher will [expir]e in %d days. For more
information about Publisher 97, call 1-800-426-9400 or visit the
Publisher site on the World Wide Web at http://www.microsoft.com/publisher/.
----------------- digression end --------------
As I said... there are MANY doors you may trespass to crack this
target... let's continue with the simplest one in my opinion:
1) Let's run it... it runs, how nice!
2) Let's move the OS date... say four months ahead.
It does not run anymore, this is sad!
3) WHAT HAS CHANGED IN THE FILE? That's the point my reader...
Let's compare the two files... the original and the copy after
the fatidic message "trial time is out, won't work any more", bye
sucker:*
FC /b mspub.ded mspub.exe
(that's the DOS command FileCompare that you are giving, duh)
And this is the result you'll get:
"Comparing files mspub.ded and mspub.exe"
"000F3703: 75 EB"
"000F370C: 75 EB"
MMMM! That's interesting! And what do we have there? Let's have
a look at our (huge) dead listing (do not forget: 2560 (256*10)
bytes difference between REAL AND Wdasm addressing... you just
add A00h to the DOS addresses to get your bearings inside the
dead listing files... F3703+A00= F4103... F370C+A00=F410C):
* Referenced by lotta CALLs at Addresses:
|:004014F1, :0040199A, :00401AC6, :00401C37, :00401F6C, ;first calls
... HUNDERT CALLS AND HUNDERT MORE... many many calls I have not reprinted
|:0058B1C4, :0058B279, :0058B443, :0058BA9F ;last calls
|
:004F40FC 8B4C2404 mov ecx, [esp + 04]
:004F4100 83F901 cmp ecx, 1
:004F4103 EB09 **** jmp 004F410E ;..... Should be 75, i.e. Jne
:004F4105 833DD0225C0000 cmp dword ptr [005C22D0], 0
:004F410C EB06 **** jmp 004F4114 ;..... Should be 75, I.e. Jne
:004F410E 890DD0225C00 mov [005C22D0], ecx ;ecx NOT 1 flag 22D0 FALSE
:004F4114 A1D4225C00 mov eax, [005C22D4]
:004F4119 51 push ecx
:004F411A 83E840 sub eax, 00000040
:004F411D 890DC4935C00 mov [005C93C4], ecx
:004F4123 A3D4225C00 mov [005C22D4], eax
:004F4128 83C040 add eax, 00000040
:004F412B 50 push eax
:004F412C FF158C085D00 Call dword ptr [005D088C] ;call MSVCRT40.longjmp
:004F4132 83C408 add esp, 00000008
:004F4135 C20400 ret 0004
All this means for us only one thing... location [005C22D0]
decides a lot. But wait, let's see... What did these assholes
do? They "patched" their own program in order to protect it...
how funny... time is out, so jmp anyway (instead of jump on not
equal) to the evil routines... they know that now we would like
to know WHO calls here... and there are (therefore, as
dissuasion) hundert of procedures calling this cram... no point
in checking all of them... you would sink in a sea of calls...
what will we do? Where is the real and only one PROTECTION call
to 4F40FC among this bunch of useless calls? We have only ONE way
to find it out without losing time... Let's zen a little... you
have read this lesson from the beginning... now STOP and think...
i.e. use your brain (supposed you have one): do not read any more
what follow: STOP NOW and answer this question BEFORE
proceeding... really... you are here to learn, NOT TO COPY
METHODS THAT OTHERS HAVE FOUND... once more... We know that
somebody modified this cram... but HOW DO WE GET BACK (how do we
reverse the flow) TO THE CORRECT CALLING ROUTINE AMONG HUNDERT
OF THEM calling here?
Ok, you did stop and think... you may go on reading (if you did
not... be ashamed... cracking is like watching a beautyful
picture... you must think a lot, else your watching is useless).
OK: We used the GetLocalTime routine as a bait inside my first
example... can we apply it here? Let's search for it... HEY! They
do not use it at all, there is NO GetLocalTime in this
application... how the hel do they know which time is it?
Let's search for "time", my friends... here the locations:
Processing file : C:\PROGRAM FILES\MICROSOFT PUBLISHER 97\Mspub.alf
Line 1340 - Addr:BFF77105 hint(00DB) Name: GetFile[Time]
Line 1342 - Addr:BFF77144 hint(01F9) Name: SetFile[Time]
Line 1457 - Addr:BFF62E82 hint(01FE) Name: Set[Time]r
Line 1494 - Addr:BFF61AC2 hint(0162) Name: Kill[Time]r
Line 1547 - Addr:BFF643F9 hint(00EF) Name: GetDoubleClick[Time]
Line 1555 - Addr:BFF63E4D hint(01C9) Name: SendMessage[Time]outA
Line 1572 - Addr:BFF64406 hint(00D1) Name: GetCaretBlink(Time]
Line 1591 - Addr:BFF647E6 hint(0110) Name: GetMessage[Time]
Line 1865 - Addr:10238C10 hint(0466) Name: [time]
Line 1871 - Addr:102387D0 hint(0423) Name: local[time]
Ok, that's more than enough, thankyou... let's begin from
the beginning... what about a little GetFileTime pinpointing to
start with? Where are the GetFileTime routines inside our target?
:004CBC11 FF1594005D00 Call dword ptr [005D0094]
;KERNEL32.GetFileTime
:004CBD3A FF1594005D00 Call dword ptr [005D0094]
;KERNEL32.GetFileTime
Only TWO? Most rewarding... and where is the triggering call to
the first one (probably to both of them)?
Have a look at the dead listing of our target... these cracks are
so simple that I wonder at times why the hell they insist...
either they shoudl learn HOW TO PROTECT PROPERLY the shit they
program, or they should give it for free to everybody (like I'm
doing now... hope that EVERY student and every poor chap in
Africa and Asia will use Micro$oft publisher for free without
ever giving them a cent... this is european cracking at his best!
And besides, that's the minimum we owe the poor slaves that do
sweat and work hard in order to pay for our barbecues :=)...
this is the synthesis of the dead listing:
* Referenced by a CALL at Address:004C8843 ;This is the call
that triggers everything... DO NOT FORGET IT
:004CBA50 55 push ebp
:004CBA51 A1D4225C00 mov eax, [005C22D4]
:004CBA56 8BEC mov ebp, esp
:004CBA58 83C040 add eax, 00000040
:004CBA5B 81EC5C010000 sub esp, 0000015C
:004CBA61 A3D4225C00 mov [005C22D4], eax
:004CBA66 C745E414165C00 mov [ebp-1C], 005C1614;->"MSPUBW40.DLL"
:004CBA6D C745FCFFFFFFFF mov [ebp-04], FFFFFFFF
:004CBA74 56 push esi
:004CBA75 57 push edi
:004CBA76 6A00 push 00000000
:004CBA78 50 push eax
:004CBA79 E889020C00 Call 0058BD07;MSVCRT40._setjmp3,
:004CBA7E 83C408 add esp, 00000008
:004CBA81 85C0 test eax, eax
:004CBA83 B801000000 mov eax, 00000001
:004CBA88 7502 jne 004CBA8C
:004CBA8A 33C0 xor eax, eax
:004CBA8C 85C0 test eax, eax
:004CBA8E 0F8527030000 jne 004CBDBB
:004CBA94 6A00 push 00000000
:004CBA96 FF1590085D00 **** Call dword ptr [005D0890];MSVCRT40.time **
:004CBA9C 83C404 add esp, 00000004
:004CBA9F B980510100 mov ecx, 00015180
:004CBAA4 2BD2 sub edx, edx
:004CBAA6 8945F4 mov [ebp-0C], eax
:004CBAA9 6804010000 push 00000104
:004CBAAE 8DBDA4FEFFFF lea edi, [ebp+FFFFFEA4]
:004CBAB4 F7F1 div ecx
:004CBAB6 8D85A4FEFFFF lea eax, [ebp+FFFFFEA4]
:004CBABC 2955F4 sub [ebp-0C], edx
:004CBABF 50 push eax
:004CBAC0 FF158C005D00 Call dword ptr[005D008C];GetSystemDirectoryA
:004CBAC6 B9FFFFFFFF mov ecx, FFFFFFFF
:004CBACB 2BC0 sub eax, eax
:004CBACD F2 repnz
:004CBACE AE scasb
:004CBACF F7D1 not ecx
:004CBAD1 80BC29A2FEFFFF5C cmp byte ptr [ecx + ebp - 0000015E], 5C
:004CBAD9 7434 je 004CBB0F
:004CBADB BF10165C00 mov edi, 005C1610
:004CBAE0 B9FFFFFFFF mov ecx, FFFFFFFF
:004CBAE5 2BC0 sub eax, ea
:004CBAE7 F2 repn
:004CBAE8 AE scasb
:004CBAE9 F7D1 not ecx
:004CBAEB 2BF9 sub edi, ecx
:004CBAED 8BD1 mov edx, ecx
:004CBAEF 8BF7 mov esi, edi
:004CBAF1 B9FFFFFFFF mov ecx, FFFFFFFF
:004CBAF6 8DBDA4FEFFFF lea edi, [ebp+FFFFFEA4]
:004CBAFC 2BC0 sub eax, eax
:004CBAFE F2 repnz
:004CBAFF AE scasb
:004CBB00 4F dec edi
:004CBB01 8BCA mov ecx, edx
:004CBB03 C1E902 shr ecx, 02
:004CBB06 F3 repz
:004CBB07 A5 movsd
:004CBB08 8BCA mov ecx, edx
:004CBB0A 83E103 and ecx, 00000003
:004CBB0D F3 repz
:004CBB0E A4 movsb
:004CBB0F 8B7DE4 mov edi, [ebp-1C]
:004CBB12 B9FFFFFFFF mov ecx, FFFFFFFF
:004CBB17 2BC0 sub eax, eax
:004CBB19 F2 repnz
:004CBB1A AE scasb
:004CBB1B F7D1 not ecx
:004CBB1D 2BF9 sub edi, ecx
:004CBB1F 8BD1 mov edx, ecx
:004CBB21 8BF7 mov esi, edi
:004CBB23 B9FFFFFFFF mov ecx, FFFFFFFF
:004CBB28 8DBDA4FEFFFF lea edi, [ebp+FFFFFEA4]
:004CBB2E 2BC0 sub eax, eax
:004CBB30 F2 repnz
:004CBB31 AE scasb
:004CBB32 4F dec edi
:004CBB33 8BCA mov ecx, edx
:004CBB35 C1E902 shr ecx, 02
:004CBB38 F3 repz
:004CBB39 A5 movsd
:004CBB3A 8BCA mov ecx, edx
:004CBB3C 6A00 push 00000000
:004CBB3E 83E103 and ecx, 00000003
:004CBB41 6880000000 push 00000080
:004CBB46 F3 repz
:004CBB47 A4 movsb
:004CBB48 6A03 push 00000003
:004CBB4A 8D85A4FEFFFF lea eax, [ebp+FFFFFEA4]
:004CBB50 6A00 push 00000000
:004CBB52 6A01 push 00000001
:004CBB54 6800000080 push 80000000
:004CBB59 50 push eax
:004CBB5A FF15C8005D00 Call dword ptr [005D00C8];CreateFileA
:004CBB60 8945FC mov [ebp-04], eax
:004CBB63 83F8FF cmp eax, FFFFFFFF
:004CBB66 7507 jne 004CBB6F
:004CBB68 6AFE push FFFFFFFE
:004CBB6A E88D850200 call 004F40FC
:004CBB6F 6A00 push 00000000
:004CBB71 8B45FC mov eax, [ebp-04]
:004CBB74 6A00 push 00000000
:004CBB76 6850D90100 push 0001D950
:004CBB7B 50 push eax
:004CBB7C FF1598005D00 Call dword ptr [005D0098];SetFilePointer
:004CBB82 83F8FF cmp eax, FFFFFFFF
:004CBB85 7507 jne 004CBB8E
:004CBB87 6AE7 push FFFFFFE7
:004CBB89 E86E850200 call 004F40FC
:004CBB8E 6A00 push 00000000
:004CBB90 8D45F0 lea eax, [ebp-10]
:004CBB93 50 push eax
:004CBB94 8D4DF8 lea ecx, [ebp-08]
:004CBB97 6A04 push 00000004
:004CBB99 8B55FC mov edx, [ebp-04]
:004CBB9C 51 push ecx
:004CBB9D 52 push edx
:004CBB9E FF1590005D00 Call dword ptr [005D0090];ReadFile
:004CBBA4 85C0 test eax, eax
:004CBBA6 7406 je 004CBBAE
:004CBBA8 837DF004 cmp [ebp-10], 00000004
:004CBBAC 7407 je 004CBBB5
:004CBBAE 6A03 push 00000003
:004CBBB0 E847850200 call 004F40FC
:004CBBB5 8B45FC mov eax, [ebp-04]
:004CBBB8 50 push eax
:004CBBB9 FF154C015D00 Call dword ptr [005D014C];CloseHandle
:004CBBBF C745FCFFFFFFFF mov [ebp-04], FFFFFFFF
:004CBBC6 817DF86F6C626F cmp [ebp-08], 6F626C6F
:004CBBCD 0F85C2000000 jne 004CBC95
:004CBBD3 6A00 push 00000000
:004CBBD5 8D85A4FEFFFF lea eax, [ebp+FFFFFEA4]
:004CBBDB 6880000000 push 00000080
:004CBBE0 6A03 push 00000003
:004CBBE2 6A00 push 00000000
:004CBBE4 6A00 push 00000000
:004CBBE6 68000000C0 push C0000000
:004CBBEB 50 push eax
:004CBBEC FF15C8005D00 Call dword ptr [005D00C8];CreateFileA
:004CBBF2 8945FC mov [ebp-04], eax
:004CBBF5 83F8FF cmp eax, FFFFFFFF
:004CBBF8 7507 jne 004CBC01
:004CBBFA 6AFE push FFFFFFFE
:004CBBFC E8FB840200 call 004F40FC
:004CBC01 8D45AC lea eax, [ebp-54]
:004CBC04 8D4DB4 lea ecx, [ebp-4C]
:004CBC07 50 push eax
:004CBC08 8D55BC lea edx, [ebp-44]
:004CBC0B 51 push ecx
:004CBC0C 8B45FC mov eax, [ebp-04]
:004CBC0F 52 push edx
:004CBC10 50 push eax
:004CBC11 FF1594005D00 ****Call dword ptr [005D0094];GetFileTime ***
:004CBC17 85C0 test eax, eax
:004CBC19 7507 jne 004CBC22
:004CBC1B 6A03 push 00000003
:004CBC1D E8DA840200 call 004F40FC
:004CBC22 6A00 push 00000000
:004CBC24 8B45FC mov eax, [ebp-04]
:004CBC27 6A00 push 00000000
:004CBC29 6850D90100 push 0001D950
:004CBC2E 50 push eax
:004CBC2F FF1598005D00 Call dword ptr [005D0098];SetFilePointer
:004CBC35 83F8FF cmp eax, FFFFFFFF
:004CBC38 7507 jne 004CBC41
:004CBC3A 6AE7 push FFFFFFE7
:004CBC3C E8BB840200 call 004F40FC
:004CBC41 6A00 push 00000000
:004CBC43 8D45F0 lea eax, [ebp-10]
:004CBC46 50 push eax
:004CBC47 8D4DF4 lea ecx, [ebp-0C]
:004CBC4A 6A04 push 00000004
:004CBC4C 8B55FC mov edx, [ebp-04]
:004CBC4F 51 push ecx
:004CBC50 52 push edx
:004CBC51 FF1530015D00 Call dword ptr [005D0130];WriteFile
:004CBC57 85C0 test eax, eax
:004CBC59 7406 je 004CBC61
:004CBC5B 837DF004 cmp [ebp-10], 00000004
:004CBC5F 7407 je 004CBC68
:004CBC61 6A03 push 00000003
:004CBC63 E894840200 call 004F40FC
:004CBC68 8D45AC lea eax, [ebp-54]
:004CBC6B 8D4DB4 lea ecx, [ebp-4C]
:004CBC6E 50 push eax
:004CBC6F 8D55BC lea edx, [ebp-44]
:004CBC72 51 push ecx
:004CBC73 8B45FC mov eax, [ebp-04]
:004CBC76 52 push edx
:004CBC77 50 push eax
:004CBC78 FF159C005D00 ***Call dword ptr [005D009C];SetFileTime **
:004CBC7E 8B4DFC mov ecx, [ebp-04]
:004CBC81 51 push ecx
:004CBC82 FF154C015D00 Call dword ptr [005D014C];CloseHandle
:004CBC88 C745FCFFFFFFFF mov [ebp-04], FFFFFFFF
:004CBC8F 8B4DF4 mov ecx, [ebp-0C]
:004CBC92 894DF8 mov [ebp-08], ecx
:004CBC95 817DF80100ADDE cmp [ebp-08], DEAD0001 ;***!***
:004CBC9C 0F8408010000 je 004CBDAA
:004CBCA2 8B45F8 mov eax, [ebp-08]
:004CBCA5 3945F4 cmp [ebp-0C], eax
:004CBCA8 7248 jb 004CBCF2
:004CBCAA 8B45F4 mov eax, [ebp-0C]
:004CBCAD B980510100 mov ecx, 00015180
:004CBCB2 2B45F8 sub eax, [ebp-08]
:004CBCB5 2BD2 sub edx, edx
:004CBCB7 F7F1 div ecx
:004CBCB9 83F83C cmp eax, 0000003C
:004CBCBC 7334 jnb 004CBCF2
:004CBCBE B93C000000 mov ecx, 0000003C
:004CBCC3 2BC8 sub ecx, eax
:004CBCC5 894DC4 mov [ebp-3C], ecx
:004CBCC8 8D4DC4 lea ecx, [ebp-3C]
:004CBCCB 51 push ecx
:004CBCCC 683E040000 push 0000043E
:004CBCD1 E85C810200 call 004F3E32
:004CBCD6 B801000000 mov eax, 00000001
:004CBCDB C705D0225C0000000000 mov dword ptr [005C22D0],0
:004CBCE5 5F pop edi
:004CBCE6 5E pop esi
:004CBCE7 8BE5 mov esp, ebp
:004CBCE9 832DD4225C0040 sub dword ptr [005C22D4],40
:004CBCF0 5D pop ebp
:004CBCF1 C3 ret
:004CBCF2 817DF80100ADDE cmp [ebp-08], DEAD0001
:004CBCF9 0F84AB000000 je 004CBDAA
:004CBCFF 6A00 push 00000000
:004CBD01 8D85A4FEFFFF lea eax, [ebp+FFFFFEA4]
:004CBD07 6880000000 push 00000080
:004CBD0C 6A03 push 00000003
:004CBD0E 6A00 push 00000000
:004CBD10 6A00 push 00000000
:004CBD12 68000000C0 push C0000000
:004CBD17 50 push eax
:004CBD18 FF15C8005D00 Call dword ptr [005D00C8];CreateFileA
:004CBD1E 8945FC mov [ebp-04], eax
:004CBD21 83F8FF cmp eax, FFFFFFFF
:004CBD24 0F8480000000 je 004CBDAA
:004CBD2A 8D45CC lea eax, [ebp-34]
:004CBD2D 8D4DD4 lea ecx, [ebp-2C]
:004CBD30 50 push eax
:004CBD31 8D55DC lea edx, [ebp-24]
:004CBD34 51 push ecx
:004CBD35 8B45FC mov eax, [ebp-04]
:004CBD38 52 push edx
:004CBD39 50 push eax
:004CBD3A FF1594005D00 *** Call dword ptr [005D0094];GetFileTime **
:004CBD40 85C0 test eax, eax
:004CBD42 7455 je 004CBD99
:004CBD44 6A00 push 00000000
:004CBD46 8B45FC mov eax, [ebp-04]
:004CBD49 6A00 push 00000000
:004CBD4B 6850D90100 push 0001D950
:004CBD50 50 push eax
:004CBD51 FF1598005D00 Call dword ptr [005D0098];SetFilePointer
:004CBD57 83F8FF cmp eax, FFFFFFFF
:004CBD5A 743D je 004CBD99
:004CBD5C 6A00 push 00000000
:004CBD5E 8D45F0 lea eax, [ebp-10]
:004CBD61 50 push eax
:004CBD62 8D4DE8 lea ecx, [ebp-18]
:004CBD65 6A04 push 00000004
:004CBD67 8B55FC mov edx, [ebp-04]
:004CBD6A C745E80100ADDE mov [ebp-18], DEAD0001
:004CBD71 51 push ecx
:004CBD72 52 push edx
:004CBD73 FF1530015D00 Call dword ptr [005D0130];WriteFile
:004CBD79 85C0 test eax, eax
:004CBD7B 741C je 004CBD99
:004CBD7D 837DF004 cmp [ebp-10], 00000004
:004CBD81 7516 jne 004CBD99
:004CBD83 8D45CC lea eax, [ebp-34]
:004CBD86 8D4DD4 lea ecx, [ebp-2C]
:004CBD89 50 push eax
:004CBD8A 8D55DC lea edx, [ebp-24]
:004CBD8D 51 push ecx
:004CBD8E 8B45FC mov eax, [ebp-04]
:004CBD91 52 push edx
:004CBD92 50 push eax
:004CBD93 FF159C005D00 ***Call dword ptr [005D009C];SetFileTime **
:004CBD99 8B45FC mov eax, [ebp-04]
:004CBD9C 50 push eax
:004CBD9D FF154C015D00 Call dword ptr [005D014C];CloseHandle
:004CBDA3 C745FCFFFFFFFF mov [ebp-04], FFFFFFFF
:004CBDAA 683D040000 push 0000043D
:004CBDAF E81E800200 call 004F3DD2
:004CBDB4 33C0 xor eax, eax
:004CBDB6 E920FFFFFF jmp 004CBCDB
:004CBDBB 837DFC00 cmp [ebp-04], 00000000
:004CBDBF 740A je 004CBDCB
:004CBDC1 8B45FC mov eax, [ebp-04]
:004CBDC4 50 push eax
:004CBDC5 FF154C015D00 Call dword ptr [005D014C];CloseHandle
:004CBDCB 683F040000 push 0000043F
:004CBDD0 E8FD7F0200 call 004F3DD2
:004CBDD5 33C0 xor eax, eax
:004CBDD7 5F pop edi
:004CBDD8 5E pop esi
:004CBDD9 8BE5 mov esp, ebp
:004CBDDB 5D pop ebp
:004CBDDC C3 ret
OK, that's enough dead listing for now... we know now that the
REAL protection may call :004CBA50 (the beginning of the huge
code snippet above with GetFileTime and other file opening and
closing goodies)... and wdasm gives us the caller (only one...
THE TARGET!... don't you feel it?)
:004C8843 ;This is the call that triggers everything
;I told you: DO NOT FORGET IT
:004CBA50 55 push ebp
:... ...and the rest of the huge snippet
Therefore let's have a look at the caller... here it is:
:call_the_time_checking_huge_snippet
:004C8843 E808320000 call 004CBA50 ;call time checks
:004C8848 85C0 test eax, eax ;on non zero
:004C884A 7507 jne 004C8853 ;go go_on
:004C884C 6A0D push 0000000D ;do not push
:004C884E E8A9B80200 call 004F40FC ;do not call here
:go_on
:004C8853 E8CC1D0500 call 0051A624 ;continue here
:004C8858 8B4510 mov eax, [ebp+10]
:004C885B 50 push eax
:004C885C E8298DF7FF call 0044158A
:004C8861 F60540F15C0008 test byte ptr [005CF140], 08
:004C8868 0F84BC010000 je 004C8A2A
:004C886E C7451400000000 mov [ebp+14], 00000000
Therefore the crack is clear
** how to crack MSPublisher97 (trial 60 days), by +ORC, April
1997**
If you have NOT already sprenged MSpublisher time protection
search for
:004C8843 E808320000 call 004CBA50 ;trigger time checks
and change it to
:004C8843 E910000000 jmp 004C8853 ;don't trigger
If you DO have already sprenged MSpublisher time protection
FIRST search for
:004C8843 E808320000 call 004CBA50 ;trigger time checks
and change it to
:004C8843 E910000000 jmp 004C8853 ;don't trigger
THEN search for
:004F4103 EB09 jmp 004F410E ;jmp anyway
and change it to
:004F4103 7509 jne 004F410E ;jne
THEN search for
:004F410C EB06 jmp 004F4114 ;jmp anyway
and change it to
:004F410C 7506 jne 004F4114 ;jne
**********************************************************
LET'S CRACK MICROSOFT'S MONEY 97 and 95 NOW
Let's finish this lesson with another sound hit at Micro$oft.
This is the main part of the strainer to next year's +HCU, please
solve it (it's MUCH more easy than last year's strainer).
I'm cracking here Microsoft MONEY 97, 90 days trial version I
found on the cd-cover of a review called PC-PRO, issue 31, MAY
1997 (but I bought it in transit at Heathrow airport for three
pounds at the beginning of April and not in May, as usual in this
awful commerce oriented society even minutiae like the dates of
the issues of magazines are completely false :=(
This is another kind of program I personally would not touch with
a pole, nor would I use it, even if somebody would pay me for
it... but I know that a lotta suckers buy these ridiculous
applications greedly... such kind of customers do pay a lot of
money to Micro$oft... and to the banks, and to the various
asinine "investor advisors", and to all the awful commercial
people that has given us this grey world of unhappiness, and
inequality, where only irrelevance and bad taste are valued,
where knowledge is "allowed" only and only if it helps them to
make more money (not happiness)... where poetry and feelings are
considered useless and obsolete by the "market forces"... My, how
I hate cheerfully this whole bunch of "market operators"! How I
hope that the people they have enslaved will one day hang the
whole lot of them, pinning the TV-news moderators to the
doors of the TV-studios by their tongue as a good collateral
measure... (the sooner this happens the better, give it a move
please, I would like to take some nice photos of the hanging
bodies),... ok, enough, let's crack first of all the programs
used by this outrageous people, hoping that my crackings will
spread enough to diminish Gates' cashflow a little... a pebble
of sand is nothing less than a pebble of sand, after all, let's
never forget it :=)
Let's see what happens here... once more with GetLocalTime? Let's
see... here you have three calling "points" for GetLocalTime:
at 45804D, at 46A308 and at 5DA056, let's call them 45, 46 and
5D. Since the one at 46 is referenced by not less than 80 calls,
we will deem it more important than the first one at 45 (three
calls) and the third one at 5D (two calls).... but wait...
WAIT, HISTORY IS IMPORTANT
But wait...may be we should delve a little deeper in
Micro$oft's protection strategies, may be you should have FIRST
a look at an OLDER copy of Micro$oft's Money... say version
3.00p of February 1994... the file you have to crack is here
MNYDEMO.EXE, length 1.173.184 bytes, from 8/2/1994... I found it
on a old cd-rom: PCHOME n.8 from June 1994, as usual, quite a lot
of magazines will have had the "privilege" of burning this trial
version on their CD-ROMs during that summer... you should be able
to find a copy of it on the Web too, if you happen to know how
to search and, what's even more important, WHERE to search... as
I said elsewhere, on the Web you can find almost everything...
provided you already know where it is :=)
THE STRAINER... FIRST OF ALL YOU'LL HAVE TO FIND IT!
Anyway, since this lesson is intended as a "strainer" for
next years +HCU, a part of your duty is TO FIND the targets we
have to crack... this will be easy for MS MONEY 97, but (I hope)
not so easy for MS MONEY from 1994... believe me, this searching
is a very important art... you may be just lucky, or already
have (like me) a huge collection of many CD-ROM that appeared on
magazines covers and that you bought at discount prices... or you
may have to beg or implore or exchange programs with some old guy
from New Zealand or a weird wannaby warez dude from Corea, which
happens to have the copy you are interested in... you may have
to examine old usenet discussion groups, to peruse old
PC-magazines... to delve inside a lot of useless pages...
searching for your nugget. But you'll gain a lot of knowledges
in this process... ignorantia est carentia scientiae debitae.
OLD VERSION, SAME LIMITATIONS
The "trial" old demo of MS-Money 94 has an analogous
protection scheme to the very recent MONEY '97 trial version?
Please check... if it is so, that would be VERY important for
us... history and evolution of a targets' protections IS INDEED
very important. If you'll delve inside cracking as an art, as I
would like you to, you'll see that patterns and trends play (like
in real life) a tremendous unproportionated role... protections
mirror our society (at times I believe that everything does, but
me): real knowledge and innovation plays almost no role, stupid
"trends" and repetitions of the same boring schemes do actually
make the 99% of the "reality".
In the meantime life keep worsening for the stupid slaves,
more and more useless stinking cars are polluting our cities and
the "new" programs we buy are slower and by far not as good and
powerful as the old DOS programs of 1990... a proof? For the dead
listing of this target you'll NOT be able to use Word 7.0 ("file
is too huge"), but you'll still be able to use Word 2.0 from
1994... funny, isn't it?
This old "trial" demo of MS-Money has THREE levels of
protection:
1) The system date in your computer must be 1994 or 1995
2) There is a Cinderella 60 days limit (Micro$oft was not yet
a "90 days" enterprise... we are watching here the BIRTH of this
MS-protection scheme :=)
3) Transactions (i.e. fields of this database) can only be
entered within a 60-days period (this is at the same part the
"tricky" part of this crack and a key to the crack :=)
HOW DO YOU BEGIN?
I'm writing this to teach you MANY cracking techniques, let's
pack this target from another direction, let's forget winice for
a while and use a bit of "dead listing", a program like winsight
and some of the brain we are supposed to have:
1) Have a look at the messages i.e.:
install our target...
run it as it should, changing the OS date to 1994
change OS date past the 60 days limit
look at the message ("The 60-days limit of this working model..."
2) Fire Borland's Winsight (I'm using here version 1.30 from
an old cracked Delphi, but you'll find hundred of them on the
web) It will describe you EXACTLY the nagwindow you have on your
screen:
Popup 0610 {#32770:Dialog} mnydemo.exe (144,183)-(523,345)"Notice of Expiration"
You may even get details on this Popup 610, if you feel like it.
4) You have the NAME (very important). Search it inside the
dead listing (you have previously made with WCB or with wdasm)
of MNYDEMO.EXE, you'll get the following:
Name:
DialogID_0494, # of Controls=004, Caption:"Notice of Expiration"
001 - ControlID:02CE, Control Class:"" Control Text:"The 60-day
limit of this working model has expired."
See what's important? ID_0494... that's important.
5) Now search ID_0494 in your dead listing... you'll find THREE
occurrences (i.e. they call three time the 60-days limit) let's
examine them (with context):
Block 6 at 263:
6.263 is called "cascade" (switch) from the beginning of block 6:
:0006.0012 57 push di
:0006.0013 6A00 push 0000
:0006.0015 9AFFFF0000 call USER.GETWINDOWWORD
(GETWINDOWWORD returns a 16-bit WORD value from the extra
info associated with a window. Push handle and index (in
bytes) in the extra memory where the value will be found)
:0006.001A 8BF0 mov si, ax
:0006.001C 8B460C mov ax, [bp+0C]
:0006.001F 3DA100 cmp ax, 00A1 ;is it 161?
:0006.0022 7503 jne 0027 ;may call NoE if not
...
:0006.0027 7729 ja 0052 ;may call NoE if more
...
:0006.0052 3D1501 cmp ax, 0115
:0006.0055 7503 jne 005A ;if not 115
...
:0006.005A 7712 ja 006E ;more? Call NoE
...
:0006.006E 2D0102 sub ax, 0201 ;sub 201
:0006.0071 7503 jne 0076 ;may call NoE
...
:0006.0076 48 dec ax ;-1
:0006.0077 48 dec ax ;-1
:0006.0078 7503 jne 007D ;may call NoE
...
:0006.007D 2D9102 sub ax, 0291 ;sub 291
:0006.0080 7503 jne 0085 ;do not call NoE
:0006.0082 E9D701 jmp 025C ;call NoE ******
...
:0006.025C 57 push di
:0006.025D 9AFFFF0000 call USER.GETPARENT
(This returns the handle to a window's parent. Function
returns window's parent handle if successful and NULL if
no parent or error)
* Possible Reference to Dialog: DialogID_0494
|
:0006.0263 689404 push 0494 ;HERE! NOTICE OF EXPIRATION
:0006.0266 FF760A push word ptr [bp+0A]
:0006.0269 FF7608 push word ptr [bp+08]
:0006.026C FF7606 push word ptr [bp+06]
:0006.026F 9AFFFF0000 call USER.SENDMESSAGE ;bagger off, bad guy!
:0006.0274 EB14 jmp 028A
Ok, for block 6 what should we say? Can we start our crack from
here?
Let's have a look at the next block:
Block 8 at 17D2:
:0008.17CA 8B46F4 mov ax, [bp-0C]
:0008.17CD 3946F0 cmp [bp-10], ax
:0008.17D0 7246 jb 1818
* Possible Reference to Dialog: DialogID_0494
|
:0008.17D2 689404 push 0494 ;HERE! NOTICE OF EXPIRATION
:0008.17D5 685505 push SEG ADDR of Segment 0028
:0008.17D8 684C15 push 154C
:0008.17DB FF362C0A push word ptr [0A2C]
:0008.17DF 6A00 push 0000
:0008.17E1 6A00 push 0000
:0008.17E3 6A00 push 0000
:0008.17E5 9A34019911 call 000.0134 ;call KERNEL.MAKEPROCINSTANCE
that's the check for all open windows (Useless with 32 bit)
And, please, what do we have at 28.154C?
Exported fn(): DLGPROCDEMO - Ord:0019
:0028.154C 8CD8 mov ax, ds
:0028.154E 90 np (always suspect these
funny nops, somebody patched here?... :=)
:0028.154F 45 inc bp
:0028.1550 55 push bp
:0028.1551 8BEC mov bp, sp
:0028.1553 1E push ds
:0028.1554 8ED8 mov ds, ax
:0028.1556 83EC02 sub sp, 0002
:0028.1559 56 push si
:0028.155A 8B4E0C mov cx, [bp+0C] ;fetch bp+C
:0028.155D 8BC1 mov ax, cx
:0028.155F 2D0F00 sub ax, 000F
:0028.1562 740E je 1572 ;was it 15?
:0028.1564 2D0101 sub ax, 0101 ;was it 272?
:0028.1567 7425 je 158E
:0028.1569 48 dec ax
:0028.156A 7454 je 15C0 ;273?
:0028.156C 33C0 xor ax, ax
:0028.156E E98900 jmp 15FA
A jump below followed by a switch tree... is it interesting for
us? You'll answer!
Finally, let's have a look at the THIRD and last occurrence of
our "Notice of expirations" at block 52 at 2465:
* Possible Ref to Menu: MAINMENU, Item: "Future Transactions"
|
:0052.2449 6A02 push 0002
:0052.244B 9AE00ED424 call 0006.0EE0
:0052.2450 837EF800 cmp word ptr [bp-08], 0000
:0052.2454 7503 jne 2459
:0052.2456 E9CE00 jmp 2527
:0052.2459 8B5EFC mov bx, [bp-04]
:0052.245C FF7718 push word ptr [bx+18]
:0052.245F 9AFFFF0000 call USER.GETPARENT
:0052.2464 50 push ax
* Possible Reference to Dialog: DialogID_0494
|
:0052.2465 689404 push 0494 ;HERE! NOTICE OF EXPIRATION
* Possible Ref to Menu: MAINMENU, Item: "Account Book"
|
:0052.2468 6A01 push 0001
:0052.246A 6A00 push 0000
:0052.246C 6A00 push 0000
:0052.246E 9A1B250000 call USER.SENDMESSAGE
Well, I think this is enough:
The crack for it is pretty obvious, is it?
Let's start with a simple substitution:
instead of
:0008.17D0 7246 jb 1818
let's have
:0008.17D0 55 push bp
:0008.17D0 5D pop bp
(nooping it)
That's it, folk!... but, wait... all this DOES NOT work
correctly... did I forgot something?
THAT's the Strainer! Solve it (you have time until SEPTEMBER 1997).
THE STRAINER: SOLVE IT!
You want to be a +HCUker? SOLVE the crack for MS-Money (old
version and new version), I want to get from you (directly to
na526164@anon.penet.fi if it still works or else through channel
you have to find yourself)
1) The complete and WELL described crack to MSMONEY version 3 (1994)
(60 days trial protection)
2) The complete and WELL described crack to MSMONEY 97 (1997)
(90 days trial protection)
3) The reason for the crack I used for Winproject instead of
nooping the alternative location... which would have seen more
obvious at first glance.
I would like you (since these cracks are alltogether much
more easy than the Instant access strainer we used last year) to
DELVE DEEP inside the date-encryption routines of these programs,
explaining them perfectly.
Please use a language that newbyes can easily follow... I
do not intend to work in order to re-explain once more things you
should have explained well in the first time.
Best protection busters (and best approaches) will enter the
+HCU. Lamers and people that have copied from other will be left
out.
+HCU 1998 will begin on 1 Januar 1998. The above solutions
must be sent to me BEFORE september 1997. Should anon.penet die,
I'll reopen another anonymous channel end August.
Well, that's it for this lesson, reader. Not all lessons of my
tutorial are or will be on the Web.
You'll obtain the missing lessons IF AND ONLY IF you mail
me back (via anon.penet.fi) with some tricks of the trade I may
not know that YOU discovered. Mostly I'll actually know them
already, but if they are really new you'll be given full credit,
and even if they are not, should I judge that you "rediscovered"
them with your work, or that you actually did good work on them,
I'll send you the remaining lessons nevertheless. Your
suggestions and critics on the whole crap I wrote are also
welcomed. Do not annoy me with requests for warez, everything is
on the Web, learn how to search, for Hiawatha sake.
"If you give a man a crack he'll be hungry again
tomorrow, but if you teach him how to crack, he'll
never be hungry again"
E-mail
+ORC
+ORC na526164@anon.penet.fi