Player structure for bf2142

[SINE]

As you all know, bf2142 seems more like a mod than a full game and internal structures did not change much. Here is what I found.

dwPlayer = reference of player struture


isCommander: dwPlayer+0x10c
1 byte flag
1 – commanding, 0 – not commanding

team id: dwPlayer+0xd8
1 byte flag
eu: 2, pac: 1

isAlive: (dwPlayer+0xd5) && (!dwPlayer+0xe0)
flag has to be calculated based on "isspawned" and "iscriticalywounded" flags. result:
1: alive, 0: exploded, disconnected or critically wounded

weapon fov: (float32)dwPlayer+0xc0
world fov: (float32)dwPlayer+0xc4 (always equal)
possibly different for non 4:3 aspect resolutions, i havent tested.

nickname: (char[16])dwPlayer+0x64 or, if longer than 15 or 16 chars, (char*)[dwPlayer+0x64]
This is eithr nickname directly, or pointer to nickname, if exceeds 15 characters. Same for vehicle name (below):

vehicle name: [dwPlayer+0x80]+4]+x24]+0x1a4
or if longer than 15 chars:
[[dwPlayer+0x80]+4]+x24]+0x1a4]

vehicle type (?): [dwPlayer+0x80]+4]+x24]+0x1b4
this does not correspond to vehicle class info from .tweak files, so this is probably useless.

viewmatrix for localplayer: [dwPlayer+0x84] + 0xc8
(16 floats 32b)

position: [dwPlayer+0x84]-0x178
3 floats (32b)
(that works also for other players)

alternate position reading: [[dwPlayer+0x80]+4]+0xd0
this one is updated more frequently for distant targets but this marks coordinates of enemy feet rather than head, as with previous offset

enemy pitch vector components:
x component address: [dwPlayer+0x84]+0x194
y component address: [dwPlayer+0x84]+0x1A4

enemy azimuth components:
x component address: [dwPlayer+0x84]+0x1a0
y component address: [dwPlayer+0x84]+0x198

player pose: [[dwPlayer+0x80]+4]+0x26c
0 - standing, 1 - ducking, 2 - prone

Now if someone is after player references they are very easy to get ahold of. just check virtual function 0xf (+0x3c in vtable) of playermanager (0xA6A814 in demo):

body of the function is as follows (demo offsets):

004AF7D0 55 PUSH EBP
004AF7D1 8BEC MOV EBP,ESP
004AF7D3 83EC 4C SUB ESP,4C
004AF7D6 53 PUSH EBX
004AF7D7 56 PUSH ESI
004AF7D8 57 PUSH EDI
;; edi - team id
004AF7D9 8BF9 MOV EDI,ECX
004AF7DB 6A 00 PUSH 0
004AF7DD 8D77 18 LEA ESI,DWORD PTR DS:[EDI+18]
;; edi = cplayermgr
004AF7E0 6A 00 PUSH 0
004AF7E2 8BCE MOV ECX,ESI
004AF7E4 897D F8 MOV DWORD PTR SS:[EBP-8],EDI
004AF7E7 E8 B4F3FFFF CALL BF2142.004AEBA0
;; changes EAX (later ignored), ecx (ignored), edx (ignored) and esp
004AF7EC 8B47 10 MOV EAX,DWORD PTR DS:[EDI+10]
;; eax = [cplayermanager]+10 - looks like pointer table
004AF7EF 8B18 MOV EBX,DWORD PTR DS:[EAX]
;; this is also a pointer table
004AF7F1 3BD8 CMP EBX,EAX
004AF7F3 74 4D JE SHORT BF2142.004AF842
;; first end-of-list condition, apparently - for noplayer situation, perhaps
004AF7F5 8B4B 08 MOV ECX,DWORD PTR DS:[EBX+8]
;; thats our first player reference!
004AF7F8 8B01 MOV EAX,DWORD PTR DS:[ECX]
;; and thats cplayer virtual table, whatever
004AF7FA 894D FC MOV DWORD PTR SS:[EBP-4],ECX
004AF7FD FF90 F4000000 CALL DWORD PTR DS:[EAX+F4]
;; CPlayer->getTeamID, apparently
004AF803 3B45 08 CMP EAX,DWORD PTR SS:[EBP+8]
;; are teams the same?
004AF806 75 33 JNZ SHORT BF2142.004AF83B
004AF808 8B7E 04 MOV EDI,DWORD PTR DS:[ESI+4]
;; esi is still cplayermanager+x18
004AF80B 8B57 04 MOV EDX,DWORD PTR DS:[EDI+4]
;; another pointer table
004AF80E 8D4D FC LEA ECX,DWORD PTR SS:[EBP-4]
004AF811 51 PUSH ECX
004AF812 52 PUSH EDX
004AF813 57 PUSH EDI
004AF814 8BCE MOV ECX,ESI
;; esi = ecx = cplayermanager+x18
004AF816 E8 A5E4FAFF CALL BF2142.0045DCC0
;; changes eax, ecx (ignored), edx (ignored), esp
004AF81B 8B4E 08 MOV ECX,DWORD PTR DS:[ESI+8]
004AF81E BA FFFFFF3F MOV EDX,3FFFFFFF
004AF823 2BD1 SUB EDX,ECX
004AF825 83FA 01 CMP EDX,1
004AF828 72 23 JB SHORT BF2142.004AF84D
004AF82A 83C1 01 ADD ECX,1
004AF82D 894E 08 MOV DWORD PTR DS:[ESI+8],ECX
;; saves something in cplayermanager structure - maybe part of end list conditon
004AF830 8947 04 MOV DWORD PTR DS:[EDI+4],EAX
;; as abobe (eax derived by f:045dcc0) points to some pointer table
004AF833 8B48 04 MOV ECX,DWORD PTR DS:[EAX+4]
;; ecx points to another pointer table - deja vu with beginning of function
004AF836 8B7D F8 MOV EDI,DWORD PTR SS:[EBP-8]
;; edi points to cplayer manager
004AF839 8901 MOV DWORD PTR DS:[ECX],EAX
004AF83B 8B1B MOV EBX,DWORD PTR DS:[EBX]
;; Hooray, EBX was not changed through the whole function!
004AF83D 3B5F 10 CMP EBX,DWORD PTR DS:[EDI+10]
;; edi+10 points to cplayermanager+10, most likely our end loop condition
004AF840 ^75 B3 JNZ SHORT BF2142.004AF7F5
;; end loop condition check (remember, EBX was set above to next element of pointer table!)
004AF842 5F POP EDI
004AF843 8BC6 MOV EAX,ESI
004AF845 5E POP ESI
004AF846 5B POP EBX
004AF847 8BE5 MOV ESP,EBP
004AF849 5D POP EBP
004AF84A C2 0400 RETN 4

thats actually from demo, but it is not much different in retail. what it does is not relevant, but it is kind enough to iterate through the whole list of players - references are hold in EBX register throughout the whole LOOP cycle. bottom line is that you can access player references by going through simplelinked list, as follows:

[[[[0A6A814]+x10]]+8] - first player
[[[[[0A6A814]+x10]]]+8] - 2nd player
[[[[[[0A6A814]+x10]]]]+8] - 3rd player

Thats for demo, but relative offsets did not change in retail or 1.01 - only playermanager offset changed, and finding that easily is left as an excercise to the reader.

for different turrets, proportional and differential constants needed for regulators are stored in .tweak files. i havent figured out the gravity constant yet, though i am sure onec i have some time i will find it :-)

sorry for typos etc. but i am too busy to read it twice :-) offsets should be generally working. i am anxious to see more of those ugly haxxors to have some real challenges, and not just some absurd k/d ratio i enjoy now.

Credits go to DrunkenCheatah for StructBuilder (that "0wns" ;-) and Tachyon
Greetings to Zaxxz, Jaamsma and Dubbls

Sine

[KizZamP-]

Can't believe nobody has replied yet.

Awesome job !

[SINE]

thx :-)
Sine

[DrUnKeN ChEeTaH]

Good work, just a few comments...

The playername (dwPlayer+0x64) or Vehicle name is just a std::string...


class CPlayer
{
public:
virtual void Function0();
virtual void Function1();
virtual void Function2();
virtual void Function3();
virtual void Function4();
virtual void Function5();
virtual void Function6();
virtual void Function7();
virtual string* GetName();
...
...

then you can just do this:
Player->GetName()->c_str();
or
cast the address directly to string using your values


and maybe this will help with getting players...
GetPlayerByIndex(int Index); returns a valid CPlayer or NULL


class CPlayerManager
{
public:
virtual void AddRef();
virtual int ******();
virtual void Release();
virtual void Function2();
virtual void Function3();
virtual void Function4();
virtual void Function5();
virtual void Function6();
virtual CPlayer* GetPlayerByIndex(int Index);
virtual void Function8();
virtual void Function9();
virtual void Function10();
virtual CPlayer* GetLocalPlayer();

char unknown0[16];
DWORD TotalPlayers; //0014
char unknown1[84];
CPlayer* LocalPlayer; //006C
};

[SINE]

Thx! I think there will be a whole lot more nice hacks for bf2142 than for bf2. Mostly because of the unlocks and what they provide - there is some unlock for uav hoovering above SL, an unlock for viewing enemy kit's, there is even an unlock for prolonging tag fade time (so stickytags, as i understand, can return and be undetectable forever :-). I am dead sure most if not all of these are exploitable client side, enabling some visual aids that can not be detected by screenshot analysis. Once I have some time (now I barely have time to code or play) I will be looking for these. I am sure it will be a LOT of fun ;-)

cheers, Sine

[peek]

Agree with U. I played demo for now and all commander sets are still hackable and can be unlimited.
DICE didn't learn anything from past...

b.r


Thx! I think there will be a whole lot more nice hacks for bf2142 than for bf2. Mostly because of the unlocks and what they provide - there is some unlock for uav hoovering above SL, an unlock for viewing enemy kit's, there is even an unlock for prolonging tag fade time (so stickytags, as i understand, can return and be undetectable forever :-). I am dead sure most if not all of these are exploitable client side, enabling some visual aids that can not be detected by screenshot analysis. Once I have some time (now I barely have time to code or play) I will be looking for these. I am sure it will be a LOT of fun ;-)

cheers, Sine

[Tachyon]

Good work, just a few comments...

The playername (dwPlayer+0x64) or Vehicle name is just a std::string...


class CPlayer
{
public:
virtual void Function0();
virtual void Function1();
virtual void Function2();
virtual void Function3();
virtual void Function4();
virtual void Function5();
virtual void Function6();
virtual void Function7();
virtual string* GetName();
...
...

then you can just do this:
Player->GetName()->c_str();
or
cast the address directly to string using your values


and maybe this will help with getting players...
GetPlayerByIndex(int Index); returns a valid CPlayer or NULL


class CPlayerManager
{
public:
virtual void AddRef();
virtual int ******();
virtual void Release();
virtual void Function2();
virtual void Function3();
virtual void Function4();
virtual void Function5();
virtual void Function6();
virtual CPlayer* GetPlayerByIndex(int Index);
virtual void Function8();
virtual void Function9();
virtual void Function10();
virtual CPlayer* GetLocalPlayer();

char unknown0[16];
DWORD TotalPlayers; //0014
char unknown1[84];
CPlayer* LocalPlayer; //006C
};


@DrUnKeN ChEeTaH
Tnx.....no more checking bytes for being ASCII or non-ASCII :-)

@Sine:
Will be useful for Master-Slave target mode.... ;)
Btw. are there any public aimbots which communicate directly with each other for better group logic ?
Lol maybe we can make a lot of money with this idea :-) :-) :-)

Tachyon