H A T R E D P R E S E N T
Football Manager 2008 (c) SEGA Europe
18/10/2007 :.. Rel.date . protection ..: SecuROM
0 :.... DVD(s) . genre .......: Sport
FAIRLIGHT: We nuked you because you propered us without a valid
reason.
Unfortunately we have to defend our crack since we are again being
attacked with false accusations.
First we had to defend our OpenEvent check fix. You made no
follow-up comment so we assume you have accepted by now that we
were right about that.
You then continue with accusations and include 4 examples of
so-called triggers that you claim we haven't fixed.
Example #1:
026D051D CALL DWORD PTR DS:[<&KERNEL32.GetCurrentProcessId>]
026D0523 XOR EAX,DWORD PTR DS:[ESI+244]
026D0529 JE 026D0535
Quick explanation: GetCurrentProcessId is called at 026D051D. EAX
now holds the current process id at 026D0523. EAX is then XORed
with [ESI+244]. If [ESI+244] also holds the current process id
then the XOR operation will result in a jump taken at 026D0529
(good-boy scenario), if however [ESI+244] holds anything else than
the current process id it will result in a jump not taken at
026D0529 (bad-boy scenario). So the fact that we haven't patched
anything here does not prove that we have overlooked this check.
If [ESI+244] holds the correct process id at the time of execution
then everything is ok.
We have fixed the problem at its source which is the SecuROM API
calls. By fixing that we have made sure that the proper current
process id is always in place when these checks are later
performed no matter if there are 20 or 100.
Here is an example of how the current process id is retrieved via
SecuROM API call (and later checked).
00EE7ED0 33DB XOR EBX,EBX
00EE7ED2 8D86 44020000 LEA EAX,DWORD PTR DS:[ESI+244] ; [ESI+244] sure looks familiar doesn't it?
00EE7ED8 C706 F4136201 MOV DWORD PTR DS:[ESI],fm.016213F4
00EE7EDE C746 04 E4136201 MOV DWORD PTR DS:[ESI+4],fm.016213E4
00EE7EE5 C746 08 BC136201 MOV DWORD PTR DS:[ESI+8],fm.016213BC
00EE7EEC C746 0C B0136201 MOV DWORD PTR DS:[ESI+C],fm.016213B0
00EE7EF3 C746 10 88136201 MOV DWORD PTR DS:[ESI+10],fm.01621388
00EE7EFA C786 40020000 01000000 MOV DWORD PTR DS:[ESI+240],1
00EE7F04 8918 MOV DWORD PTR DS:[EAX],EBX
00EE7F06 895D FC MOV DWORD PTR SS:[EBP-4],EBX
00EE7F09 C705 A0326802 28B11602 MOV DWORD PTR DS:[26832A0],fm.0216B128
00EE7F13 A3 A4326802 MOV DWORD PTR DS:[26832A4],EAX
00EE7F18 68 A0326802 PUSH fm.026832A0
00EE7F1D E8 6FBD7E01 CALL fm.026D3C91
026D3C91 50 PUSH EAX
026D3C92 53 PUSH EBX
026D3C93 FF15 24E11D01 CALL DWORD PTR DS:[<&KERNEL32.GetCurrentProcessId>] ; KERNEL32.GetCurrentProcessId
026D3C99 8B5C24 0C MOV EBX,DWORD PTR SS:[ESP+C]
026D3C9D 8B5B 04 MOV EBX,DWORD PTR DS:[EBX+4]
026D3CA0 8903 MOV DWORD PTR DS:[EBX],EAX
026D3CA2 5B POP EBX
026D3CA3 58 POP EAX
026D3CA4 C2 0400 RETN 4
00EE7F22 EB 0E JMP SHORT fm.00EE7F32
Example #2:
026D09CC CALL DWORD PTR DS:[<&KERNEL32.GetCurrentProcessId>]
026D09D2 XOR EAX,DWORD PTR DS:[ESI+244]
026D09D8 JE 026D09E4
Same story...
Example #3:
026D169D CALL DWORD PTR DS:[<&KERNEL32.GetCurrentProcessId>]
026D16A3 XOR EAX,DWORD PTR DS:[ESI+244]
026D16A9 JE 026D16B5
Same story...
Example #4:
00EE1567 PUSH 026832A0
00EE156C CALL 026D3C91
00EE1571 JMP 00EE1581
Nothing is even wrong here!
Conclusion: FAIRLIGHT fixes "triggers" or as we like to call them
in this context "SecuROM API calls" in a different way than we do,
does that mean we did not fix them? No.
You then claim that our crack "crashes randomly when saving to
database". You present no proof that these crashes you are
supposedly experiencing have anything to do with our crack and you
certainly do not prove any connection between the code examples
and these claimed crashes.
We know of NO random crashes.
It's also interesting that you forgot to mention this issue in
your initial NFO, perhaps you realized that you were wrong when
you stated that our OpenEvent check was not fixed properly and
then needed another proper-reason to justify the release - who
knows.
"We are sure there are lot of other problems with your crack" -
well this is just pure speculation. Since when is it okay to
proper because you "feel" sure there are more problems?
"Nuking proper release because your crack is bad is just lame,
this just trury shows how inmature group you are." - our crack is
not bad and any further comments would probably qualify as
"trury inmature" :)
You made an invalid proper and therefore you were nuked.
HATRED does not condone in selling warez of any kind.
HATRED does not respect any p2p networks, NFOrce or
anything to make the scene more public.
HATRED does not believe in using a lesser protected
executable whether it be a steam exe, unprot exe,
demo exe, activemark exe, direct2drive exe or any
other weaker protected exe to make a cheap copy/paste
code exe and then label it as a crack. Nor do we
believe in any other sorts of cheap workarounds.
We greet the respectable groups like:
RELOADED - GENESIS - BACKLASH - DELIGHT - RAZOR1911
ascii art by barium<SAC>
Sprache wählen 
Registrierte Benutzer können Text-, Hintergrund- und ANSI-Art-Farbe individuell anpassen! 
