Jump to content

protecao script


Recommended Posts

 

11 minutes ago, #DeltaSCR said:

@Jonas^ Achei interessante essa proteção... Pode me explicar mais como ela funciona?

Bom pra ser sincero eu tentei utilizar esse modo e não consegui, mas acho que a melhor maneira é usar um element-data e verificar se ele é true or false por meio de um export, resumindo:

Você vai ter um resource principal que ira verificar todos os outros resouces, no caso você vai exportar a função do resource principal nos outros resouces pra verificar se ele esta sendo executado no ip cadastrado ou não.

EDIT: Pedi pro meu professor @DNL291 te explicar melhor como funciona uehuheuea

Edited by Jonas^
  • Like 1
Link to comment
Just now, Jonas^ said:

 

Bom pra ser sincero eu tentei utilizar esse modo e não consegui, mas sei que a melhor maneira é usar um element-data e verificar se ele é true or false por meio de um export, resumindo:

Você vai ter um resource principal que ira verificar todos os outros resouces, no caso você vai exportar a função do resource principal nos outros resouces pra verificar se ele esta sendo executado no ip cadastrado ou não.

Interessante, vou tentar utilizá-lo depois...

Link to comment
14 minutes ago, #DeltaSCR said:

@Jonas^ Achei interessante essa proteção... Pode me explicar mais como ela funciona?

A função fetchRemote ali vai obter o IP do servidor, daí no caso se você quiser verificar se o IP é o mesmo que um IP especificado faz uma verificação if SERVER_IP == seu_IP then.

Edit: com algumas modificações extras é possível fazer uma proteção no resource, cancelando o evento onResourceStart

Edited by DNL291
  • Thanks 1
Link to comment
  • Other Languages Moderators

Meu sistema de proteção por IP também é por meio desse fetchRemote. Ele é feito por um único resource específico e dai os resources que possuem bloqueio verificam o IP através de um export desse resource. Se houver qualquer problema (o resource não existir, ou não conseguir retornar o IP por falta de permissão), o resource cancela sua própria ativação.

E também é claro, tudo deve estar compilado.

  • Thanks 1
Link to comment
1 hour ago, Lord Henry said:

Meu sistema de proteção por IP também é por meio desse fetchRemote. Ele é feito por um único resource específico e dai os resources que possuem bloqueio verificam o IP através de um export desse resource. Se houver qualquer problema (o resource não existir, ou não conseguir retornar o IP por falta de permissão), o resource cancela sua própria ativação.

E também é claro, tudo deve estar compilado.

É uma proteção boa, mas nunca é bom confiar cegamente nesses sistemas. Se alguém conseguir o código mesmo que ele esteja compilado, pode conseguir executar o código protegido. No caso do onResourceStart + cancelEvent por exemplo, dá pra burlar isso.

Edited by DNL291
Link to comment
  • Other Languages Moderators

@DNL291 a única maneira de burlar meu sistema é o cara conseguir descompilar o resource da proteção por IP e o resource bloqueado, para conseguir ter acesso as senhas de desbloqueio que são passadas de maneira criptografada através do export. Se o cara conseguir ser hacker o suficiente para descriptografar os resources, dai realmente não há o que fazer.

Também não adianta o cara tentar dar output nos valores retornados pelo export, pois como eu disse, as senhas são passadas criptografadas. O cara pode ser esperto e tentar criar um resource falso que sempre retorna um IP válido, mas mesmo assim vai faltar as senhas de cada resource.

  • Thanks 1
Link to comment

Por questões de overwrite como já mencionado, você não tem garantia que o resource não será ativado (nos casos que não possua permissão). Uma proteção adicional é manter todo o seu código no escopo da validação:

-- código inseguro
addEventHandler("onResourceStart",resourceRoot,
	function()
		local ip,senha = exports.validar:autenticar()
		if (ip == "127.0.0.1" and descriptografar(senha) == "aljkdkhje") then
			-- código "seguro"
		else return cancelEvent()
		end
	end
)

Dependendo de como foi feito e sabendo mais/menos o funcionamento do sistema de segurança, dá pra bolar algo utilizando algumas funções do debug para tentar espiar funções/variáveis e talvez até obter a chave da descriptografia.

Enfim, nada é totalmente seguro... compilando e colocando em uma host confiável já dá pro gasto pra grande maioria, em casos mais extraordinários (scripts fodas) é que vale tal esforço.

Link to comment
  • Other Languages Moderators

Como assim overwrite? A questão da falta de permissão vc se refere a quais permissões?

E como o cara vai dar debug nas variáveis do meu script se ele é criptografado? Quer dizer, ele precisa saber os nomes das variáveis pra poder chamá-las, certo?

Edited by Lord Henry
  • Thanks 1
Link to comment

overwrite acho que ele quis dizer questões de cancelar o inicio de algum script de proteção compilado, mas logicamente se não tiver uma noção de como é mais ou menos feito o código acredito que seja praticamente impossível burlar isso.

Edited by Jonas^
Link to comment
2 hours ago, Lord Henry said:

Como assim overwrite?

overwrite = sobrescrever… no nosso caso, funções.

Você usa onResourceStart e cancelEvent() na proteção né ? É possível que alguém sobrescrever o addEventHandler e não faça nada quando for onResourceStart, ou seja, não vai rodar a função do evento, sendo assim, ele vai “pular” sua verificação+cancelEvent():

_addEventHandler = addEventHandler
function addEventHandler(eventName, attachedTo, handlerFunction, getPropagated, priority)
	if (eventName ~= "onResourceStart") then
		getPropagated = getPropagated or true
		priority = priority or "normal"
		_addEventHandler(eventName, attachedTo, handlerFunction, getPropagated, priority)
	end
end
2 hours ago, Lord Henry said:

A questão da falta de permissão vc se refere a quais permissões?

Falta de permissão = alguém conseguiu ilegalmente seus resources e esta tentando ativar. A proteção sua então vai considerar que ele não tem permissão e então cancelar o ativamento do resource... Realmente ficou confuso essa questão de permissão, mas se trata de terceiros tentando utilizar seus resources.

2 hours ago, Lord Henry said:

E como o cara vai dar debug nas variáveis do meu script se ele é criptografado? Quer dizer, ele precisa saber os nomes das variáveis pra poder chamá-las, certo?

O script pode estar compilado, porém no mesmo resource eu posso adicionar um script malicioso que de certa forma conseguiria “monitorar” a execução do compilado, visto que estariam em um mesmo “ambiente”.

Dá para ver o nome das variáveis com:
debug.getlocal / debug.getupvalue / _G

Obs: Estou trazendo questões teóricas, nunca utilizei na prática, ou seja ->  Certeza que vai funcionar ? R: Não. (mas deveria!)

  • Like 1
Link to comment

@Lord Henry Não é necessário descompilar pra conseguir executar o código, e o MaligNos já explicou o porquê. Faça um teste você mesmo.

Aqui um exemplo:

function enterVehicle ( player, seat, jacked )
	cancelEvent( true )
	outputChatBox ( "Veiculos bloqueados!", player )
end
addEventHandler ( "onVehicleStartEnter", getRootElement(), enterVehicle )

Ok, esse código vai impossibilitar o jogador de entrar em qualquer veículo.

Agora, eu crio outro script separado, exatamente assim:

_cancelEvent = cancelEvent
function cancelEvent()
	return _cancelEvent(false)
end

Resultado, a função cancelEvent lá dentro do outro código será sempre chamada dessa forma: cancelEvent(false) mesmo que outro valor seja passado.

Agora, impedindo essa "interferência externa":


local _cancelEvent = cancelEvent
local function cancelEvent( ... )
	return _cancelEvent( ... )
end

function enterVehicle ( player, seat, jacked )
	cancelEvent( true )
	outputChatBox ( "Veiculos bloqueados!", player )
end
addEventHandler ( "onVehicleStartEnter", getRootElement(), enterVehicle )

Aquele wrapper (assim que também é conhecido) no outro script não vai mais mudar nada nesse que o cancelEvent está local.
Edit Esse código acima na verdade não vai impedir nada pois a esse ponto já irá receber a função reescrita.

--

Até mesmo a variável que armazena a chave de proteção está vulnerável - isso porque existe a biblioteca Lua debug (além de _G), já mencionados. E essas funções estão habilitadas no MTA.

Meio fora do assunto, mas há alguns anos atrás, um membro do fórum tinha conseguido obter a chave de encriptação utilizada internamente no MTA (procurei esse post, mas perece que já foi removido).

  • Like 1
Link to comment
  • Other Languages Moderators

Hum... Os caras cancelam a função que cancela, lol '-'

10 hours ago, DNL291 said:

Até mesmo a variável que armazena a chave de proteção está vulnerável - isso porque existe a biblioteca Lua debug (além de _G), já mencionados. E essas funções estão habilitadas no MTA.

E existe alguma forma de cancelar a utilização delas? Da mesma forma que fizeram pra cancelar a função cancelEvent?

Edit: Na real não se trata de cancelar as funções e sim torná-las inutilizáveis.

Edited by Lord Henry
  • Thanks 1
Link to comment
10 hours ago, DNL291 said:

Agora, impedindo essa "interferência externa":


local _cancelEvent = cancelEvent
local function cancelEvent( ... )
	return _cancelEvent( ... )
end

function enterVehicle ( player, seat, jacked )
	cancelEvent( true )
	outputChatBox ( "Veiculos bloqueados!", player )
end
addEventHandler ( "onVehicleStartEnter", getRootElement(), enterVehicle )

Aquele wrapper (assim que também é conhecido) no outro script não vai mais mudar nada nesse que o cancelEvent está local.

Interessante! Confesso que estava tentando pensar em algo do tipo... mas no final das contas não daria no mesmo https://i.imgur.com/x0FE5Xq.png ?

 

Link to comment
13 minutes ago, Lord Henry said:

E existe alguma forma de cancelar a utilização delas? Da mesma forma que fizeram pra cancelar a função cancelEvent?

Edit: Na real não se trata de cancelar as funções e sim torná-las inutilizáveis.

Imagino eu, que um debug = nil funcione.

Mas se o cara salvar em outra variável antes de você definir nil, acredito que conseguirá utilizar do mesmo modo kkk

teste = debug
debug = nil
print(teste) -- lib ok

 

Link to comment
  • Other Languages Moderators
10 hours ago, DNL291 said:

a variável que armazena a chave de proteção está vulnerável

Mesmo se ela for local? Pois teoricamente não daria pra lê-la fora de seu escopo, em outro script.

Edited by Lord Henry
Esqueça aquela ideia anterior, é fácil burlar.
Link to comment
19 minutes ago, Lord Henry said:

Esqueça aquela ideia anterior, é fácil burlar.

O principal mesmo é buscar manter sigilo total de como foi feito o sistema de proteção, ninguém burla nada sem antes saber como funciona. Você analisando o código, "facilmente" vê um jeito de burla-lo, agora um script criptografado, teria que ralar muito para descobrir um jeito.

Link to comment
  • Other Languages Moderators

A ideia que eu apaguei, era de verificar o número de caracteres no meta.xml. Se for diferente do número de caracteres que o desenvolvedor deixou programado, impede a ativação do resource pois detecta que "houve alteração no meta". Mas é fácil burlar, só o cara substituir os nomes e depois fazer as alterações de modo que fique com exatamente o mesmo número de caracteres, incluindo a modificação. Dai burlaria o sistema de novo.

Edited by Lord Henry
Esqueci de 1 vírgula.
Link to comment
2 hours ago, Lord Henry said:

Mesmo se ela for local? Pois teoricamente não daria pra lê-la fora de seu escopo, em outro script.

Realmente quando trabalha com funções/variáveis locais, complica 100%, teria que usar setfenv (função desabilitada no MTA por questões de segurança). Mas tem que ser ambos locais, pois se uma função global utilizar uma variável local, daria para pegar com getupvalue.

-- script A
local teste = "oie"
function testeFunc()
  if (teste) then end
end

-- script B
local i = 1
while true do
  local nome, val = debug.getupvalue(testeFunc, i)
  if not nome then break end
  print(nome, val) -- teste  oie
  i = i + 1
end

 

Link to comment
3 hours ago, MaligNos said:

Interessante! Confesso que estava tentando pensar em algo do tipo... mas no final das contas não daria no mesmo https://i.imgur.com/x0FE5Xq.png ?

 

Não sei se entendi bem, mas no memento em que eu crio aquela função local, isso vai tornar impossível modifica-lá por outro script sobrescrevendo, ela estará no mesmo escopo, no caso, no próprio script, será como uma função cancelEvent que não tem relação com das outras.

3 hours ago, Lord Henry said:

Mesmo se ela for local? Pois teoricamente não daria pra lê-la fora de seu escopo, em outro script.

Também dá, estando local ela só vai estar disponível no mesmo código mas ainda dá pra obtê-la com uma função Lua.

4 hours ago, Lord Henry said:

E existe alguma forma de cancelar a utilização delas? Da mesma forma que fizeram pra cancelar a função cancelEvent?

Proteger desses métodos que mostramos aqui sim, nunca fiz algo do tipo mas você pode tentar fazendo uma versão que abrange todas funções do código e que tornam elas inacessíveis por funções sobrescritas (anulando variável/função na tabela Lua _G por exemplo), Ou utilizar loadstring + pcall para executar o trecho do código a ser protegido.

Você também pode tentar fazer o código em seu próprio "ambiente", será mais fácil se você já tem uma noção de metatables + setfenv e outras demais funções.

Obs: Também tem esta função do MTA que também pode vazar informações do código: https://wiki.multitheftauto.com/wiki/AddDebugHook (eu nunca testei então não sei dizer o quanto ela é eficaz).

 

Edit

3 hours ago, MaligNos said:

Imagino eu, que um debug = nil funcione.

Mas se o cara salvar em outra variável antes de você definir nil, acredito que conseguirá utilizar do mesmo modo kkk


teste = debug
debug = nil
print(teste) -- lib ok

 

Será que ainda dá pra acessar debug pela tabela Lua _G? Aí está algo a se testar...

Edit²

1 hour ago, MaligNos said:

teria que usar setfenv (função desabilitada no MTA por questões de segurança)

Na verdade essa função pode ser utilizada no MTA (isso até onde eu sei).

--

Desculpem o excesso de quotes 9_9

Edited by DNL291
  • Haha 1
Link to comment

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now
  • Recently Browsing   0 members

    • No registered users viewing this page.
×
×
  • Create New...