PAS Updates
gottfriedleibniz opened this issue · 3 comments
Looked through this native repository for commands not caught by PAS
. Ordered by usefulness.
// Return Types
// build,hash,cfx_result,nativedb_result,name
323,0x40F7E66472DF3E5C,Any,char*,UGC_GET_CACHED_DESCRIPTION // (!)
323,0xBF09786A7FCAB582,Any,char*,UGC_GET_CONTENT_NAME
323,0x703F12425ECA8BF5,Any,char*,UGC_GET_CONTENT_USER_NAME
323,0xC55A0B40FFB1ED23,Any,char*,UGC_GET_CREATE_CONTENT_ID
323,0x24409FC4C55CB22D,Any,char*,NETWORK_GET_PRESENCE_INVITE_CONTENT_ID
// Parameters
// build,hash,cfx_type,nativedb_type,name
323,0x1162EA8AE9D24EEA,float,float*,OVERRIDE_SAVE_HOUSE
323,0x1162EA8AE9D24EEA,float,Vector3*,OVERRIDE_SAVE_HOUSE
573,0x6BC0ACD0673ACEBE,Any,int*,N_0x6BC0ACD0673ACEBE // x2
1290,0x8A4416C0DB05FA66,Any,Any*,N_0x8A4416C0DB05FA66 // (!)
1103,0xDAB963831DBFD3F4,int,int*,_IS_ANY_AIR_DEFENSE_ZONE_INSIDE_SPHERE
463,0x83660B734994124D,Any,int*,N_0x83660B734994124D
463,0x2DA41ED6E1FCD7A5,Any,int*,N_0x2DA41ED6E1FCD7A5
463,0xC434133D9BA52777,Any,int*,N_0xC434133D9BA52777
463,0x1A8EA222F9C67DBB,Any,float*,N_0x1A8EA222F9C67DBB
463,0xF11F01D98113536A,Any,float*,N_0xF11F01D98113536A
505,0x2E4C123D1C8A710E,Any,int*,N_0x2E4C123D1C8A710E // x2
1290,0xE42D626EEC94E5D9,Any,int*,N_0xE42D626EEC94E5D9 // x3
463,0xB09D25E77C33EB3F,int,int*,IS_PED_EXCLUSIVE_DRIVER_OF_VEHICLE
323,0xA4822F1CF23F4810,Any,Vector3*,GENERATE_VEHICLE_CREATION_POS_FROM_PATHS
2545,0x340A36A700E99699,,int*,N_0x340A36A700E99699
2545,0x40EB1EFD921822BC,,int*,N_0x40EB1EFD921822BC
2545,0x52F734CEBE20DFBA,,int*,N_0x52F734CEBE20DFBA // x2
2612,0xFCE2747EEF1D05FC,,Any*,N_0xFCE2747EEF1D05FC
2802,0x3DA8C28346B62CED,,Vector3*,N_0x3DA8C28346B62CED
2944,0x809549AFC7AEC597,,float*,N_0x809549AFC7AEC597
2944,0x809549AFC7AEC597,,Vector3*,N_0x809549AFC7AEC597
There are some other incorrectly documented natives that may trigger a false positive (unlikely). Other undocumented natives are presumed to be in-pointers.
Few other comments:
0x40F7E66472DF3E5C
and0x8A4416C0DB05FA66
expose the content buffer (ASLR).- It would be nice if
GET_ENTITY_ADDRESS
could be no-op'd on release builds (PAS may not sanitize those addresses).
I'll push a quick manual set of those that are included in the current data set to this repo, though I'm unsure when this can get taken up in a normal build given some of the turmoil as of late.
The 2545+ natives are a bit concerning as they're not in here either and some are definitely problematic, and ideally we'd run a full regeneration pass of pointer types against the well-known .sch
files too.
Having the main executable not be RWX would help a lot, but GuardIT didn't like that. I think the ASLR bits should be resolved mostly once stuff is marked as char*
but I forgot if this was taken up during the previous mitigation rounds.
I should also add, some hardening (i.e., filling in scrBind*SafePointer?) should probably be added to a few of the scrBindClass
natives. There were a few other things I had noted, but I can't recall off the top of my head.
scrBind was designed to have a safe pointer check at some point though I don't think that got implemented, indeed- especially as more vtable-y things show up this probably should get covered though yeah.