What are the m_fFlags and dwForceJump offsets?

m_fFlags and dwForceJump are both bitfields

Homework

m_fFlags

C++: // CBaseEntity::m_fFlags // PLAYER SPECIFIC FLAGS FIRST BECAUSE WE USE ONLY A FEW BITS OF NETWORK PRECISION // This top block is for singleplayer games only....no HL2:DM (which defines HL2_DLL) #if !defined( HL2MP ) && ( defined( PORTAL ) || defined( HL2_EPISODIC ) || defined ( HL2_DLL ) || defined( HL2_LOSTCOAST ) ) #define FL_ONGROUND (1<<0) // At rest / on the ground #define FL_DUCKING (1<<1) // Player flag -- Player is fully crouched #define FL_WATERJUMP (1<<2) // player jumping out of water #define FL_ONTRAIN (1<<3) // Player is _controlling_ a train, so movement commands should be ignored on client during prediction. #define FL_INRAIN (1<<4) // Indicates the entity is standing in rain #define FL_FROZEN (1<<5) // Player is frozen for 3rd person camera #define FL_ATCONTROLS (1<<6) // Player can't move, but keeps key inputs for controlling another entity #define FL_CLIENT (1<<7) // Is a player #define FL_FAKECLIENT (1<<8) // Fake client, simulated server side; don't send network messages to them // NON-PLAYER SPECIFIC (i.e., not used by GameMovement or the client .dll ) -- Can still be applied to players, though #define FL_INWATER (1<<9) // In water // NOTE if you move things up, make sure to change this value #define PLAYER_FLAG_BITS 10 #define FL_FLY (1<<10) // Changes the SV_Movestep() behavior to not need to be on ground #define FL_SWIM (1<<11) // Changes the SV_Movestep() behavior to not need to be on ground (but stay in water) #define FL_CONVEYOR (1<<12) #define FL_NPC (1<<13) #define FL_GODMODE (1<<14) #define FL_NOTARGET (1<<15) #define FL_AIMTARGET (1<<16) // set if the crosshair needs to aim onto the entity #define FL_PARTIALGROUND (1<<17) // not all corners are valid #define FL_STATICPROP (1<<18) // Eetsa static prop! #define FL_GRAPHED (1<<19) // worldgraph has this ent listed as something that blocks a connection #define FL_GRENADE (1<<20) #define FL_STEPMOVEMENT (1<<21) // Changes the SV_Movestep() behavior to not do any processing #define FL_DONTTOUCH (1<<22) // Doesn't generate touch functions, generates Untouch() for anything it was touching when this flag was set #define FL_BASEVELOCITY (1<<23) // Base velocity has been applied this frame (used to convert base velocity into momentum) #define FL_WORLDBRUSH (1<<24) // Not moveable/removeable brush entity (really part of the world, but represented as an entity for transparency or something) #define FL_OBJECT (1<<25) // Terrible name. This is an object that NPCs should see. Missiles, for example. #define FL_KILLME (1<<26) // This entity is marked for death -- will be freed by game DLL #define FL_ONFIRE (1<<27) // You know... #define FL_DISSOLVING (1<<28) // We're dissolving! #define FL_TRANSRAGDOLL (1<<29) // In the process of turning into a client side ragdoll. #define FL_UNBLOCKABLE_BY_PLAYER (1<<30) // pusher that can't be blocked by the player #else #define FL_ONGROUND (1<<0) // At rest / on the ground #define FL_DUCKING (1<<1) // Player flag -- Player is fully crouched #define FL_ANIMDUCKING (1<<2) // Player flag -- Player is in the process of crouching or uncrouching but could be in transition // examples: Fully ducked: FL_DUCKING & FL_ANIMDUCKING // Previously fully ducked, unducking in progress: FL_DUCKING & !FL_ANIMDUCKING // Fully unducked: !FL_DUCKING & !FL_ANIMDUCKING // Previously fully unducked, ducking in progress: !FL_DUCKING & FL_ANIMDUCKING #define FL_WATERJUMP (1<<3) // player jumping out of water #define FL_ONTRAIN (1<<4) // Player is _controlling_ a train, so movement commands should be ignored on client during prediction. #define FL_INRAIN (1<<5) // Indicates the entity is standing in rain #define FL_FROZEN (1<<6) // Player is frozen for 3rd person camera #define FL_ATCONTROLS (1<<7) // Player can't move, but keeps key inputs for controlling another entity #define FL_CLIENT (1<<8) // Is a player #define FL_FAKECLIENT (1<<9) // Fake client, simulated server side; don't send network messages to them // NON-PLAYER SPECIFIC (i.e., not used by GameMovement or the client .dll ) -- Can still be applied to players, though #define FL_INWATER (1<<10) // In water // NOTE if you move things up, make sure to change this value #define PLAYER_FLAG_BITS 11 #define FL_FLY (1<<11) // Changes the SV_Movestep() behavior to not need to be on ground #define FL_SWIM (1<<12) // Changes the SV_Movestep() behavior to not need to be on ground (but stay in water) #define FL_CONVEYOR (1<<13) #define FL_NPC (1<<14) #define FL_GODMODE (1<<15) #define FL_NOTARGET (1<<16) #define FL_AIMTARGET (1<<17) // set if the crosshair needs to aim onto the entity #define FL_PARTIALGROUND (1<<18) // not all corners are valid #define FL_STATICPROP (1<<19) // Eetsa static prop! #define FL_GRAPHED (1<<20) // worldgraph has this ent listed as something that blocks a connection #define FL_GRENADE (1<<21) #define FL_STEPMOVEMENT (1<<22) // Changes the SV_Movestep() behavior to not do any processing #define FL_DONTTOUCH (1<<23) // Doesn't generate touch functions, generates Untouch() for anything it was touching when this flag was set #define FL_BASEVELOCITY (1<<24) // Base velocity has been applied this frame (used to convert base velocity into momentum) #define FL_WORLDBRUSH (1<<25) // Not moveable/removeable brush entity (really part of the world, but represented as an entity for transparency or something) #define FL_OBJECT (1<<26) // Terrible name. This is an object that NPCs should see. Missiles, for example. #define FL_KILLME (1<<27) // This entity is marked for death -- will be freed by game DLL #define FL_ONFIRE (1<<28) // You know... #define FL_DISSOLVING (1<<29) // We're dissolving! #define FL_TRANSRAGDOLL (1<<30) // In the process of turning into a client side ragdoll. #define FL_UNBLOCKABLE_BY_PLAYER (1<<31) // pusher that can't be blocked by the player

C++: #define PLAYER_FLAG_BITS 10

How does the game check these bitflags?

C++: if ( GetBasePlayer()->GetFlags() & FL_ONGROUND )

C++: if (GetAsyncKeyState(VK_SPACE) && m_fFlags & (1 << 0)) { writeMem<DWORD>(clientdll + dwForceJump , 6); }

dwForceJump

C++: //These make you jump 0000 0010 = decimal = 2 0000 0011 = decimal = 3 0000 0110 = decimal = 6 0000 0111 = decimal = 7 //These don't make you jump 0000 0100 = decimal 4 0000 1000 = decimal 8

C++: bool IsJumping( void ) { return m_bJumping; }

C++: bool CMultiPlayerAnimState::HandleJumping( Activity &idealActivity ) { if ( m_bJumping ) { if ( m_bFirstJumpFrame ) { m_bFirstJumpFrame = false; RestartMainSequence(); // Reset the animation. } // Check to see if we hit water and stop jumping animation. if ( GetBasePlayer()->GetWaterLevel() >= WL_Waist ) { m_bJumping = false; RestartMainSequence(); } // Don't check if he's on the ground for a sec.. sometimes the client still has the // on-ground flag set right when the message comes in. else if ( gpGlobals->curtime - m_flJumpStartTime > 0.2f ) { if ( GetBasePlayer()->GetFlags() & FL_ONGROUND ) { m_bJumping = false; RestartMainSequence(); } }

C++: if (m_nButtons & IN_JUMP) { Jump(); }

C++: #define IN_ATTACK (1 << 0) #define IN_JUMP (1 << 1) #define IN_DUCK (1 << 2) #define IN_FORWARD (1 << 3) #define IN_BACK (1 << 4) #define IN_USE (1 << 5) #define IN_CANCEL (1 << 6) #define IN_LEFT (1 << 7) #define IN_RIGHT (1 << 8) #define IN_MOVELEFT (1 << 9) #define IN_MOVERIGHT (1 << 10) #define IN_ATTACK2 (1 << 11) #define IN_RUN (1 << 12) #define IN_RELOAD (1 << 13) #define IN_ALT1 (1 << 14) #define IN_ALT2 (1 << 15) #define IN_SCORE (1 << 16) // Used by client.dll for when scoreboard is held down #define IN_SPEED (1 << 17) // Player is holding the speed key #define IN_WALK (1 << 18) // Player holding walk key #define IN_ZOOM (1 << 19) // Zoom key for HUD zoom #define IN_WEAPON1 (1 << 20) // weapon defines these bits #define IN_WEAPON2 (1 << 21) // weapon defines these bits #define IN_BULLRUSH (1 << 22) #define IN_GRENADE1 (1 << 23) // grenade 1 #define IN_GRENADE2 (1 << 24) // grenade 2 #define IN_ATTACK3 (1 << 25)

Does dwForceJump = the m_nButtons bitfield ?

C++: #define IN_JUMP (1 << 1) // 0010 in binary

Does dwForceJump = the m_nButtons bitfield ?

If you know me then you know that I am leading the holy war against pasting. In today's episode we will talk about bitfields, bunnyhops and bullshit.99% of people people don't have any idea what these variables are so I'm gonna explain it. People are writing 4/5/6 in decimal to dwForceJump and they don't even know why...I see this in every pasted CSGO cheat and it's been taught in thousands of tutorials but not a single one tells you what they are. Today we will set the record straight!A bitfield is typically a 4 byte variable where each bit is a bitflag. A bitflag is a bit that represents a bool. Why? To conserve memory and be efficient, better to use a bit than a 1 or 4 byte bool, especially when it comes to networking, every bit saved = less lag. As an integer is 32 bits, you can encode 32 bools into one integer, that's a big savings in memory.So when you read/write integers to these variables or view them in cheat engine you're only working with an abstract form, unless you're viewing the actual bits.m_fFlags is used for model animations ant other things. The two most common bits which are used are the "on the ground" and "client" bits. Here are the m_fFlag and some other constants defined in the Source Engine SDK in const.hThe first 10 are the important onesThey are defining the variables by using the shift left bitwise operator. So when you see ( 1 << 4 ) it means, shift the "1" bit left 4 spaces. The first bit is called the "zero bit" so when you see 1<< 4 it's setting the 4th bit, by moving the bit 4 places to the left.So it starts off as 0000 0001 with the first bit set, then when you shift it left it becomes 0001 0000.How many bitflags are there? Alot but for the player I think there is 10 or 11 based on:Now this is just a the source SDK from 2013, so who knows, there could be more in CSGO and other source engine games.With the "AND" or "&" bitwise operator:FL_ONGROUND = 0001, the first bit is setif you bitwise AND 1 with 1 the result is 1.false = 0;true = !false; -> this means that any value that is NOT ZERO, resolves to trueIf the FL_ONGROUND bit is set, the result of the operation is "true" because the result is nonzero.So how we check this in our hacks? Same way:Wait a second what the hell is that 6 doing there?dwForceJump is a bitfield like m_fFlags encoded in a 32bit integer, so it's defined as an integer but it's bits are checked using bitwise operators.When you're reversing it in Cheat Engine you will typically see it displayed as an integer or as a byte, either way it's in decimal notation not binary. When viewing it as decimal you will notice:4 = not jumping5 = jumpingWhen you set it to 5, it forces you to jump you can also use +jump, but you will notice if you just overwrite it with 5 it gets stuck on 5. It stays on 5 and doesn't change back to 4. If you press the space bar again, you won't jump the first time because the state is improperly set.Because it's set to 5, you can't reset it to 5 again!But if you write 6 to it, it will reset to 4, allowing you to write 6 again and trigger a jump.To explain it further, in the reversing process you would try many different values:Notice the pattern? Setting the 0 bit or the 1st bit makes you jump, but setting the other bits does not. The trouble is depending what value you write, it doesn't always reset the value back to decimal 4 or 0100 in binary.In these cases the game doesn't properly detect you're "not jumping" and doesn't allow you to jump again. Why? Continue readingBasically jumping is assigned a time, when the time is up and you're on the ground, m_bJumping is set to false. But this doesn't show us how m_bJumping is set to true...Ok so m_nButtons is a bitfield and it's doing a bitwise AND with IN_JUMP to check the IN_JUMP bitflag. If it's set, it calls the Jump() function.dwForceJump isn't a random variable that randomly makes you jump when you write 6 to it and it's sole purpose is not jumping. The m_nButtons bitfield is set by what buttons you're pressing then the game logic checks this bitfield to decide what logic and animations to execute.This means to make the game detect the input which triggers the jump function, you want to set the second bit. So therefore any 4 byte integer that's written to dwForceJump that has the second bit set will make you jump.These integers all have the second bit set:2,3,6,7,10If you write any of those to dwForceJump it makes you jump.Not that 4 is a special number, but because 4 = 0000 0100 in binary and that is the "default on ground" settings.But guess what? Setting the 1st bit also makes you jump. So now I'm not so sure.It's definitely a bitfield because if you view the assembly instructions that test/cmp the address, it uses bitwise operators checking the first bit and doing a bitwise OR on the 1st and 2nd bit.I was pretty sure is was the m_nbuttons bitfield but it's not, because when you do any other button presses for movement, it doesn't change...No, but m_nButtons gets it's value from dwForceJump. So we need to trace backwards from m_nButtons to dwForceJump.