Announcement and final word on the CheatHappens vs. h4x0r trainer war

[Joe Forster/STA]

Bioshock_v1.1_+_10_Trainer_REAL.rar

Compiled using delphi - cheatengine usage is obvious
check file offset 0x50 (80 decimal) - this is where cheatengine stores the pointer to its 'data'
in this trainer, its located at 00 F8 20 00 = 0x0020f800 as the file offset, this is easily verified

0020F800: 22 23 02 00-07 00 00 00-0E 00 00 00-01 00 00 00 "#☻ • ♫ ☺
0020F810: 31 06 00 00-00 49 6E 73-65 72 74 2D-00 00 00 00 1♠ Insert-
0020F820: 00 00 00 00-00 00 00 00-00 06 00 00-00 37 13 AD ♠ 7‼¡
0020F830: DE 00 00 00-00 00 00 00-00 00 00 FF-00 00 00 01 Ì * ☺
0020F840: 00 00 00 00-00 00 00 88-02 00 00 5A-47 4D 45 47 ê☻ ZGMEG

022322 = cheatengine 'tag' for memory trainer, 'protected' (ie: can't be opened in cheat engine to view its 'work')
and yes, its easily bypassed (changing to 022222 works partially, 111111 is the value used to do a file patcher)..

now, look at the import table, there are multiple entries for dll's of the same name - this is a typical characteristic
of delphi..

Linker version is 2.25 in the PE header- again.. typical of delphi..

manifest information is..

<assembly xmlns="urn:schemas-microsoft-com:asm.v1" manifestVersion="1.0">
<assemblyIdentity
type="win32"
name="DelphiApplication"
version="1.0.0.0"
processorArchitecture="*"/>
<trustInfo xmlns="urn:schemas-microsoft-com:asm.v3">
<security>
<requestedPrivileges>
<requestedExecutionLevel level="requireAdministrator"/>
</requestedPrivileges>
</security>
</trustInfo>

<dependency>
<dependentAssembly>
<assemblyIdentity
type="win32"
name="Microsoft.Windows.Common-Controls"
version="6.0.0.0"
publicKeyToken="6595b64144ccf1df"
language="*"
processorArchitecture="*"/>
</dependentAssembly>
</dependency>
</assembly>

------------------

Bioshock_v1.1_+_10_Trainer.rar

Well, for a start, we can see this exe is NOT delphi compiled - its coded in c..

the cheatengine pointer is also NOT present
cheatengine data is also NOT present (did a search for it)..

Linker version is 2.50 - i've never seen this before in a delphi exe

Import table does NOT have multiple entries for the same dll's of the same name
msvcrt.dll is also imported - this is DEFINATELY NOT a delphi executable

Rich information is also removed in the pe header - probably to reduce any possible method of fingerprinting the origin
typically the c compiler does NOT remove this information...

manifest information is.. (note - only 0xA is used here, NOT 0xD 0xA for cr/lf... bit strange)

<?xml version="1.0" encoding="UTF-8" standalone="yes"?>◙<assembly xmlns="urn:schemas-microsoft-com:asm.v1" manifestVersion="1.0">◙ <assemblyIdentity◙ versi
on="1.0.0.0"◙ processorArchitecture="X86"◙ name="CompanyName.ProductName.YourApp"◙ type="win32" />◙ <description></description>◙ <dependency>◙ <d
ependentAssembly>◙ <assemblyIdentity◙ type="win32"◙ name="Microsoft.Windows.Common-Controls"◙ version="6.0.0.0"◙ processorArch
itecture="X86"◙ publicKeyToken="6595b64144ccf1df"◙ language="*" />◙ </dependentAssembly>◙ </dependency>◙◙</assembly>

icon is also for CH.....

------------------

initial overview

from this initial analysis we can see that both exe's were coded in ENTIRELY different languages,
the fake trainer is NOT even using cheatengine code...

entrypoint of fake trainer code is..

.00401000: 6838000000 push 000000038 ;' 8'
.00401005: 6800000000 push 0
.0040100A: 68D0BD6100 push 00061BDD0 --↓1
.0040100F: E80C100000 call memset --↓2
.00401014: 83C40C add esp,00C

using memset.. delphi wouldn't do that...

the program then tries to launch a file from the temp folder..

0017FD8C 02950598 ASCII "C:\Users\Admin\AppData\Local\Temp\Bioshock v1.1 + 10 Trainer.exe"

(which did not exist on first run)..

00402482 |. FF15 5CBB6100 call dword ptr [<&KERNEL32.CreateProcessA>] ; \CreateProcessA

is where its done..

it then tries to do a ShellExecuteExA...

004025DE |. FF15 90BB6100 call dword ptr [<&SHELL32.ShellExecuteExA>] ; SHELL32.ShellExecuteExA

0017FF50 00402A46 /CALL to CreateFileA from Bioshock.00402A44
0017FF54 00405057 |FileName = "C:\h4x0r.dll"
0017FF58 C0000000 |Access = GENERIC_READ|GENERIC_WRITE
0017FF5C 00000001 |ShareMode = FILE_SHARE_READ
0017FF60 00000000 |pSecurity = NULL
0017FF64 00000002 |Mode = CREATE_ALWAYS
0017FF68 00000080 |Attributes = NORMAL
0017FF6C 00000000 \hTemplateFile = NULL

this fails if uac is enabled (drive protected)... so i had to force the code to dump the dll to another location
the code also tries to make the file hidden, and has a bug later on where it does a SetFileAttributesA (hidden) with
a null pointer for the filename (which obviously fails)..

the h4x0r.dll is definately packed and not a 'normal' executable..
the import table is BAD.. and on my machine at least, the dll would NOT load..