Understanding and Recreating a VB6 Binary
-
Decompiling a VB6 DLL is best left to Chuck Norris, but I have a VB6 DLL from a vendor that is out of business, that was legitimately licensed etc. I would like to discover basic functionality and algorithms in this DLL, which at worst boils down to plain disassembling it and getting my fingers dirty debugging the assembly code. Are there any intermediate steps I can take to lessen the pain? VB Decompiler[^] Pro looks promising as an aid. Anything else, or just advice for someone really willing to go the distance to get my client operational again.
-
Decompiling a VB6 DLL is best left to Chuck Norris, but I have a VB6 DLL from a vendor that is out of business, that was legitimately licensed etc. I would like to discover basic functionality and algorithms in this DLL, which at worst boils down to plain disassembling it and getting my fingers dirty debugging the assembly code. Are there any intermediate steps I can take to lessen the pain? VB Decompiler[^] Pro looks promising as an aid. Anything else, or just advice for someone really willing to go the distance to get my client operational again.
Nope, you've pretty much found the only tool that's going to help you do this. Even so, be prepared for a lot of pain and fixing up the code so it makes sense along the line of what you think the code was supposed to be doing. No, it's not a perfect decompile and nothing is going to be since VB6 compiled down to native code, there's really no way to acurratly reverse it back into such a high level langauge.
A guide to posting questions on CodeProject[^]
Dave Kreskowiak Microsoft MVP Visual Developer - Visual Basic
2006, 2007, 2008 -
Nope, you've pretty much found the only tool that's going to help you do this. Even so, be prepared for a lot of pain and fixing up the code so it makes sense along the line of what you think the code was supposed to be doing. No, it's not a perfect decompile and nothing is going to be since VB6 compiled down to native code, there's really no way to acurratly reverse it back into such a high level langauge.
A guide to posting questions on CodeProject[^]
Dave Kreskowiak Microsoft MVP Visual Developer - Visual Basic
2006, 2007, 2008Dave Kreskowiak wrote:
you've pretty much found the only tool that's going to help you do this
No, the one I mentioned gave me the message, "This program compiled with unknown compiler. This decompiler can't help you." Looks like PE Explorer is going to be more useful. I don't need a full decompiler - I'm willing to explore plain old assembly, if I can find guidance on doing that. I understand pure assembly, but I need some resources on the structures etc. of Win32 DLL's.
-
Dave Kreskowiak wrote:
you've pretty much found the only tool that's going to help you do this
No, the one I mentioned gave me the message, "This program compiled with unknown compiler. This decompiler can't help you." Looks like PE Explorer is going to be more useful. I don't need a full decompiler - I'm willing to explore plain old assembly, if I can find guidance on doing that. I understand pure assembly, but I need some resources on the structures etc. of Win32 DLL's.
Couple of old hackers tool that may help. This one is no longer developed but apparently still available - W32DASM 8.94[^]. And then there is this one IDA Pro Disassembler[^].
-
Decompiling a VB6 DLL is best left to Chuck Norris, but I have a VB6 DLL from a vendor that is out of business, that was legitimately licensed etc. I would like to discover basic functionality and algorithms in this DLL, which at worst boils down to plain disassembling it and getting my fingers dirty debugging the assembly code. Are there any intermediate steps I can take to lessen the pain? VB Decompiler[^] Pro looks promising as an aid. Anything else, or just advice for someone really willing to go the distance to get my client operational again.
Can your client not just use the vb6 dll as is, even though the vendor is out of business? I've never tried to do what you're trying... but, it sounds like it could be a great source of unexpected (and worse - hidden) bugs waiting to happen. It may be worth weighing up just writing from scratch with the existing dll as something to test alongside the new one you write.