One main reason you should remove of mellotrainer from your server

Agreed, its not just localised to mellotrainer specifically, im sure there are dozens of resources which could have issues like this, however so far im sure this is the most dangerous of them, seeing as you can kick and even BAN people.

Uuuum are you the the people joining random servers and kicking people just to prove your point? I saw IllusiveTea with IceHax joining random servers exploiting this.

If a user can exploit a trainer isn’t that a sign that you should remove it? Clearly the trainer has flaws (as mentioned in the OP) that can be used to affect a server negatively and cause a great impact.

1 Like

Can we have a similar post for Windows 7 vulnerabilities. Maybe we can convince people to use Windows 10 :laughing:

Serious note: I wasn’t aware of this and changed to vMenu for other reasons. Good to hear about this and to put it out in the public.

3 Likes

What exactly is so called mellotrainer


image
(Joke, Jesse Cris)

vMenu would be the superiour menu to use. MelloTrainer has been discontinued by the developer and is per definition not safe for usage on public servers (since it does not use the builtin ACL).

3 Likes

Great example of why you should not be trusting the client! Always perform server-side checks that validate client activities.

1 Like

Lamaba is pretty good.

If you are on about scripthook stuff then just no. This is directed more specifically at basically being able to use a “server-side trainer” and bypassing any sort of restrictions the owners/copycats (same thing) put in place on it.

yea i did find out, that why i made my own admin menu :slight_smile:

Clever boy :smile:

Going to make a list of resources i have found with this type of issue:

  • mellotrainer - fuck me theres a lot to be said about this one - 280 servers!
  • vrp_lottery - specifically, not checking if the value is negative or not
  • esx_spectate - allowing users to spectate and even kick - 304 servers!

esx_spectate is not bugged, is coded so you can see it even if you are a user but you can change it in client\main.lua .
Go to line 230 and change the function from there with this one

Citizen.CreateThread(function()
	while true do
		Wait(0)
		
		if IsControlJustReleased(1, 163) then
			print('triggered')
			if group == "superadmin" then
				TriggerEvent('esx_spectate:spectate')
			end
		end
	end
end)

That code is irrelevant here, the server side lacks the check of permissions, and using the cef debug page you can send a post request to trigger the kick without any sort of checks. After all, never trust the client. You don’t need to see the menu to trigger the event which kicks

it works just fine for me

Dude, its not about it “working”. Theres an exploit in it on the server-side in terms of permission checks, it just believes anyone who triggers the event is an admin, which they may not even be as you can trigger it without using the menu which needs admin.

See this line:

no permission checks whatsoever, which is a MASSIVE flaw, considering you dont even need any sort of exploit to do so, as the event is exposed in the CEF debugger.

oh yeah i forgot, the event is not named esx_spectate:kick , i changed the name too :smiley:
so try to run esx_spectate:kick event

That doesnt matter, they can see the NUI section and do the post request through $.post or so. Meaning changing event names changes nothing.

yeah good luck finding wich is wich when i changed it with numbers, and only i have the list , i know they can run other scripts to read the events names and all that shit, got that covered allready. scrambled most of the important events

Thats not what i mean at all. Im talking about CEF here, you can see the js code which you need in order to trigger the event. Your point here is completely irrelevant. I can come and show you if you really dont believe me and want to see so.

You dont need an exploit at all. All you need is Google Chrome and head over to localhost:13172 while your game is loaded