Retriving source code from a exe file which was developed in visual basic 6
-
hi I lost my source code which was on my thumd drive now is it possible to get the source code from the exe file which is only pcs left from my project on my desktop. If so can someone please help Thank you :confused: steve Haris
You can NOT retrieve the source code from a Visual Basic 6 application, because it is converted into machine language (unlike .NET EXE which is reversable since it is interpreted by the CLR). The most you can get out of a VB 6 application is what they call a semi-decompile, which is the actual form elements (like textbox, combo, etc) using an application such as this one: http://www.decompiler-vb.net/[^]
Pete Soheil DigiOz Multimedia http://www.digioz.com
-
You can NOT retrieve the source code from a Visual Basic 6 application, because it is converted into machine language (unlike .NET EXE which is reversable since it is interpreted by the CLR). The most you can get out of a VB 6 application is what they call a semi-decompile, which is the actual form elements (like textbox, combo, etc) using an application such as this one: http://www.decompiler-vb.net/[^]
Pete Soheil DigiOz Multimedia http://www.digioz.com
if I had an app which was developed in vb.net and does similar function would i be able to get the source code out of it like actuall function etc.... I was able to get the funtions name and stuff but not the way the function was written ?? if so could you please shade some light in how to archive that goal thanks
-
if I had an app which was developed in vb.net and does similar function would i be able to get the source code out of it like actuall function etc.... I was able to get the funtions name and stuff but not the way the function was written ?? if so could you please shade some light in how to archive that goal thanks
S.Haris wrote:
if I had an app which was developed in vb.net and does similar function would i be able to get the source code out of it like actuall function etc.... I was able to get the funtions name and stuff but not the way the function was written ?? if so could you please shade some light in how to archive that goal thanks
Hi, Assuming that the .NET application has not been Obfuscated, you can get all the code, including functions, classes and form elements (100% of the code) back. One of my favorite .NET decompilers is Dis#, which will can give you back C# or VB.NET code out of .NET exe or dll (depending on which one you choose). It can be downloaded here: http://www.netdecompiler.com/[^]
Pete Soheil DigiOz Multimedia http://www.digioz.com
-
S.Haris wrote:
if I had an app which was developed in vb.net and does similar function would i be able to get the source code out of it like actuall function etc.... I was able to get the funtions name and stuff but not the way the function was written ?? if so could you please shade some light in how to archive that goal thanks
Hi, Assuming that the .NET application has not been Obfuscated, you can get all the code, including functions, classes and form elements (100% of the code) back. One of my favorite .NET decompilers is Dis#, which will can give you back C# or VB.NET code out of .NET exe or dll (depending on which one you choose). It can be downloaded here: http://www.netdecompiler.com/[^]
Pete Soheil DigiOz Multimedia http://www.digioz.com
-
as far as i know i dont think its been Obfuscated but on second hand how could i bee sure thats it has not been is there any way to tell if so can you please shade some light I I dont mean to be a compelet Leacher... Sorry If I am being one...
S.Haris wrote:
as far as i know i dont think its been Obfuscated but on second hand how could i bee sure thats it has not been is there any way to tell
Download the trial version of Dis# software and try to open it. If it opens it without a problem it means its not Obfuscated.
Pete Soheil DigiOz Multimedia http://www.digioz.com
-
S.Haris wrote:
if I had an app which was developed in vb.net and does similar function would i be able to get the source code out of it like actuall function etc.... I was able to get the funtions name and stuff but not the way the function was written ?? if so could you please shade some light in how to archive that goal thanks
Hi, Assuming that the .NET application has not been Obfuscated, you can get all the code, including functions, classes and form elements (100% of the code) back. One of my favorite .NET decompilers is Dis#, which will can give you back C# or VB.NET code out of .NET exe or dll (depending on which one you choose). It can be downloaded here: http://www.netdecompiler.com/[^]
Pete Soheil DigiOz Multimedia http://www.digioz.com
DigiOz Multimedia wrote:
Assuming that the .NET application has not been Obfuscated, you can get all the code, including functions, classes and form elements (100% of the code) back.
Does that include comments and #ifdef'ed out sections? What reason exists for throwing all the source code into an executable? What purpose does it serve?
-
DigiOz Multimedia wrote:
Assuming that the .NET application has not been Obfuscated, you can get all the code, including functions, classes and form elements (100% of the code) back.
Does that include comments and #ifdef'ed out sections? What reason exists for throwing all the source code into an executable? What purpose does it serve?
supercat9 wrote:
Does that include comments and #ifdef'ed out sections?
You get the equivalent of the original code back. I don't believe you can get the comments back though, because the CLR just ignores those. Not sure about #ifdef.
supercat9 wrote:
What reason exists for throwing all the source code into an executable? What purpose does it serve?
You don't throw the source code into the executable, the source code is used to compile the executable. :laugh:
Pete Soheil DigiOz Multimedia http://www.digioz.com
-
DigiOz Multimedia wrote:
Assuming that the .NET application has not been Obfuscated, you can get all the code, including functions, classes and form elements (100% of the code) back.
Does that include comments and #ifdef'ed out sections? What reason exists for throwing all the source code into an executable? What purpose does it serve?
Hi, in general a decompiler returns a synthetic source code that, when compiled again, results in the same EXE/DLL. It will not include parts the compiler did not need, such as comments, code snippets ignored by preprocessing, redundant statements, etc. And it will not necesserally look like the original: - variable names may be fictitious (local variable names typically are not present in EXE); - program flow control may look different (for, while, ...) but will be equivalent - the optimization may have moved lines around; etc. A .NET decompile will resemble the original much closer, since there is a lot of metadata in the assemblies; decompiling a debug build may look very similar to the original, except for the comments. In fact, compile then decompile is one way to translate a source file to another programming language (e.g. VB.NET to C#), again loosing comments. :)
Luc Pattyn [Forum Guidelines] [My Articles]
this months tips: - before you ask a question here, search CodeProject, then Google - the quality and detail of your question reflects on the effectiveness of the help you are likely to get - use PRE tags to preserve formatting when showing multi-line code snippets
-
as far as i know i dont think its been Obfuscated but on second hand how could i bee sure thats it has not been is there any way to tell if so can you please shade some light I I dont mean to be a compelet Leacher... Sorry If I am being one...
You could always try using the suggested tool and see if it successfully completes and produces usable code.. Michael Davey
biproject.com rss and blog news in a more palatable format!
-
You could always try using the suggested tool and see if it successfully completes and produces usable code.. Michael Davey
biproject.com rss and blog news in a more palatable format!
Apologies.. didn't see that the conversation had gone over the page! Michael Davey
biproject.com rss and blog news in a more palatable format!
-
Hi, in general a decompiler returns a synthetic source code that, when compiled again, results in the same EXE/DLL. It will not include parts the compiler did not need, such as comments, code snippets ignored by preprocessing, redundant statements, etc. And it will not necesserally look like the original: - variable names may be fictitious (local variable names typically are not present in EXE); - program flow control may look different (for, while, ...) but will be equivalent - the optimization may have moved lines around; etc. A .NET decompile will resemble the original much closer, since there is a lot of metadata in the assemblies; decompiling a debug build may look very similar to the original, except for the comments. In fact, compile then decompile is one way to translate a source file to another programming language (e.g. VB.NET to C#), again loosing comments. :)
Luc Pattyn [Forum Guidelines] [My Articles]
this months tips: - before you ask a question here, search CodeProject, then Google - the quality and detail of your question reflects on the effectiveness of the help you are likely to get - use PRE tags to preserve formatting when showing multi-line code snippets
A .NET decompile will resemble the original much closer, since there is a lot of metadata in the assemblies; decompiling a debug build may look very similar to the original, except for the comments.
Okay, that makes sense. So it's not really storing the source--just enough information to figure out what the code is up to, plus (if debug information is enabled) a full symbol table. BTW, why did compilers get in the habit of throwing debug information into a .EXE file? When debugging one could just as easily have the information in another file, and when not debugging it's not only useless bloat but it may also undermine any secrets stored within the application.
-
A .NET decompile will resemble the original much closer, since there is a lot of metadata in the assemblies; decompiling a debug build may look very similar to the original, except for the comments.
Okay, that makes sense. So it's not really storing the source--just enough information to figure out what the code is up to, plus (if debug information is enabled) a full symbol table. BTW, why did compilers get in the habit of throwing debug information into a .EXE file? When debugging one could just as easily have the information in another file, and when not debugging it's not only useless bloat but it may also undermine any secrets stored within the application.
supercat9 wrote:
why did compilers get in the habit of throwing debug information into a .EXE file? When debugging one could just as easily have the information in another file, and when not debugging it's not only useless bloat but it may also undermine any secrets stored within the application.
A lot of development systems (such as Visual Studio) give you a choice (Debug/Release, several switches) about the amount of debug info in an EXE/DLL. They typically use extra files (.PDB) for symbol definitions, and only use source files for showing the current file/function/line. Needing/wanting all these files is fine on the development machine, it is troublesome on other machines where early testing shows some problems (files missing, files out of sync, ...). In .NET more info must be present in the EXE/DLL because of reflection: by default one can interrogate an assembly as to what classes, fields, methods it is holding. Obfuscating hides that information and would disable reflection, except for the names that are specially flagged for this purpose. :)
Luc Pattyn [Forum Guidelines] [My Articles]
this months tips: - before you ask a question here, search CodeProject, then Google - the quality and detail of your question reflects on the effectiveness of the help you are likely to get - use PRE tags to preserve formatting when showing multi-line code snippets