Que encriptadores para PHP conheces?

[AriOps]

Digam neste tópico que encriptadores de código conhecem e as suas vantagens em relação aos outros (opcional claro 😞)

Só conheço o Zend Guard, desvantagem vi logo uma, é preciso ter o Zend Optimizer no servidor.  :bored:

[djthyrax]

Qual é o objectivo de usar encriptadores? Acho estúpido usar isso.

[AriOps]

Pois mas há pessoal que usa. Como eu preciso de um desencriptador específico estou a ver o que é que o pessoal conhece, pode ser que alguém conheça o que me serve 😞

[djthyrax]

http://www.google.com/search?hl=en&client=firefox-a&rls=com.ubuntu:en-US:official&hs=xwg&sa=X&oi=spell&resnum=0&ct=result&cd=1&q=PHP+code+encrypter&spell=1

Encontrei logo: http://www.sourceguardian.com/

[DanielGomes]

Qual é o objectivo de usar encriptadores? Acho estúpido usar isso.

O objectivo, segundo os fabricantes, é proteger o código-fonte e ao mesmo tempo acelerar a execução dos scripts.

Em resposta ao tópico: conheço o SourceGuardian, Ioncube e PHPShield.

Todos eles funcionam de forma semelhante e não é necessário instalar nada no servidor, apenas adicionar "loaders" ao site. O PHPShield é o mais barato (cerca de 60€) e tem servido para as minhas necessidades.

[falco]

Proteger o código de quê?

Que disparate...

[AriOps]

Proteger o código de quê?

Que disparate...

Imagina que forneces um serviço a um cliente, uma plataforma programada por ti e que tu vendes aos outros.

Se o teu cliente quiser, tendo o código fonte pode vender a quem quiser (não é bem assim mas é quase).

Eu pessoalmente não uso, mas existe quem o faça.

[DanielGomes]

Obviamente que quem desenvolve software open-source ou quem não tem grandes preocupações com o paradeiro do seu código não precisa.

Eu não cobro pelo software que desenvolvo mas protejo-o na mesma para evitar dissabores com clientes e mesmo alguns problemas de segurança. É uma questão de necessidade e/ou escolha de quem trabalha: para uns é um disparate, para outros é útil.

[falco]

Imagina que forneces um serviço a um cliente, uma plataforma programada por ti e que tu vendes aos outros.

Se tu vendes a plataforma, então a plataforma passa a ser dos outros...

Não confundir o vender software com o licenciar software...

Eu não cobro pelo software que desenvolvo mas protejo-o na mesma para evitar dissabores com clientes e mesmo alguns problemas de segurança. É uma questão de necessidade e/ou escolha de quem trabalha: para uns é um disparate, para outros é útil.

Proteges de quê?

Problemas de segurança? Quais?

Isso é parvo. A aplicação vai ser executada pelo interpretador de PHP, basta modificar o interpretador de PHP, para se ter acesso ao código fonte. E vejam lá que o interpretador até é Software Livre, ou seja, tem o código fonte acessível. Ou seja, a isso de encriptar o código é completamente inútil.

A única forma que têm de não permitir o acesso ao código de uma aplicação PHP é não distribuirem a aplicação, ou seja, executam-na num servidor vosso controlado exclusivamente por vocês. O resto são coisas para a Alice no país das maravilhas.

[Triton]

A aplicação vai ser executada pelo interpretador de PHP, basta modificar o interpretador de PHP, para se ter acesso ao código fonte. E vejam lá que o interpretador até é Software Livre, ou seja, tem o código fonte acessível. Ou seja, a isso de encriptar o código é completamente inútil.

Sendo assim também podes aceder ao código de qualquer aplicação, basta usar um disassembler, ou um descompilador para uma linguagem.

[DanielGomes]

Imagina que forneces um serviço a um cliente, uma plataforma programada por ti e que tu vendes aos outros.

Se tu vendes a plataforma, então a plataforma passa a ser dos outros...

Não confundir o vender software com o licenciar software...

Eu não cobro pelo software que desenvolvo mas protejo-o na mesma para evitar dissabores com clientes e mesmo alguns problemas de segurança. É uma questão de necessidade e/ou escolha de quem trabalha: para uns é um disparate, para outros é útil.

Proteges de quê?

Problemas de segurança? Quais?

Isso é parvo. A aplicação vai ser executada pelo interpretador de PHP, basta modificar o interpretador de PHP, para se ter acesso ao código fonte. E vejam lá que o interpretador até é Software Livre, ou seja, tem o código fonte acessível. Ou seja, a isso de encriptar o código é completamente inútil.

A única forma que têm de não permitir o acesso ao código de uma aplicação PHP é não distribuirem a aplicação, ou seja, executam-na num servidor vosso controlado exclusivamente por vocês. O resto são coisas para a Alice no país das maravilhas.

Instalar anti-virus também é completamente inutil se eu puder aceder à tua máquina e desactivar o programa para a conseguir infectar. Mas eu não tenho acesso à tua máquina, como muitos clientes não têm acesso aos seus servidores e muito menos fazem ideia de como aceder a nada. De qualquer das formas nem sei se o que dizes é assim tão fácil: boa sorte a obter a fonte a partir de um script obfuscado, encriptado e codificado em bytecode. Eu não tenho conhecimentos para tanto, confesso.

Em segurança fala-se de minimizar o risco, não de o eliminar. O facto de alguém poder ver o meu código e usar eventuais falhas de segurança (ninguém é perfeito) para atacar os meus clientes é uma preocupação a ter em conta. Depois, fornecer a aplicação protegida deixa-me descansado para que eu não tenha de "fidelizar" o cliente para sempre e/ou a ter o site no meu servidor para que eu o possa vigiar. Poderá continuar a usar o software onde quiser, só não pode é modificá-lo. Simples.

Um quote do site do Ioncube:

Q. Can encoded files be restored to original source?

A. No. Unlike systems that work by hiding sourcecode and then restoring it at runtime, the ionCube encoding system compiles scripts into bytecode before the encoding process. This eliminates the source code by transforming it into a binary machine code language.

Although no security system can be immune to reverse engineering tactics, our approach adds security at many stages and provides formidable challenges to analsys.

[falco]

Tive a pesquisar um pouco sobre esse ioncube, para ele funcionar precisa de uma extenção ao PHP...

Isso não tem grande Futuro, o funcionamento do ioncube não é suportado pela malta do PHP, e é fechado, o resultado disso é que não deve funcionar em muitas versões do PHP e também não deve ser muito rápido a lidar com novas versões, talvez quebre com patchs de distribuidores, etc...

Ainda assim acho uma perda de tempo, de dinheiro e uma dor de cabeça para manutenção de sistemas e de aplicações.

[DanielGomes]

Tive a pesquisar um pouco sobre esse ioncube, para ele funcionar precisa de uma extenção ao PHP...

Isso não tem grande Futuro, o funcionamento do ioncube não é suportado pela malta do PHP, e é fechado, o resultado disso é que não deve funcionar em muitas versões do PHP e também não deve ser muito rápido a lidar com novas versões, talvez quebre com patchs de distribuidores, etc...

Ainda assim acho uma perda de tempo, de dinheiro e uma dor de cabeça para manutenção de sistemas e de aplicações.

Se pesquisares mais um pouco (http://www.ioncube.com/loaders.php) verás que há "loaders" para todas as plataformas e todas as versões do PHP, das mais antigas às mais recentes. Os loaders são executados a pedido (runtime) e não precisam de instalação. Seguem numa pasta, com o teu programa. A unica coisa que precisas e que me lembro de repente é que a função dl() deve poder ser chamada pelos scripts, nada que os ISPs me tenham recusado fazer até hoje.

O suporte da comunidade não é relevante neste caso pois trata-se de um produto comercial, e o Ioncube e SourceGuardian (e a versão "lite", o PHPShield) já andam por aí há uns anitos e têm-se safado bem.

[falco]

Quando falei em ser suportado, falava em mantido... É um pouco como os drivers proprietários e o kernel Linux, frequentemente alterações ao kernel quebram os drivers, se os drivers fossem livres a malta do kernel conseguia evitar isso.

[Procrastinator]

Uma boa solução para isto é criar web services! Nunca dar codigo a ninguem (a não ser obviamente que queiram). Creio que é esta a filosofia do google (como por exemplo o google maps) e penso segui-la.

[Triton]

Quando falei em ser suportado, falava em mantido... É um pouco como os drivers proprietários e o kernel Linux, frequentemente alterações ao kernel quebram os drivers, se os drivers fossem livres a malta do kernel conseguia evitar isso.

falco, não é preciso os drivers serem livres para a malta do kernel evitar quebrar drivers.

[pedrotuga]

Matenham-se no tema do tópico.

Sempre que há alguem que fala num ofucador de uma linguagem interpretada aparecem logo uma carrada de respostas a dizer que isso não serve para nada e que é parvo, etc.

Curiosamente, sempre que alguem aparece a perguntar como fazer disassemble de código compilado aparecem tambem não sei quantas respostas a dizer que é ilegal etc.

Respondam simplesmente à questão colocada ou discutam o tema. Por muito sem-sentido que seja o motivo do utilizador, concerteza do que lhe pedir satisfações ou explicações sobre para que quer ele um ofuscador, ainda é mais descabido.

[falco]

falco, não é preciso os drivers serem livres para a malta do kernel evitar quebrar drivers.

Há muitas ocasiões é que é.

Há alturas é que se quer fazer modificações que têm que romper com a forma como as coisas funcionavam. E ou se escolhe fazer essa modificação, ou se escolhe não fazer a modificação porque o fabricante de um driver não quer/pode. Acho que ninguém pode correctamente achar que o desenvolvimento de um kernel deve parar porque os developers de drivers não conseguem acompanhar o ritmo e não querem deixar que outros que poderiam resolver os problemas dos drivers os resolvam. Por isso a malta do kernel faz o esforço que for razoável para não quebrar o funcionamento das coisas desde que isso não impeça de fazerem as coisas da forma que eles acham mais adequada para o kernel, é por isso que às vezes os fabricantes de drivers proprietários se queixam de as coisas mudarem e por isso quebrarem e é por isso que por exemplo no ALSA, existe uma componente que permite ao ALSA utilizar os drivers do deprecado sistema OSS (era um esforço razoável tendo em conta o impacto).

Mas isso é discussão para outro tópico...

Uma boa solução para isto é criar web services! Nunca dar codigo a ninguem (a não ser obviamente que queiram). Creio que é esta a filosofia do google (como por exemplo o google maps) e penso segui-la.

A maior parte da estratégia do Google centra-se à volta disso e funciona bem para o Google e para outras empresas com casos similares, mas não é solução para todos os casos (como por exemplo o desenvolvimento de um site para uma empresa).

Curiosamente, sempre que alguem aparece a perguntar como fazer disassemble de código compilado aparecem tambem não sei quantas respostas a dizer que é ilegal etc.

E de facto em alguns países é ilegal, em outros não é e em alguns como em Portugal, não é totalmente ilegal (mas como não jurista recomendo que evitem fazer isso se não conhecerem a lei em detalhe). Estou a ver se preparo uma thread que discute precisamente esta temática neste contexto, mas falta-me tempo, porque implica a pesquisa em diversos diplomas legais (e suas sucessivas alterações), bem como a preparação da argumentação da minha opinião.