xREL.v3

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>