Segurança do .exe AHK

Tire suas dúvidas sobre programação em AutoHotkey

Moderator: Gio

User avatar
manehscripts
Posts: 102
Joined: 03 May 2019, 16:10

Segurança do .exe AHK

29 May 2019, 19:45

Fazem alguns dias que descobri o AHK e estou super interessado em aprender mais e mais. O engraçado é que até então, eu não sabia da existência do sub-fórum em português, embora a participação em outros idiomas não seja o meu problema. Talvez aqui fique mais fácil de compreender as dicas pois eu acredito que tenham muitos brasileiros/portugueses que entendem (e muito) do assunto em geral.

Bom, chega de lero-lero. Eu criei um tópico sobre a Segurança AHK em inglês na parte Ask For Help, onde um membro me sugeriu postar no sub-tópico da mesma versão que eu utilizo (AHK_H) para talvez sanar melhor o meu problema (e a propósito foi nesse momento que eu descobri da existência da sessão em português).

Eu observei também que o amigo @Gio esteve lá me ajudando (e ele é brasileiro pelo o que me parece :D ).
O objetivo dessa postagem é tentar descobrir a melhor forma de proteger o nosso arquivo .exe criado com base no código desenvolvido com o AHK. Eu estou desenvolvendo um projeto de estudo, para posteriormente se tornar um projeto real talvez (tudo depende apenas da questão de proteção), pois o meu programa vai trabalhar com acesso a um Banco de Dados e se não houver essa proteção, de nada vai adiantar pois um acesso malicioso aos dados tornaria tudo perdido.

Atualmente estou usando o Obfuscator para criptografar meu código, ele ajuda mas eu não sei se é 100% seguro. Também não encontrei nada falando sobre uma eng. reversa para decodificar o código gerado pelo Obfuscator, e por enquanto ele tem trazido uma certa segurança.

Eu estou compilando meu .exe com o compiler Ahk2Exe.ahk, carrego ele no AutoHotkey.exe 64bit do ahkdll-v1-release-master. Essa forma de compilação se torna segura? Eu procurei a existência de algum decompilador, mas não encontrei. Pensei também se caso essa forma não fosse a mais segura, levar todo meu código para outro gerador de executável como Visual Studio por exemplo (apenas se assim for mais seguro).

Em suma, essa é a principal dúvida do momento, talvez alguém possa ajudar ou então sanar o mesmo problema que eu estou passando. Isso pode ajudar todos!
Desde já obrigado! :thumbup:
User avatar
Gio
Posts: 684
Joined: 30 Sep 2013, 10:54
Location: Brazil

Re: Segurança do .exe AHK

30 May 2019, 09:45

Bom dia Manehscripts.

Seja bem-vindo ao fórum da comunidade do AutoHotkey :thumbup:

A questão da segurança do código é um tema importante, mas que precisa ser corretamente ponderado pelo desenvolvedor. Eu diria que em mais de 99% das vezes, a segurança básica que o arquivo compilado do AutoHotkey fornece (com o uso do packer mpress) já é muito mais do que suficiente (muito mais mesmo!). Mas se você quer ter ainda mais segurança, preciso entender duas coisas antes de indicar uma solução: a primeira é o que exatamente você está tentando proteger dentro do programa e a segunda é de quem exatamente você esta tentando proteger isso.

PRIMEIRO: O que exatamente você está tentando proteger?
1. Uma string específica dentro do programa que contem uma senha de um serviço?
2. Uma conexão a um banco de dados?
3. O know-how (a lógica) das rotinas do seu programa?
4. Uma rotina de autenticação de licenças?
5. Uma rotina específica que você desenvolveu e que faz um trabalho muito técnico e desconhecido que possa gerar uma grande vantagem comercial? (exemplo: reconhecimento de pássaros em vídeos, etc)?

SEGUNDO: De quem você está tentando proteger isso?
1. De uma pessoa que possa querer acessar as telas do seu programa com uma senha de usuário?
2. De uma pessoa que possa querer acessar o banco de dados do seu programa?
3. De alguém que possa querer burlar uma licença do seu programa para não pagar a mensalidade?
4. De alguém que possa querer burlar uma licença do seu programa para tentar vender aos seus clientes pela metade do preço da mensalidade?
5. De outro desenvolvedor que possa querer roubar a ideia da lógica do seu programa para adaptá-la ao dele?
6. De alguém que possa querer roubar o código-fonte inteiro para se tornar seu concorrente sem ter que desenvolver nada?
7. De outro desenvolvedor que possa querer roubar a rotina muito técnica e desconhecida que você desenvolveu (exemplo: reconhecimento de pássaros em vídeos) para vender ao Google ou outra empresa grande de software?

Preciso que seja absolutamente honesto nas respostas (por exemplo não diga que quer proteger o código inteiro se não for esse o caso, pois a orientação que vou dar vai mudar conforme o caso e posso acabar indicando uma coisa totalmente desnecessária, custosa e trabalhosa para você).
User avatar
manehscripts
Posts: 102
Joined: 03 May 2019, 16:10

Re: Segurança do .exe AHK

30 May 2019, 10:24

Gio wrote:
30 May 2019, 09:45
Bom dia Manehscripts.

Seja bem-vindo ao fórum da comunidade do AutoHotkey :thumbup:

A questão da segurança do código é um tema importante, mas que precisa ser corretamente ponderado pelo desenvolvedor. Eu diria que em mais de 99% das vezes, a segurança básica que o arquivo compilado do AutoHotkey fornece (com o uso do packer mpress) já é muito mais do que suficiente (muito mais mesmo!). Mas se você quer ter ainda mais segurança, preciso entender duas coisas antes de indicar uma solução: a primeira é o que exatamente você está tentando proteger dentro do programa e a segunda é de quem exatamente você esta tentando proteger isso.

PRIMEIRO: O que exatamente você está tentando proteger?
1. Uma string específica dentro do programa que contem uma senha de um serviço?
2. Uma conexão a um banco de dados?
3. O know-how (a lógica) das rotinas do seu programa?
4. Uma rotina de autenticação de licenças?
5. Uma rotina específica que você desenvolveu e que faz um trabalho muito técnico e desconhecido que possa gerar uma grande vantagem comercial? (exemplo: reconhecimento de pássaros em vídeos, etc)?

SEGUNDO: De quem você está tentando proteger isso?
1. De uma pessoa que possa querer acessar as telas do seu programa com uma senha de usuário?
2. De uma pessoa que possa querer acessar o banco de dados do seu programa?
3. De alguém que possa querer burlar uma licença do seu programa para não pagar a mensalidade?
4. De alguém que possa querer burlar uma licença do seu programa para tentar vender aos seus clientes pela metade do preço da mensalidade?
5. De outro desenvolvedor que possa querer roubar a ideia da lógica do seu programa para adaptá-la ao dele?
6. De alguém que possa querer roubar o código-fonte inteiro para se tornar seu concorrente sem ter que desenvolver nada?
7. De outro desenvolvedor que possa querer roubar a rotina muito técnica e desconhecida que você desenvolveu (exemplo: reconhecimento de pássaros em vídeos) para vender ao Google ou outra empresa grande de software?

Preciso que seja absolutamente honesto nas respostas (por exemplo não diga que quer proteger o código inteiro se não for esse o caso, pois a orientação que vou dar vai mudar conforme o caso e posso acabar indicando uma coisa totalmente desnecessária, custosa e trabalhosa para você).
Obrigado novamente pela sua resposta... vamos lá!

Sobre a sua primeira pergunta eu creio que todas a opções se enquadram com a minha necessidade, haja vista que também uma se encaixa com a outra. Eu tenho strings que são informações de acesso ao Banco de Dados, e também tenho rotina de autenticação que são interligadas com o Bando de Dados que podem ser manipuladas se as informações forem vazadas, além de é claro, rotina específica que eu tive o trabalho de desenvolver e provável que seja exclusivo e diferencial para o que temos no mercado.

Na segunda opção é um pouco parecido, se a pessoa tiver o acesso ao Banco de Dados, consequentemente terá as informações de todos os usuários como e-mail, senha, dados pessoais, tempo de aquisição do programa entre outras informações, bem como também poderá burlar a licença do programa acrescentando dias a mais de acesso. Eu criei uma coluna na tabela do Banco de Dados que mostra quando a pessoa está utilizando o programa, caso ela consiga burlar a utilização sem precisa ter mensalidade, eu conseguirei ver que o e-mail TAL está utilizando sem permissão, onde simplesmente posso deletar a conta e retirar a conexão dela com um simples comando. Com certeza as pessoas que mais tentarão acessar as minhas informações serão os concorrentes, por ver a funcionalidade do programa e querer entender a lógica de todo o trabalho que eu fiz para implementar nos deles, ou simplesmente querer atrapalhar o meu trabalho. As 3 última opções praticamente se enquadram com essa minha última resposta.

Eu tentei ser o mais honesto possível baseado nas suas opções, mas o resumo da ópera se baseia no acesso ao Banco de Dados, embora as outras opções também sejam de extrema importância. Porque a partir do momento que a pessoa tiver acesso ao Bando de Dados, tudo estará perdido, menos que eu faça constantes backup's e esteja preparado para ficar alterando a versão do programa com novos dados do Banco de Dados e disponibilizando para o pessoal baixar novamente, gerando então um loop infinito (já que alguém descobriu como conseguir meus dados).

Obrigado!!!
-----------------------------------------------------------
Stop to think, shut up to resist, and act to win!
User avatar
Gio
Posts: 684
Joined: 30 Sep 2013, 10:54
Location: Brazil

Re: Segurança do .exe AHK

30 May 2019, 12:16

Ok. Tá certo, mas olha só, esse é um tópico muito longo, e no final quase sempre a conclusão acaba sendo bem diferente do que se esperava. Mesmo assim vamos lá, vou tratar vários pontos relacionados para que possamos adquirir uma visão mais abrangente do que está envolvido, e daí quem sabe você terá mais embasamento para optar por algum dos métodos descritos.

A primeira coisa que você deve ter em mente é que a segurança da informação tem um custo. Isso significa basicamente que você vai precisar dedicar muitas horas de trabalho implementando novas rotinas com o único propósito de elevar o nível de segurança da informação. Além disso, é possível que a implementação dessas rotinas atrapalhem você também na hora de atualizar o programa ou mesmo na hora de procurar bugs no seu programa. Neste sentido, entenda que a segurança deve ser tratada como em uma analogia com o mundo real, onde o trabalho de gerar segurança é como construir um muro para impedir o acesso a uma propriedade sua.

Quanto mais alto você projetar o muro, em tese mais seguro ele se torna, mas se você ultrapassar uma determinada altura, o custo para aumentar o muro deixa de ser justificado pelo benefício de ter um muro mais alto. Além disso, o muro muito alto pode criar fraquezas estruturais (ou seja, uma rotina de segurança também pode criar espaço para exploits de hackers). Lembre-se sempre que um muro também pode ser demolido ou que o ladrão pode simplesmente cair de paraquedas: a ideia é que uma pessoa realmente motivada e com os recursos e conhecimentos necessários jamais poderá ser totalmente impedida de entrar na sua propriedade (ou de extrair a informação do seu programa). Também não faz sentido gastar 100 mil em um muro para uma propriedade que vale 50 mil certo?

:arrow: Tendo dito tudo isso, vamos falar primeiro sobre o que podemos fazer para proteger o código fonte do script "compilado" inteiro.

Existem duas formas de implementar uma linguagem de programação: através de um compilador e através de um interpretador. O executável do autohotkey é um poderoso interprertador. Isso significa que ele lê os comandos de texto que você escreve no script e então executa os códigos de máquina necessários para que aquelas ações aconteçam. Um exemplo de outra linguagem interpretada é o conhecido Java. A outra forma de implementar uma linguagem de programação é através de um compilador de verdade. Um compilador, ao invés de ler os comandos escritos e executar as instruções, vai ler os comandos escritos e CRIAR NOVAS sequências de instruções em código de máquina que executem esses comandos. Isso significa que o resultado da compilação verdadeira é um código de máquina à parte, e que o código-fonte não estará mais presente neste arquivo final. Um exemplo de linguagem que faz isso é o C++, através do Visual Studio C++.

No caso do AutoHotkey, como os usuários demonstraram a necessidade de criar arquivos executáveis únicos (sem arquivos de texto na mesma pasta), foi criado um pseudo-compilador (ahk2exe), que na verdade simplesmente pega o script e insere dentro do próprio executável do AutoHotkey. Assim, quando você "compila" um script, você simplesmente copia o executável do AutoHotkey e insere dentro dele o script em forma de instruções de texto mesmo. Dessa forma, olhando dentro do arquivo do executável "cru", você poderá normalmente encontrar o script inteirinho com todos os comandos de texto de forma legível. Mas isso não é uma regra: existe uma maneira de transformar até mesmo o arquivo de texto do script em código de máquina, e isso é feito através de um packer (como por exemplo, o mpress, que se estiver presente na pasta do compilador pode ser usado clicando na flag "use mpress if present" dentro da tela do ahk2exe).

O que um packer faz é pegar um arquivo executável e com ele criar um segundo arquivo executável comprimido, e neste arquivo comprimido é inserido um código de máquina no início da cadeia de instruções que vai auto-descomprimir o executável comprimido, carregando para dentro da RAM os códigos de máquina do arquivo original, que serão então executados. A vantagem do uso do packer é que o arquivo final fica com um tamanho menor em disco do que o arquivo original. Para nosso caso, a vantagem é que o script também passa a ficar escondido dentro de código de máquina de auto-descompressão.

Mas então, essa segurança se torna igual a de um compilador verdadeiro? Talvez. Pode ser até maior (mas também pode ser menor). Essa pergunta não tem uma resposta certa, porque os métodos de extração de dados (engenharia reversa) teriam resultados diferentes em cada uma das situações conforme os casos específicos. Alguns arquivos fruto de um compilador podem ser bem fáceis de aplicar engenharia reversa, especialmente para fazer coisas como burlar uma licença (desde que você saiba o que fazer, lógico). Então a compilação verdadeira na verdade não é muito segura também. Além disso, o hacker que quisesse burlar o arquivo do AutoHotkey após o uso do packer teria que fazer o que chamamos de "unpack", que é uma coisa relativamente trabalhosa (mas é possível haver ferramentas que facilitem, por isso cada packer tem a sua dificuldade de fazer um "unpack"). O que você deve tirar deste parágrafo é o seguinte: use um packer. Se você está preocupado que alguém que conheça à fundo tanto o AutoHotkey como também a engenharia reversa possa tentar fazer um hack no seu arquivo (e tem pouquíssimas pessoas assim, principalmente aqui no brasil), não use o mpress (use outro menos conhecido da comunidade). Mas se você achar que isso é muito improvável (e quase 100% das vezes é), pode usar o mpress numa boa. Finalmente, com relação aos packers você deve observar que tem de testar o programa inteiro depois de aplicar o packer, pois é possível que algo inesperado ocorra (ou seja, que o packer não consiga fazer um pack bom no arquivo). Outra coisa que você também deve ter em mente é que packers são usados bastante por desenvolvedores de vírus (em virtude de diminuir o tamanho em disco do arquivo final e dificultar a engenharia reversa). Dessa forma, podem ocorrer mais falso-positivos em anti-vírus com o seu arquivo final.

Outra coisa que você pode fazer é obfuscar o seu código-fonte. A obfuscação é um trabalho que pode ser feito com ferramentas ou de forma manual, e o que ela faz é embaralhar o código fonte do seu arquivo, tornando-o tão difícil de um ser humano ler que fica muito difícil tentar modificar ou extrair alguma coisa, e isso torna inviável o uso desse código fonte para quase qualquer fim que não seja a sua execução sem alterações. A obfuscação em alto nível, eu acredito ser até mesmo muito mais segura do que a compilação do arquivo, pois o código de máquina, apesar de ilegível por um ser humano à princípio, tem um funcionamento de conhecimento geral e muitas ferramentas de análise disponíveis, mas a rotina de obfuscação que o seu programa vai usar pode ser algo que só você saiba o funcionamento, o que vai forçar o candidato a hacker a tentar deduzir o que foi que você escreveu em cada linha a partir de muitos testes diferentes. Outra dica: A obfuscação manual é bem mais trabalhosa, mas a obfuscação com ferramentas disponíveis está mais sujeita a alguém tentar obter informações direto da ferramenta obfuscadora. Você também pode usar as duas se quiser.

:arrow: Agora como você ja sabe o que fazer em relação ao código fonte, vamos à questão da segurança da conexão.

A conexão que o seu programa faz com um banco de dados, através de um aplicativo ou serviço (ou mesmo via protocolo web), também pode ser protegida. Neste caso, se for uma conexão via web, eu acredito que alguma proteção já se torna algo bem mais importante. Imagine que um hacker pode tentar criar um serviço falso para tentar obter a string que o seu programa está enviado na tentativa de conexão e dela obter as credenciais de acesso. Assim, os desenvolvedores de banco de dados normalmente têm hoje ferramentas de autenticação criptografada. Busque investigar quais estão disponíveis e o que você deve fazer para conseguir implementar uma autenticação criptografada no seu mecanismo de banco de dados. Dica: normalmente isto é feito através de chave pública e chave privada, com algum elemento de segurança tipo data de acesso e consumo de seção, ou coisa parecida, de modo que a string de autenticação seja diferente a cada acesso (e assim uma string não possa ser usada para inferir outra). De qualquer forma, você ainda terá o problema de o hacker só precisar de um único acesso para tentar extrair informações, então fique esperto: no gestor do banco de dados você também tem outras opções de ferramentas de segurança, como fazer com que todas as consultas do tipo de acesso elencado ao seu programa usem somente Stored Procedures (código SQL que você criou) e também que quaisquer acessos às tabelas ativem triggers de log ou interrupção de acesso. Outra opção, no caso do acesso via web, é limitar os IPs que podem acessar o servidor.

:arrow: Por fim, vamos falar de segurança de licenças.

Usando engenharia reversa, é relativamente fácil burlar uma segurança de licenças básica offline alterando somente o código de máquina de um arquivo compilado (mesmo a compilação verdadeira). Isso ocorre porque o programa normalmente usa especificamente instruções de comparação e em momentos previsíveis da execução para definir se uma chave é válida. Assim, se você quiser agregar mais segurança à rotina de verificação de licença do seu programa, pode, por exemplo, criar várias rotinas diferentes de comparação da chave para autenticação e em momentos diferentes da execução (para forçar o hacker a ir procurando e alterando uma a uma). O uso do packer também ajuda, uma vez que ele deve ser vencido antes que o código de máquina de comparação esteja visível no debugger. Uma outra coisa que você deve ter em mente é que uma rotina de verificação de licenças nunca é tão segura quanto uma rotina onde parte essencial do serviço do programa seja executada pelo seu próprio servidor. Se este último caso for possível, o hacker teria que basicamente acessar seu servidor para fazer uso efetivo daquele programa, e se isso não fosse o bastante, você ainda pode limitar quais IPs podem acessar os serviços do seu servidor (mesmo com as credenciais de autenticação corretas, um IP fora da whitelist vai ter seu acesso negado), e se for um IP da própria whitelist, você também pode logar esse acesso para fins de prova.

:arrow: Pronto! acho que agora consegui dar um breve resumo sobre algumas das opções que você tem para elevar o nível de segurança dos seus programas. Mas sendo bem sincero, e é preciso que você pondere bem sobre isso, em 99% das vezes uma grande parte disso não vale nem a pena se dar ao trabalho de fazer. Quando a gente inicia na programação, a gente tem essa ideia de que aquilo que estamos fazendo vale muito dinheiro por si só ou então que interessaria muito às pessoas hackearem os nossos programas, mas a grande verdade é que isso é quase sempre coisa da nossa imaginação.

Quase qualquer programa que você desenvolva é relativamente fácil de entender a lógica só de olhar as telas e quase qualquer programador de nível comercial vai saber implementar aquilo de outra forma (e em outra linguagem) no programa dele (o que se for feito dessa forma muitas vezes sequer é um infração de direito autoral). Além disso, praticamente ninguém vai se dar ao trabalho de hackear um programa para se ver livre de pagar uma licença em massa (que normalmente é menos de 50 reais) ou então de uma licença mensal (que normalmente está atrelada a serviços como suporte e atualização). Se isso não fosse o bastante, invadir um banco de dados é um crime (Lei 12.737), gerando responsabilização penal do indivíduo, e ainda a alteração indevida de uma obra de direito autoral (seu programa) gera possibilidades de ressarcimento para o detentor do direito autoral do programa (você), além de que você pode impor ainda uma cláusula penal pesada aos seus clientes em caso de tentativa de hacking por parte deles (ou seja, uma indenização que eles teriam que pagar para você). Por fim, se você desenvolver uma solução técnica muito específica, pode também ser o caso de patenteá-la (um software não é passível de ser patenteado, ele já é defendido por direito autoral, mas a solução técnica que se opera por meio dele pode sim ser patenteada dependendo do caso).

Procure sempre ponderar que tipos de ferramentas de segurança são efetivamente importantes em cada caso e quando tiver optado por alguma ação específica, sinta-se livre para tirar suas dúvidas sobre como implementá-la (mas por favor, vamos tratar de apenas uma implementação de cada vez).

Espero ter ajudado :beer:
User avatar
juanmuscaria
Posts: 65
Joined: 29 Oct 2017, 10:53
GitHub: juanmuscaria
Location: Brazil
Contact:

Re: Segurança do .exe AHK

30 May 2019, 12:57

Por experiência própria recomendo fazer um servidor para processar informações delicadas, já que mesmo ofuscando, comprimindo, e deixando o script quase impossível de ler se alguém quer modificar ele e tiver muio tempo e conhecimento ela vai conseguir fazer isso.
Mas não precisa se preocupar tanto assim com segurança, é pouca gente que faz esse tipo de coisa, e normalmente cobram bem caro por isso, mas se você estiver em um ambiente que tem certeza absoluta que alguém vai tentar modificar ou roubar informações recomendo fortemente fazer o sistema que processa informações delicadas separado do produto do usuário final, um grande exemplo do por que se deve fazer isso são jogos, esses jogos onde a maior parte dos cálculos e verificações são feitas do lado do cliente sempre vai estar cheio de hackers, mas esses onde é o servidor que processa tudo raramente você vê um hacker.
User avatar
manehscripts
Posts: 102
Joined: 03 May 2019, 16:10

Re: Segurança do .exe AHK

30 May 2019, 13:00

@Gio , eu tenho certeza que essa sua AULA vai servir para tantos outros camaradas que precisaram de ajuda como eu! :bravo:
Agradeço de verdade a disposição em querer ajudar e estou muito satisfeito com tudo que aprendi.
Eu não sei nem o que dizer, visto que tudo que você falou é exatamente o que eu precisava saber, basta agora eu começar a colocar em prática algumas coisas que ainda não fiz.

Parabéns pelo seu know-how! :clap:
Obrigado! :thumbup:
-----------------------------------------------------------
Stop to think, shut up to resist, and act to win!
User avatar
manehscripts
Posts: 102
Joined: 03 May 2019, 16:10

Re: Segurança do .exe AHK

30 May 2019, 13:07

juanmuscaria wrote:
30 May 2019, 12:57
Por experiência própria recomendo fazer um servidor para processar informações delicadas, já que mesmo ofuscando, comprimindo, e deixando o script quase impossível de ler se alguém quer modificar ele e tiver muio tempo e conhecimento ela vai conseguir fazer isso.
Mas não precisa se preocupar tanto assim com segurança, é pouca gente que faz esse tipo de coisa, e normalmente cobram bem caro por isso, mas se você estiver em um ambiente que tem certeza absoluta que alguém vai tentar modificar ou roubar informações recomendo fortemente fazer o sistema que processa informações delicadas separado do produto do usuário final, um grande exemplo do por que se deve fazer isso são jogos, esses jogos onde a maior parte dos cálculos e verificações são feitas do lado do cliente sempre vai estar cheio de hackers, mas esses onde é o servidor que processa tudo raramente você vê um hacker.
Olá! A um mês atrás (a propósito), eu estava conversando com um amigo programador, e ele me sugeriu fazer exatamente isso que você me falou (eu só preciso me aprofundar mais em COMO FAZER). Os usuários do meu programa terão uma ponte de ligação direto com o DB, e isso facilitaria um acesso. Na sua sugestão (só para confirmar se é exatamente isso), a conexão de acesso do usuário ao DB teria um desvio de conexão como API, talvez?
E aproveitando que você tocou nesse assunto, o programa que estou desenvolvendo tem a ver com jogo. Por isso e entender que é aonde mais se infiltra hackers, eu estou dando uma atenção especial na questão de segurança.
-----------------------------------------------------------
Stop to think, shut up to resist, and act to win!
User avatar
juanmuscaria
Posts: 65
Joined: 29 Oct 2017, 10:53
GitHub: juanmuscaria
Location: Brazil
Contact:

Re: Segurança do .exe AHK

30 May 2019, 13:47

manehscripts wrote:
30 May 2019, 13:07
juanmuscaria wrote:
30 May 2019, 12:57
Por experiência própria recomendo fazer um servidor para processar informações delicadas, já que mesmo ofuscando, comprimindo, e deixando o script quase impossível de ler se alguém quer modificar ele e tiver muio tempo e conhecimento ela vai conseguir fazer isso.
Mas não precisa se preocupar tanto assim com segurança, é pouca gente que faz esse tipo de coisa, e normalmente cobram bem caro por isso, mas se você estiver em um ambiente que tem certeza absoluta que alguém vai tentar modificar ou roubar informações recomendo fortemente fazer o sistema que processa informações delicadas separado do produto do usuário final, um grande exemplo do por que se deve fazer isso são jogos, esses jogos onde a maior parte dos cálculos e verificações são feitas do lado do cliente sempre vai estar cheio de hackers, mas esses onde é o servidor que processa tudo raramente você vê um hacker.
Olá! A um mês atrás (a propósito), eu estava conversando com um amigo programador, e ele me sugeriu fazer exatamente isso que você me falou (eu só preciso me aprofundar mais em COMO FAZER). Os usuários do meu programa terão uma ponte de ligação direto com o DB, e isso facilitaria um acesso. Na sua sugestão (só para confirmar se é exatamente isso), a conexão de acesso do usuário ao DB teria um desvio de conexão como API, talvez?
E aproveitando que você tocou nesse assunto, o programa que estou desenvolvendo tem a ver com jogo. Por isso e entender que é aonde mais se infiltra hackers, eu estou dando uma atenção especial na questão de segurança.
Sim teria que ser com uma API, tem como fazer com ahk mas muita gente usa java script.
Sobre a parte de hacker, eles se aproveitam de falhas, tipo, o programa muda uma coisa X no servidor sem o servidor verificar, ai ele pode abusar dessa falha para fazer outras coisas, como por exemplo em um servidor que eu tenho, tinha um sistema de hats que permitia o jogador enviar arquivos zip para ele com a skin própria dele, mas o servidor não verificava o zio, com um client modificado ele poderia enviar uma zip bomb e crashar o servidor ou envia um zip com path traversal e sobrescrever arquivos importantes do servidor, sempre valide o que o usuário manda para seu servidor.
User avatar
manehscripts
Posts: 102
Joined: 03 May 2019, 16:10

Re: Segurança do .exe AHK

30 May 2019, 15:47

juanmuscaria wrote:
30 May 2019, 13:47
manehscripts wrote:
30 May 2019, 13:07
juanmuscaria wrote:
30 May 2019, 12:57
Por experiência própria recomendo fazer um servidor para processar informações delicadas, já que mesmo ofuscando, comprimindo, e deixando o script quase impossível de ler se alguém quer modificar ele e tiver muio tempo e conhecimento ela vai conseguir fazer isso.
Mas não precisa se preocupar tanto assim com segurança, é pouca gente que faz esse tipo de coisa, e normalmente cobram bem caro por isso, mas se você estiver em um ambiente que tem certeza absoluta que alguém vai tentar modificar ou roubar informações recomendo fortemente fazer o sistema que processa informações delicadas separado do produto do usuário final, um grande exemplo do por que se deve fazer isso são jogos, esses jogos onde a maior parte dos cálculos e verificações são feitas do lado do cliente sempre vai estar cheio de hackers, mas esses onde é o servidor que processa tudo raramente você vê um hacker.
Olá! A um mês atrás (a propósito), eu estava conversando com um amigo programador, e ele me sugeriu fazer exatamente isso que você me falou (eu só preciso me aprofundar mais em COMO FAZER). Os usuários do meu programa terão uma ponte de ligação direto com o DB, e isso facilitaria um acesso. Na sua sugestão (só para confirmar se é exatamente isso), a conexão de acesso do usuário ao DB teria um desvio de conexão como API, talvez?
E aproveitando que você tocou nesse assunto, o programa que estou desenvolvendo tem a ver com jogo. Por isso e entender que é aonde mais se infiltra hackers, eu estou dando uma atenção especial na questão de segurança.
Sim teria que ser com uma API, tem como fazer com ahk mas muita gente usa java script.
Sobre a parte de hacker, eles se aproveitam de falhas, tipo, o programa muda uma coisa X no servidor sem o servidor verificar, ai ele pode abusar dessa falha para fazer outras coisas, como por exemplo em um servidor que eu tenho, tinha um sistema de hats que permitia o jogador enviar arquivos zip para ele com a skin própria dele, mas o servidor não verificava o zio, com um client modificado ele poderia enviar uma zip bomb e crashar o servidor ou envia um zip com path traversal e sobrescrever arquivos importantes do servidor, sempre valide o que o usuário manda para seu servidor.
Entendi! Seu exemplo me deixou atento sobre algumas alterações que eu possa fazer no futuro, obrigado. Eu atualmente utilizo a conexão com o Banco de Dados para validar se o usuário está com o plano em dia (usuário e senha de acesso), se true acessa, se false nega. O sistema também trabalha gerando tokens de verificação para impedir que outras pessoas utilizem a mesma conta (a cada tantos segundos ele gera uma nova chave unica enquanto a pessoa estiver logada), também tem esse trabalho constate com o DB. Outra coisa também é a verificação do tempo de plano, ele checa a cada 1 segundo se o tempo está válido, quando faltam 10 minutos ele emite um alerta e quando zera ele desconecta o usuário (tudo também ligado com o Banco de Dados). Então, baseado nessas funcionalidades que eu adaptei, você acredita que fica fácil alguém acessar a rota de conexão entre o programa e o servidor (DB), a fim de obter informações sigilosas? Ou só se ele conseguir decodificar meu programa e ter acesso aos dados de conexão (embora estejam Ofuscados)?
-----------------------------------------------------------
Stop to think, shut up to resist, and act to win!
User avatar
juanmuscaria
Posts: 65
Joined: 29 Oct 2017, 10:53
GitHub: juanmuscaria
Location: Brazil
Contact:

Re: Segurança do .exe AHK

30 May 2019, 16:06

manehscripts wrote:
30 May 2019, 15:47
Entendi! Seu exemplo me deixou atento sobre algumas alterações que eu possa fazer no futuro, obrigado. Eu atualmente utilizo a conexão com o Banco de Dados para validar se o usuário está com o plano em dia (usuário e senha de acesso), se true acessa, se false nega. O sistema também trabalha gerando tokens de verificação para impedir que outras pessoas utilizem a mesma conta (a cada tantos segundos ele gera uma nova chave unica enquanto a pessoa estiver logada), também tem esse trabalho constate com o DB. Outra coisa também é a verificação do tempo de plano, ele checa a cada 1 segundo se o tempo está válido, quando faltam 10 minutos ele emite um alerta e quando zera ele desconecta o usuário (tudo também ligado com o Banco de Dados). Então, baseado nessas funcionalidades que eu adaptei, você acredita que fica fácil alguém acessar a rota de conexão entre o programa e o servidor (DB), a fim de obter informações sigilosas? Ou só se ele conseguir decodificar meu programa e ter acesso aos dados de conexão (embora estejam Ofuscados)?
Sim, tendo o programa ele pode facilmente descobrir como funciona, e as vezes nem precisa do programa, colocando algo para observar trafego de rede ele pode pegar facilmente essas coisas. Sobre isso de verificação de token, caso o token expire, a api comece a ignorar requests do usuário, assim evite que continue tendo acesso mesmo tendo expirado o token.
E mais uma coisa, pode se pegar facilmente coisas na memoria de um programa caso não esteja criptografada, por isso vários jogos usam valores em criptografados para evitar que alguém altere/leia.
User avatar
manehscripts
Posts: 102
Joined: 03 May 2019, 16:10

Re: Segurança do .exe AHK

30 May 2019, 16:17

juanmuscaria wrote:
30 May 2019, 16:06
Sim, tendo o programa ele pode facilmente descobrir como funciona, e as vezes nem precisa do programa, colocando algo para observar trafego de rede ele pode pegar facilmente essas coisas. Sobre isso de verificação de token, caso o token expire, a api comece a ignorar requests do usuário, assim evite que continue tendo acesso mesmo tendo expirado o token.
E mais uma coisa, pode se pegar facilmente coisas na memoria de um programa caso não esteja criptografada, por isso vários jogos usam valores em criptografados para evitar que alguém altere/leia.
Ele pode conseguir ter acesso para qual IP está fazendo a rota, correto? Mas para ter acesso completo apenas obtendo os dados (user e password do Banco de Dados).
E sobre o token que vc falou foi uma ressalva do que eu já fiz? Ou você sugeriu também para outra situação que eu não entendi muito bem?

Pois é, meu código está todo ofuscado. Se não me engano o Gio falou alguma coisa sobre a criptografia, e você me fez pensar com mais calma sobre isso, talvez uma criptografia única a cada nova conexão, sei lá... Preciso estudar mais sobre essas adaptações de segurança. Atualmente eu estou usando apenar o Obfuscator.
-----------------------------------------------------------
Stop to think, shut up to resist, and act to win!
User avatar
juanmuscaria
Posts: 65
Joined: 29 Oct 2017, 10:53
GitHub: juanmuscaria
Location: Brazil
Contact:

Re: Segurança do .exe AHK

30 May 2019, 16:28

manehscripts wrote:
30 May 2019, 16:17
Ele pode conseguir ter acesso para qual IP está fazendo a rota, correto? Mas para ter acesso completo apenas obtendo os dados (user e password do Banco de Dados).
E sobre o token que vc falou foi uma ressalva do que eu já fiz? Ou você sugeriu também para outra situação que eu não entendi muito bem?

Pois é, meu código está todo ofuscado. Se não me engano o Gio falou alguma coisa sobre a criptografia, e você me fez pensar com mais calma sobre isso, talvez uma criptografia única a cada nova conexão, sei lá... Preciso estudar mais sobre essas adaptações de segurança. Atualmente eu estou usando apenar o Obfuscator.
Sim, ele pode pegar o ip que está sendo usado com o banco de dados junto com as credenciais dele (já que os sniffers de rede pega tanto o ip alvo quanto os dados da conexão), por isso fazendo uma API que controle isso seria muito melhor, e tendo as credenciais no script tb é algo meio perigoso, ofuscando só dificulta a vida do cara, mas se ele estiver sendo pago eu tenho certeza que ele pega.

A criptografia serve mais para evitar que alguém tente roubar as informações do usuário (tipo o login dele para pegar o token de acesso).

Vamos pegar o discord como um exemplo de API:
Você coloca as suas credencias nele, ele manda um request com suas credenciais para api e retorna o seu token, ai a api manda as informações que o client precisa, ai qualquer coisa que você faça (como mandar uma mensagem) ele manda para API o que você fez (tipo a mensagem que você mandou).

Recomendo dar uma olhada no OAuth 2.0 para esse tipo de coisa (que é o que o discord usa) https://oauth.net/2/
User avatar
manehscripts
Posts: 102
Joined: 03 May 2019, 16:10

Re: Segurança do .exe AHK

30 May 2019, 16:40

juanmuscaria wrote:
30 May 2019, 16:28
Sim, ele pode pegar o ip que está sendo usado com o banco de dados junto com as credenciais dele (já que os sniffers de rede pega tanto o ip alvo quanto os dados da conexão), por isso fazendo uma API que controle isso seria muito melhor, e tendo as credenciais no script tb é algo meio perigoso, ofuscando só dificulta a vida do cara, mas se ele estiver sendo pago eu tenho certeza que ele pega.

A criptografia serve mais para evitar que alguém tente roubar as informações do usuário (tipo o login dele para pegar o token de acesso).

Vamos pegar o discord como um exemplo de API:
Você coloca as suas credencias nele, ele manda um request com suas credenciais para api e retorna o seu token, ai a api manda as informações que o client precisa, ai qualquer coisa que você faça (como mandar uma mensagem) ele manda para API o que você fez (tipo a mensagem que você mandou).

Recomendo dar uma olhada no OAuth 2.0 para esse tipo de coisa (que é o que o discord usa) https://oauth.net/2/
Já deve ter percebido que eu sou um novato na programação, né? :lol: Cada susto que eu levo com alguns comentários, mas compreendo o risco.
Eu ter aberto esse post foi interessante, pois pessoas como vocês abrem a nossa mente para novas pesquisas de estudo além de adquirir mais conhecimento dinâmico.
Obrigado, esterei lendo melhor sobre o OAuth e como trabalhar com API! :thumbup:
-----------------------------------------------------------
Stop to think, shut up to resist, and act to win!
User avatar
Gio
Posts: 684
Joined: 30 Sep 2013, 10:54
Location: Brazil

Re: Segurança do .exe AHK

31 May 2019, 10:35

juanmuscaria wrote:
30 May 2019, 12:57
um grande exemplo do por que se deve fazer isso são jogos, esses jogos onde a maior parte dos cálculos e verificações são feitas do lado do cliente sempre vai estar cheio de hackers, mas esses onde é o servidor que processa tudo raramente você vê um hacker.
Interessante isso que você falou. Eu não tinha parado para pensar, mas de fato, quando eu jogava jogos online tive conhecimento de que havia umas comunidades à parte dedicadas ao hacking destes jogos. Engraçado isso, mas parece que hacking é uma coisa que interessa mais do que o normal aos gamers. É um fato bem curioso, o normal seria pensar que serviços que geram algum interesse comercial nos usuários seriam um alvo mais comum :wtf:

Será porque os jogos acabam formando grandes comunidades com alto grau de competitividade? Ou seria a ideia de que burlar um jogo não é algo tão sério? Ou talvez um outro efeito qualquer (por exemplo, grande número de adolescentes com apego à tecnologia envolvidos)? Vou ter isso mais claro em mente agora se um dia for projetar algo relacionado à jogos online.
User avatar
juanmuscaria
Posts: 65
Joined: 29 Oct 2017, 10:53
GitHub: juanmuscaria
Location: Brazil
Contact:

Re: Segurança do .exe AHK

31 May 2019, 11:07

Essa parte de hacking de jogo é meio complicado, já que tem gente que faz isso para o bem e para o mal, normalmente esses jogos que tem comunidade focada em hacking ajuda bastante o jogo para corrigir falhas, mas sempre tem o lado ruim onde tem gente que faz isso só para destruir o jogo. Um grande exemplo disso é minecraft, a comunidade de modding e hacking é gigantesca, onde um monte de gente já desenvolveu ferramentas, patchs e sistemas de proteções mt bons, mas tem a outra parte da comunidade que faz hacks para destruir o jogo, ai fica na batalha entre as 2 comunidade em um jogo de gato e rato.
E um adicional, maior parte das pessoas fazem isso para adquirir conhecimento e por diversão mesmo, no meu tempo livre fico procurando exploits para poder corrigir, nesse meio tempo aprendi muita coisa relacionada a segurança e porque você deve pensar em situações quase impossíveis de acontecer.
User avatar
Gio
Posts: 684
Joined: 30 Sep 2013, 10:54
Location: Brazil

Re: Segurança do .exe AHK

07 Jun 2019, 11:38

juanmuscaria wrote:
31 May 2019, 11:07
E um adicional, maior parte das pessoas fazem isso para adquirir conhecimento e por diversão mesmo, no meu tempo livre fico procurando exploits para poder corrigir, nesse meio tempo aprendi muita coisa relacionada a segurança e porque você deve pensar em situações quase impossíveis de acontecer.
Entendo. É um hobby um pouco estranho para mim, mas pelo menos ele aumenta o conhecimento sobre segurança da informação :D

Mas agora fiquei interessado nas consequências da existência dessa comunidade de hackers de jogos :think:

Foi publicada hoje uma notícia interessante relacionada ao tema no G1. Trata-se de uma falha (BlueKeep) descoberta no acesso remoto do windows (do XP ao 7) que permite que um hacker "ganhe controle do Windows" de uma máquina (palavras do jornalista) sem que o alvo tenha feito qualquer ação. A falha aparentemente já foi corrigida, mas sistemas desatualizados ficarão em risco até que sejam atualizados.

Na sua opinião, publicar uma falha dessas (somente a existência, sem o código) para que seja então gerada uma correção e com isso gerar também uma necessidade de retrabalho por parte dos desenvolvedores (devido ao receio de que mais pessoas agora pesquisem e descubram o exploit) é algo que justifica a publicação dessa falha OU manter sigilo (e com isso evitar o custo da carga de trabalho) sobre essa falha seria melhor ainda para os desenvolvedores e para a sociedade (que como passou décadas sem se preocupar [desde o lançamento do XP no caso do BlueKeep], teoricamente poderia não ter problema nenhum antes de o programa se tornar totalmente obsoleto)? Ou seja: o risco que se corre em manter a falha sob sigilo justifica o custo do desenvolvedor e da sociedade em ter que consertá-la?

Ou melhor fraseando: Se a comunidade de hackers (parte boa) ajuda o desenvolvedor de jogos a evoluir sua segurança para se proteger da própria comunidade de hackers (parte má) não seria melhor que essa comunidade simplesmente não existisse e que não tivéssemos o custo dessa guerra fria?

E outra pergunta: publicar a existência da falha (como fizeram com o BlueKeep) é uma forma de forçar o desenvolvedor a não apostar no sigilo dela, e então fazer o trabalho de correção? Ou será que não é então uma forma de forçar (extorquir) o desenvolvedor a entrar em contato com o suposto hacker "bom" e ter de pagar a ele pelo conhecimento sobre a falha? Se a última pergunta for sim, ficar pesquisando e vendendo a correção de falhas para sistemas alheios não seria um trabalho "sujo"?

Link da matéria: https://g1.globo.com/economia/tecnologi ... dows.ghtml
User avatar
juanmuscaria
Posts: 65
Joined: 29 Oct 2017, 10:53
GitHub: juanmuscaria
Location: Brazil
Contact:

Re: Segurança do .exe AHK

07 Jun 2019, 20:30

Depende muito da situação, software livre de código aberto normalmente postam a falha junto com a correção, algumas empresas grandes normalmente guardam em sigilo a falha até ser corrigida, e postando uma falha sem a correção e sem a empresa saber pode ter alguma consequências ruins, empresa grande consegue lidar com isso rápido, softwares de codigo publico famosos também , um exemplo de falha de segurança revelada para o publico e ficou muito tempo sem correção foi um exploit no minecraft permitindo ferrar completamente com o sistema de save do jogo com "crafted packets"contendo grandes quantidades de dados em um livro, fazendo o jogo não conseguir salva e podendo duplicar itens, eu sei que na época isso foi um caos, outro exemplo é essa guerra fria entre os hackers que fazem homebrew, os caras que fazem pirataria e as empresas de console (Xbox, PS e outros consoles ai), onde esse pessoal do homebrew descobria falha e ficava guardando elas para ter a maior quantidade de firmwares possíveis com a tal falha.
Maior parte dos exploits de segurança são arrumados antes de serem publicados, mas pode ocorrer o que eu falei a cima, em questão de software publico publicar essas falhas e como ela pode ser feita ajuda a resolver rapidamente ela, já publicar falhas de software proprietário e que normalmente demora para receber update pode destruir o aplicativo.
User avatar
juanmuscaria
Posts: 65
Joined: 29 Oct 2017, 10:53
GitHub: juanmuscaria
Location: Brazil
Contact:

Re: Segurança do .exe AHK

17 Jun 2019, 20:15

Tava agora vendo alguns videos aleatórios em quanto baixo algumas coisa e achei um video que tem algumas coisas muito boas relacionada a segurança.
User avatar
Gio
Posts: 684
Joined: 30 Sep 2013, 10:54
Location: Brazil

Re: Segurança do .exe AHK

18 Jun 2019, 09:33

juanmuscaria wrote:
07 Jun 2019, 20:30
exemplo é essa guerra fria entre os hackers que fazem homebrew, os caras que fazem pirataria e as empresas de console (Xbox, PS e outros consoles ai), onde esse pessoal do homebrew descobria falha e ficava guardando elas para ter a maior quantidade de firmwares possíveis com a tal falha.
Lembrei de um caso interessante agora que você tocou no assunto dos consoles (equipamentos conhecidos antigamente como video-games). O console mais recente da nintendo, o Nintendo Switch tem uma arquitetura baseada em um chip Tegra X1. Os hackers descobriram que esse chip tinha um problema no hardware que permitia a injeção de código para execução pelo equipamento. Com um pouco de busca, descobriram ainda que a falha poderia ser acessada no nintendo switch, e para isso bastava causar um pequeno curto entre dois dos pinos onde o controle se conecta ao equipamento. O resultado foi a invenção de uma espécie de gambiarra hacker que você conecta no console e permite rodar jogos piratas baixados da internet no próprio console.

Quando a falha foi publicada, a nintendo conseguiu corrigir rapidamente na sua linha de produção, mas uma grande quantidade de consoles produzidos anteriormente já estavam no mercado e o resultado foi o nascimento de uma espécie de segundo mercado do console "desbloqueável", que mesmo usado pode chegar a custar até um pouco mais que um novo. O curioso é que os hackers passaram então a vender a gambiarra desbloqueadora livremente na internet e a desenvolver updates regulares para o software da gambiarra. Sempre que a nintendo lança uma nova versão do seu sistema operacional, ela coloca um código para impedir o uso da falha nos consoles antigos que venham a ser atualizados (e você só acessa os serviços do console se estiver atualizado), e aí poucas semanas depois já vem uma atualização da gambiarra hacker que permite rodar ela na nova versão. Uma verdadeira queda-de-braço dos hackers com a empresa.

Na minha opinião, a empresa está perdendo bastante com isso, pois seus softwares são caros e podem ser pirateados com muita facilidade por quem usa essa gambiarra hacker, o que significa que qualquer pessoa sem barreiras ético-morais sobre o assunto pode preferir a solução hacker (mais barata). Por outro lado, os hackers costumam se posicionar contrários ao que a empresa faz: desenvolver consoles com alto nível de vendor lock-in. A ideia deles é que se você compra um equipamento eletrônico, a empresa que o vendeu não tem o direito de dizer como você vai usar aquele equipamento (pois ele seria totalmente seu) e como as empresas basicamente se usam da tecnologia para impedir a execução de software de terceiros no equipamento, suas ações é que seriam abusivas.

Já sobre essas acusações de vendor lock-in, as empresas costumam se defender alegando que o mercado inteiro já adotou essa estratégia, e que ela é um mero reflexo da preferência dos próprios consumidores e de algumas barreiras práticas da operação. Para começar, o objetivo das empresas é vender jogos (e não consoles) pois os jogos, ao contrário dos consoles, são massificáveis (por exemplo: um consumidor normalmente só compra 1 console, mas pode comprar 100 jogos). No entanto, para vender jogos, é preciso que os consumidores tenham consoles, e por isso, o mercado chegou a um ponto em que a venda do console sequer dá lucro ao fabricante: os fabricantes de consoles são forçados por via de concorrência a entregar a melhor tecnologia possível com o menor preço possível ao consumidor, de modo que as vezes perdem dinheiro vendendo os equipamentos (na expectativa de ganhar vendendo os jogos).

Return to “Ajuda e Suporte Geral”

Who is online

Users browsing this forum: No registered users and 3 guests