Fuck Off, TDT for The Dream Team (TDT) by Razor 1911 (RZR)
101 of 803 files
razor 1911
- Browsers may flag this download as unwanted or malicious. If unsure, scan it with VirusTotal.
-
Last modified
MD5 checksum 93868f6111cb3e1898cf3d2ed1bd414d
Mime type ISO-8859 text, with CRLF line terminators
Download TDTLAME.nfo
Size 9 kB
1992 October 4
In this textfile, I will rag on TDT and the whole bunch of lamers associated with them. Also, I will explain WHY I'm doing this. The reason is the recent release of Might & Magic IV by FairLight, TDT and of course RAZOR.
- Text / Community drama
- Onyx, writer credits
-*-*-*-*-*-* FUCK OFF, TDT *-*-*-*-*-*-
In this textfile, I will rag on TDT and the whole bunch of lamers
associated with them. Also, I will explain WHY I'm doing this. The
reason is the recent release of Might & Magic IV by FairLight, TDT
and of course RAZOR. First off, the Razor version was the only one
that has been put out COMPLETELY CRACKED AND WORKING unlike the
Flt and TDT versions. Now, two days later TDT puts out a "crackfix"
which is supposed to be 100% and that "you can use on the Razor and
FLT versions". Of course I was very suspicious about TDT's late
fix and so I downloaded this shit and looked at it since they
claimed that there was more than ONE doc check in the game. Here's
what I found....
┌────────────────────────────────────┐
│TDT - how stupid they REALLY are....│
└────────────────────────────────────┘
OK, let's start. I will explain a _little_ of tech background to
you so that you're able to understand what I'm talking about.
The actual protection routine in Might & Magic IV is located in
a file called XEEN.DAT. This file is not a data file, but a renamed
EXE file. Also, New World Computing used PKLite to compress it and
make it harder to change stuff in it, however, we all know how to
get rid of PKlite, don't we ?
OK, well, after I got rid of PKLite I ran a filecompare between my
version and the one TDT put out. Here's the result:
Comparing files XEEN.DAT and MYXEEN.DAT
0001DD2A: 8E 38 <──────────────────────────────┐
00026C9D: 90 9A <────┐ │
00026C9E: 90 00 <────┤ │
00026C9F: 90 00 <────┤ │
00026CA0: 90 CC <────┤ this is the only
00026CA1: 90 15 <────┤ byte required to
│ crack the game.
│
these are the bytes TDT
changed to "crack" the game.
Now, here's a litte explanantion of the bytes and what they mean.
If you don't know alot of assembly, don't worry if you don't
understand it. Actually the whole point of all this is that the
TDT version IS NOT WORKING ! Hahaha... Yes, you got me right.
TDT FUCKED UP THEIR CRACK, if you try to bypass the protection,
THE GAME WON'T LET YOU CONTINUE PLAYING.
Let me just explain what I did to crack the game:
The first byte you see at 1DD2A is an offset for a JMP instruction.
The original value in an uncracked version of MMIV is 8E and to
crack the game I changed it to 38. The reason is that the JMP
originally leads to the protection routine that asks you to enter
a certain word from a certain page in the manual. What I did is
to bypass the protection check in a way that the routine assumes
that you've already entered the correct word. That's why in my
version the protection doesn't even show up anymore. Also, that
way I don't have to worry HOW MANY protection checks there are in
the game. No matter how many times the protection routine is called,
it will ALWAYS return the correct result and let you go on playing.
Now, in the TDT version SOMEONE thought he has to be a REAL smartass
motherfucker. Here is what the dumbass did:
Translated to assembly, the five bytes starting at 26C9D will come
out as a FAR call instruction
CALL 15CC:0000
This CALL will lead to the protection and ask you for a word
from the manual.
TDT's lame-o cracker changed this CALL-instruction to something
else:
NOP
NOP
NOP
NOP
NOP
Well, what the dick was trying to do is to bypass the protection
simply by not even CALLING the protection routine. So, what's
wrong you may ask, if the protection is not even called, what is
Onyx moaning about !? Well, let me explain.
First of all there might be more than ONE call to the protection in
the game. The way I cracked it, the protection may be called 100reds
of times and each time it will come out fine, but in the TDT version
you can't be sure that there's not another CALL to the protection
somewhere else in the game. So, how do you fuckers in TDT even DARE
to tell people that "there's more than ONE check in the game", eh ?
DON'T YOU LAMERS UNDERSTAND THAT EVEN IF THERE IS MORE THAN ONE
CHECK, YOUR GODDAMN VERSION WILL NOT WORK UNDER ANY CIRCUMSTANCES
BECAUSE YOU ONLY REMOVED *ONE* OF THEM ? Fuck you lamers, you should
go back to cracking school and LEARN how to do things correctly.
┌──────────────────────────────────────┐
│TDT - my grandma can do better cracks │
└──────────────────────────────────────┘
Now here's what's even WORSE about TDT's crack:
Due to the fact that the file XEEN.DAT is an EXE file, it contains
lots of addresses that have to be relocated when the file is loaded
to memory. This is refered to as the relocation table. I will not
go into a too much detailed explanation of the EXE file structure
here, but it all comes down to the fact that Sir Platinum doesn't
seem to know a shit about DOS and EXE files.
Each entry in the relocation table points to an instruction of
the program that needs to be altered to make the program work.
Something called a SEGMENT-OFFSET has to be added to some instructions
to make them work correctly. In this case, the CALL instruction that
TDT changed needed to be relocated. To make it a little bit more
understandable for you, here's an example:
un-relocated instruction: bytes in memory:
CALL 15CC:0000 9A 00 00 CC 15
Now, let's assume the program has been loaded to segment offset 1234
the whole thing would look like this AFTER the relocation:
relocated instruction: bytes in memory:
CALL 2800:0000 9A 00 00 00 28
The segment offset of 1234 has been ADDED to the original offset
of 15CC. The result is 2800. This is how it SHOULD look like.
Now how did TDT fuck up ? Here's how....
Since DOS does an automatic relocation of all entries in the
relocation table, it will not check if the relocation it just made
was VALID. To cut a long explanation short, here's what it looks
like with the TDT version:
^^^
un-relocated instruction(s): bytes in memory:
NOP 90
NOP 90
NOP 90
NOP 90
NOP 90
After the relocation process....
relocated instruction(s): bytes in memory:
NOP 90
NOP 90
NOP 90
LES SP,[BP+SI+0509] C4 A2 ....
The offset 1234 has been added to the 9090 bytes that represtented
the NOP instructions.
Due to the fact that Sir Platinum changed the original JMP
instruction to NOP instructions, the relocation will create
a new, UNPREDICTABLE instruction instead of the NOPs. As a
result THE GAME MIGHT EVEN CRASH ! YES, YOU GOT IT RIGHT, THE
WAY TDT CRACKED THIS MIGHT CRASH THE GAME ! Fuck you kids...
You apparently don't know a flying fuck about what you're doing.
Don't you fuckers know that according to what is added to your
NOP instuctions the actual CODE changes every time ? The instruc-
tions created might be total NONSENSE and lock up the game.
Goddamnit.... you lamers are so fucken stupid, you shouldn't be
allowed to touch games like Might & Magic IV since all you do is
to FUCK THEM UP.
OK, Sir Lametinum, here's what you COULD have done even tho it
STILL wouldn't get rid of ALL the doc checks in the game, just
this particular one:
9A 00 00 CC 15 CALL 15CC:0000
could have been changed to
90 NOP
EB 02 JMP IP+02 <─┐jumps OVER the relocation
CC 15 XXXX │offset.
.. ..<─────────┘
. .
Obviously you're not a proffessional cracker, just a little dumb-o
wannbe that still has alot to learn to play in the MAJOR LEAGUE
together with the BIG BOYS....
Also, to all of you out there, take this as a WARNING and think twice
before you decide to download a TDT release in the future. Who knows,
the "change" they make to a program might accidently format your hard
drive....
GO FOR QUALITY - GO FOR RAZOR RELEASES ! WE KNOW OUR BUSINESS !
- ONYX [RAZOR 1911]
10/04/92