Quantcast

Jump to content

» «
Photo

DOES_OBJECT_EXIST, DOES_CHAR_EXIST, DOES_VEHICLE_EXIST may crash the g

1 reply to this topic
fastman92
  • fastman92

    фастман92 | ف

  • Members
  • Joined: 28 Jul 2009
  • None
  • Contribution Award [Mods]

#1

Posted 22 October 2013 - 05:33 PM Edited by fastman92, 22 October 2013 - 07:55 PM.

I thought it would be good to let the scripters know that:
Commands
DOES_OBJECT_EXIST (0x03CA)
DOES_CHAR_EXIST (0x056D)
DOES_VEHICLE_EXIST (0x056E)
these commands may crash the game if random number is used for handle.

Example:
{$CLEO}
// Requires CLEO4
0@ = 574177280

:test
wait 0
if
0AB0:   key_pressed 72   // press H key
else_jump @test
056E:   car 0@ defined   // It will crash

0AD1: show_formatted_text_highpriority "Works" time 2000 
jump @test
This is because of how CPool::GetObjectByHandle(int handle) is implemented:
	// Returns pointer to object by SCM handle
	T* GetObjectByHandle(int handle)
	{
		int idx = handle / 256;

		return *(BYTE*)&this -> m_ByteMap[idx] == *(BYTE*)&handle ? &this -> m_Objects[idx] : NULL;
	}
Please notice reference to this -> m_ByteMap[idx].
The following function doesn't check if int idx
lies in bounds of this -> m_ByteMap - whether idx value is lower than value of CPool::m_Size - max number of objects that could be allocated.

In case of exceptionally high number for handle and without the check done a function will try to access bytes that don't belong to this -> m_ByteMap and will generate 0xc0000005 memory access violation error.

Conclusion: argument passed to the above commands should be a possibly valid object handle - handle of object that may have previously existed, but object may not exist anymore.
  • Silent likes this

Midnightz
  • Midnightz

    Populus vult decipi.

  • Members
  • Joined: 05 Feb 2007
  • United-States

#2

Posted 14 November 2013 - 06:05 AM

Thank you. :)




1 user(s) are reading this topic

0 members, 1 guests, 0 anonymous users