Essas criptografias eu conheço, eu quis dizer uma criptografia como a Zend Guard, já ouvi dizer que existem algumas gratuitas, mas tem de ser instaladas no servidor!
To pesquisando aqui, mas ta meio complicado achar uma boa, alguém conhece alguma desse tipo?
Como vai rodar local, não vejo problema em instalar o software para trabalhar junto com o apache
Qualquer uma que você escolher vai servir então.
Sua aplicação vai rodar local no cliente, mas ainda sim, num servidor.
Eu testei o PHTML Encoder 6.2, mas não funcionou com a aplicação gerada em scriptcase!
O zend nao rolo tambem, olha como que fica quando tento acessar o control_login
????????????????????????? ???????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????
olha o phpinfo();
ta aparecendo que o zend ta ativo!
Zend Memory Manager enabled Zend Multibyte Support enabledThis program makes use of the Zend Scripting Language Engine:
Zend Engine v2.3.0, Copyright © 1998-2011 Zend Technologies
Eu quem estou fazendo alguma coisa errada ou nao funciona mesmo?
Estou testando com o xampp
Olha só eu poço te ajudar sim. Eu comprei um software que promete criptografar o código pgp porem nao testei ainda se chama phplockit. Posso criptografar pra vc o que vc quer e vc testa pra ver se da certo.
tem alguma versão trial do phplockit?
fiz um teste aqui no servidor onde está instalado o scriptcase e o codigo criptografado pelo zend na versão trial funcionou!
Porem no xampp por mais qeu esteja escrito que está habilitado, aparece um monte de ??? na pagina e mais nada.
Outro problema é o preço absurdo que eles cobram.
Tem uma versão trial sim do PhpLockit segue o site http://www.phplockit.com/, assim que tiver um tempo vou testar a fundo, tentei criptografar um sistema inteiro e não rolou não. Acho que o certo é pegar apps mais fundamentais para o funcionamento e criptografar somente elas.
Fico a disposição!
Saulo, aqui não rolo tambem, da esse erro:
Fatal error: Call to undefined method control_login_edit::inicializa() in D:\ScriptCase\v5\wwwroot\scriptcase\app\teste\control_login\control_login.php(1) : eval()'d code(1) : eval()'d code(1) : eval()'d code on line 1233
O unico que rolo aqui foi o Zend, porem ele deu erro ao criptografar uma Grid, mas para testes rolo legal, só não consegui fazer o zend rodar no xampp e o foda é o custo auto da ferramenta!
É complicado, esses ofucadores de código se perdem no decorrer de códigos grandes e complexos como é o caso código gerado pelo ScriptCase. Eu sinceramente acho que nenhuma solução fará essa criptografia de código com eficiência no caso do Scriptcase. São muitas variáveies e funções internas, fora os casos de uso do Ajax, javascript e bibliotecas como a fpdf, e geração de gráficos. É muita coisa pra tratar em um código só.
Acho que podemos trabalhar em conjunto e desenvolver uma solução pra travar o código por máquina (servidor) como você havia proposto.
Vamos ver…
Visto que já encontram maneiras de ofuscar um código mais simples, talvez fazer uma aplicação na unha para validar uma arquivo txt com criptografia para validação de licença seja viável. Assim terá o “sistema de validação” criptografado. O sistema de validação recebe um arquivo txt, interpreta os dados e valida a licença ou tempo de vida da licença. Quando expirar, requer um novo arquivo. Pode ser uma alternativa.
Boa Tarde Cleyton Euler,
Isso eu já fasso, mas os dados ficam no banco de dados e não em um txt que acho mais viável, o problema é que se a pessoa abrir o código fonte do control_login por exemplo e apagar as linhas que fazem a validação, a pessoa consegue utilizar o sistema normalmente, até mesmo com a licença expirada!
O mesmo vai acontecer se criar uma rotina para ler o txt, basta a pessoa somente comentar, não precisa nem apagar, as linhas que fazem a validação e pronto, a pessoa tem acesso ao sistema!
Agora, se o código em PHP estiver criptografado, fica mais complicado da pessoa descriptografar primeiro o arquivo e depois procurar pelas linhas de validação, ou seja, a criptografia seria um passo que somente um usuário muito avançado conseguiria quebrar e alguém desse nível iria cobrar um preço bem alto, coisa que duvido muito que o pessoal pague!
Alguém saberia me dizer o que torna o código gerado pelo scriptcase tão complicado de se criptografar, a ponto de somente o Zend Conseguir essa tal façanha?
o código gerado pelo sc além de complexo possui muitos erros internos, um ofuscador, embaralha o código e de forma interpretativa desembaralha na execução através do eval, o Zend, é instalado no servidor junto com o php, e o código criptografado pelo zend é gravado em um arquivo, o que o zend faz ao executar esse arquivo é trazê-lo exatamente como o original, os ofuscadores, como usam o eval não consegue isso porque ele interpreta a decodificação durante a execução, e se tiver erro o eval não vai funcionar.
Então, o que eu disse é vc fazer essa validação fora do controle de login do sc, de forma que vc consiga ofusca o código do script que faz essa validação. Estou dizendo isso considerando que no seu caso não há a possibilidade de ter essa validação em bd posto que seu cliente não tem acesso a Internet.
Vamos supor que sua aplicação de menu executa uma verificação no onLoad. Licença em dia, tudo bem, continua execução. Licença expirada, chama um script que pede o arquivo txt para validar. Se o cliente não tiver um arquivo, tem que entrar em contato com vc para envio. Aqui vc pode ofuscar o script que faz a validação, visto que é feito de forma “convencional” e o arquivo txt que vc manda tem os dados de validação criptografados.
Perfeita consideração Haroldo. Acho que a dica do Cleyton deveria ser estudada!
O que ele diz é que um técnico pode abrir o fonte desse login e burlar esse código que valida esse arquivo.
Então, visto que ele já conseguiu aplicar um ofuscador com sucesso no código, o técnico veria algo incompreensível nesse controle de validação.
Pelo que percebi o problema está em conseguir usar um ofuscador no controle de login nativo do SC. Deste modo, minha idéia é fazer isso na unha e aplicar o ofuscador combinado com o txt criptografado. Talvez funcione.
Isso seria uma boa sugestão para o SC6, deixar alguma ferramenta para criptografar algo no arquivo fonte, na questão de segurança!
Cleyton, vou dar uma estudada aqui em uma possibilidade de colocar esse arquivo criptografado e ver se funciona e posto o resultado aqui, mas pensando de forma que eu queira burlar um sistema, eu poderia mais uma vez abrir os fontes do menu e remover a associação a esse arquivo criptografado que valida o sistema.
Posso estar pensando ou interpretando errado o que você disse, mas um exemplo:
A aplicação Menu chama um arquivo criptografado, se ele não existir ou se ele não validar a maquina, ele te redireciona para o control_login certo? (Pode ser algo até mais elaborado, atualizando o banco de dados como autorizar = 0).
Mas e se eu remover esse script que associa a esse arquivo criptografado na aplicação menu?
E se eu remover todas as linhas de comando que chamam esse arquivo criptografado?
O problema não é ter um arquivo criptografado, o problema é alguém conseguir remover a(s) linha(s) de comando que chama esse arquivo!
Se pelo menos eu consegui-se fazer o control_login criptografado, já ajudava, pois o próprio scriptcase não deixa acessar as demais aplicações se você não estiver logado!
Então amigo tudo isso deve ser considerado, mais pense no seguinte, você criptografou o control_login, o que o control login faz? Ele habilita e/ou desativa aplicações de acordo com o login/grupo e direciona para o menu ou outra aplicação qualquer que você definir.
Um cara que tem gabarito pra mexer no código pode criar manualmente um control_login picareta e fazer essas validações e pronto, sua segurança estará comprometida mais uma vez.
A grande questão é, quanto vale a pena investir em um sistema tão seguro a ponto de impedir qualquer pessoa com conhecimento de mexer nele, nossas aplicações não tem um apelo comercial tão grande a ponto de alguém querer perder tempo com isso (as minhas pelo menos não tem) trabalhamos com pequenas corporações e acho que essa implementação seria interessante para casos onde a aplicação term um nível de procura etremamente alto, tipo se você realmente desenvolver a galinha dos ovos de ouro, fora isso não acho que alguém vai ter saco de mexer no código do sc.
Fora que a validação pode ser implementada em todas as aplicações, não precisa ser só no control_login, duvido que alguém se atreveria a mexer em 5 apps do SC pra descobrir onde você travou o sistemas.
Um abraço!
ta certo saulo, minhas aplicações são para empresa pequenas também, nada muito grande, mas pensando em caso alguém queira roubar o sistema.
Já vi que criptografar os fontes só se for com o zend (inviável)!
O mais certo é mandar uma aplicação limitada ao cliente que quiser testar os 30 dias ou se quiser testar o full tem de ter acesso a web.
Esse tópico foi muito esclarecedor creio que não só para a minha empresa, mas para muitos que possam a vir no futuro procurar uma solução desse tipo!