programa para o V.b.

[creative]

Queria saber se existe algum programa que consiga arranjar o codigo-Fonte de um programa de Visual Basic.Net.
tipo temos o programa ja feito, e ele consegue arranjar o codigo-fonte desse mesmo programa.

Sei k deve ñ deve existir um programa dexex, mas mesmo assim era pa matar a curiosidade.

fikem bem

[-CrEaTiVe-]

[deathseeker25]

Como dizes não existe tal tipo de programas. O mais parecido com o que estás a falar é um disassembler, mas só para código em Assembly. A esse tipo de engenharia chama-se reverse-engeneering.

Se quiseres ler algo sobre os disassemblers clica aqui.

Cumps

[LuisFilipe]

Como dizes não existe tal tipo de programas.

Claro que existem.

O mais parecido com o que estás a falar é um disassembler, mas só para código em Assembly.

Claro que assembly tem uma relação directa de um para um com o código que os CPU's executam.

A esse tipo de engenharia chama-se reverse-engeneering.

Estás a ver que existe. Se bem que esse termo não se aplica aqui directamente.

Por ex: tendo uma linguagem C -> OBJ -> EXE -> Assembly (ou OBJ) -> C. Agora é só comparar com o original.

Visto que o Basic é interpretado ou précompilado não existe a passagem a código máquina, existem sim protecções ao código (ténues) e alguma optimização.
Assim: BASIC -> pseudocódigo -> encapsulamento -> EXE -> desencapsulamento -> pseudocódigo -> BASIC

Eu só não postei aqui alguma coisa porque vai contra as regras do forum de resto se se googlar um pouco encontra-se tudo e mais alguma coisa. Mesmo já pronto a servir, claro que a pagar...

[r3pek]

Como dizes não existe tal tipo de programas.

Claro que existem.

Hás de me dizer onde (para VB)? Conheço software que consegue fazer qq coisa mas para C, mas o binário (.exe) não pode ser muito complicado e é _muito_ bem pago!!

O mais parecido com o que estás a falar é um disassembler, mas só para código em Assembly.

Claro que assembly tem uma relação directa de um para um com o código que os CPU's executam.

A esse tipo de engenharia chama-se reverse-engeneering.

Estás a ver que existe. Se bem que esse termo não se aplica aqui directamente.

pk não? é o k ele ta a fazer...

Por ex: tendo uma linguagem C -> OBJ -> EXE -> Assembly (ou OBJ) -> C. Agora é só comparar com o original.

Visto que o Basic é interpretado ou précompilado não existe a passagem a código máquina, existem sim protecções ao código (ténues) e alguma optimização.
Assim: BASIC -> pseudocódigo -> encapsulamento -> EXE -> desencapsulamento -> pseudocódigo -> BASIC

Onde é k isto é verdade?! Um processador não sabe executar mais nd a nao ser Assembler (ou mais baixo ainda, opcodes). Quer a linguagem seja interpretada ou compilada, desque que tenha um binário (.exe), este vai ter sempre o código assembler corresponde a _toda_ a aplicação compilada!

[xirix]

Queria saber se existe algum programa que consiga arranjar o codigo-Fonte de um programa de Visual Basic.Net.
tipo temos o programa ja feito, e ele consegue arranjar o codigo-fonte desse mesmo programa.

Sei k deve ñ deve existir um programa dexex, mas mesmo assim era pa matar a curiosidade.

fikem bem

[-CrEaTiVe-]

Procura na net por .NET Reflector. Ele traduz o IL para código C#, VB.NET ou Delphi.

Como as linguagens .NET não são como as outras linguagens que na compilação passam para código de máquina, passa para IL (intermediate language) é possivél reverter o processo e obter código fonte.

Antes que venham falar mal ".NET Microsoft tinha que ser uma m3rda", etc etc etc. JAVA em vez de IL é os bytecodes e tb há programas para isso.

PS. Este programa para .NET até os comentários ele saca

Abraços

[LuisFilipe]

Como dizes não existe tal tipo de programas.

Claro que existem.

Hás de me dizer onde (para VB)? Conheço software que consegue fazer qq coisa mas para C, mas o binário (.exe) não pode ser muito complicado e é _muito_ bem pago!!

É curioso como alguém pode dizer que não existe algo de tão simples como utilizar um conjunto 'conhecido' de regras e aplica-las ao contrário. Ora verifica lá isto Decompiler Round-Up, Regenerating Your Code

Por ex: tendo uma linguagem C -> OBJ -> EXE -> Assembly (ou OBJ) -> C. Agora é só comparar com o original.

Visto que o Basic é interpretado ou précompilado não existe a passagem a código máquina, existem sim protecções ao código (ténues) e alguma optimização.
Assim: BASIC -> pseudocódigo -> encapsulamento -> EXE -> desencapsulamento -> pseudocódigo -> BASIC

Onde é k isto é verdade?! Um processador não sabe executar mais nd a nao ser Assembler (ou mais baixo ainda, opcodes). Quer a linguagem seja interpretada ou compilada, desque que tenha um binário (.exe), este vai ter sempre o código assembler corresponde a _toda_ a aplicação compilada!

O objectivo é recuperar o código do programa e não o código que suporta o código do programa. Não faz sentido neste caso reverter o código de criação de janelas por exemplo, esse faz parte do Windows e é apenas chamado pelo programa.

Podes ter um 'Hello world' em C com uma dezena de K's e o mesmo 'Hello world' em VB com seis centenas de K's ora se o resultado final é o mesmo porque é que o VB tem tanto código ? É da linguagem ou do encapsulamento.

O primeiro VB a sair era segundo me lembro era interpretado. A possibilidade de criar um EXE (muito prático para distribuir) não passava de encapsular o código num ambiente de execução próprio. Daí o tamanho brutal dos programas executáveis aos quais ainda era somado o tamanho do VBRUNxxx.DLL. (comparativamente ao resultado 'Hello world')

Quanto ao BASIC ser interpretado e o C ser compilado parecem ser dois erros quando se fala de .NET framework.

[r3pek]

Como dizes não existe tal tipo de programas.

Claro que existem.

Hás de me dizer onde (para VB)? Conheço software que consegue fazer qq coisa mas para C, mas o binário (.exe) não pode ser muito complicado e é _muito_ bem pago!!

É curioso como alguém pode dizer que não existe algo de tão simples como utilizar um conjunto 'conhecido' de regras e aplica-las ao contrário. Ora verifica lá isto Decompiler Round-Up, Regenerating Your Code

1º que nd, não é assim nao simples converter um 10/15 instruções assembler para um if em C/VB/java/whatever. Ha muitas considerações a ter em conta e nunca se vai ter um resultado igual ao original (nomes de variaveis eskece). A unica coisa que um gajo tira disso é a lógica... (o que normalmente é o k se ker)

Por ex: tendo uma linguagem C -> OBJ -> EXE -> Assembly (ou OBJ) -> C. Agora é só comparar com o original.

Visto que o Basic é interpretado ou précompilado não existe a passagem a código máquina, existem sim protecções ao código (ténues) e alguma optimização.
Assim: BASIC -> pseudocódigo -> encapsulamento -> EXE -> desencapsulamento -> pseudocódigo -> BASIC

Onde é k isto é verdade?! Um processador não sabe executar mais nd a nao ser Assembler (ou mais baixo ainda, opcodes). Quer a linguagem seja interpretada ou compilada, desque que tenha um binário (.exe), este vai ter sempre o código assembler corresponde a _toda_ a aplicação compilada!

O objectivo é recuperar o código do programa e não o código que suporta o código do programa. Não faz sentido neste caso reverter o código de criação de janelas por exemplo, esse faz parte do Windows e é apenas chamado pelo programa.

Podes ter um 'Hello world' em C com uma dezena de K's e o mesmo 'Hello world' em VB com seis centenas de K's ora se o resultado final é o mesmo porque é que o VB tem tanto código ? É da linguagem ou do encapsulamento.

O primeiro VB a sair era segundo me lembro era interpretado. A possibilidade de criar um EXE (muito prático para distribuir) não passava de encapsular o código num ambiente de execução próprio. Daí o tamanho brutal dos programas executáveis aos quais ainda era somado o tamanho do VBRUNxxx.DLL. (comparativamente ao resultado 'Hello world')

Quanto ao BASIC ser interpretado e o C ser compilado parecem ser dois erros quando se fala de .NET framework.

O código que gera as janelas, cm tu dizes, não é um encapsulamento para o codigo k tu escreveste. Esse codigo é todo gerado, compilado, linkado (com as dll's e afins) e por fim gerado o executavel com esse codigo. Ele não funciona meramente como uma maneira de encapsular o código... ele _é_ o código. A unica coisa que as linguagens "visuais" fazem é abreviar a criação desse código. Tu não tens que o escrever, mas ele é gerado e posto no .exe da mesma maneira que todo o código k tu escreveste.

[xirix]

Pessoal não comecem em discussões em off-topic. Para .NET e JAVA existem programas desse tipo muito eficientes (em .NET saca até os comentários do código, JAVA não sei). Para outras linguagens que não se baseem em bytecodes/IL, etc é mais dificil, mas não foi isso que o creative perguntou né pessoal???


Abraços