Code security

[Rob Teixeira]

Since people seem to believe their code is safe(er) in VB6, despite all the
stuff that has been posted, I went and did a quick check.
In the span of a half an hour, i've downloaded a half dozen VB decompilers
and dissassemblers, and found them for VB3,4,5, and 6.
The majority work on P-Code. In some cases, you get back what looks pretty
much like the ILDasm.exe display (the .NET IL disassembler). In others, it
was scary just how much the output looked like the original code.
I looked at the VB5/6 token reference that someone posted, and with that
information, i could write my own decompiler blind-folded.
Another issue is that with the exception of one of the programs i downloaded,
the rest were not professional software. The one professional decompiler
was supposed to help companies rescue code that was lost. Someone sent me
a VERY good decompiler, but only after i emailed him several times.
So what about native code? I found nearly 15 disassemblers for Win32 PE binaries.
The output, again, is nearly identical to ILDasm.exe. Some even let you modify
the code, which is how people make cracks and introduce viruses to programs.

By the way, here's a quote from the person who developed the original decompiler
for VB3:
"VB4 programs contain no information, that can be modified or removed. That's
better than with the previous VB versions, that included most of the source
code ([[note from Rob: including some comments]]). On the other hand, there
is no (I guarantee: NO) way to protect VB4 (and following versions) executables
against a decompiler."
[snip]
"BTW, possibly I'll include VB5 token code into the disassembler, before
the redesign of the decompiler. Then both VB versions can be handled with
a single decompiler. A VB5 native code decompiler won't be more difficult,
but the handling of the executables differs significantly from handling tokenized
code."

And this guy writes honest to goodness developer tools, such as profilers
and optimizers. IOW: he's not out to steal your code. You can just imagine
what *those* people are capable of.

Which brings me back to my original point:
I found a monstrous amount of material, articles, etc. that talk about how
to secure your code. In all cases, it involves locks, encryptors, and obfuscators.
You'd be surprised how many such tools are out there for VB3-6. In essense,
nothing has changed. Someone can, at the click of a button, materialize all
the good bits of your private code.
Which leads us back to - exactly how much code is really worth locking? And
why exactly are people making such a big deal about it now, when the problem
has existed for years? And guess what - the solution is still the same.

-Rob

[Jeff Pipes]

Did you happen to find a VB1 decompiler? I have an old VB1 program but lost
the source a long time ago.

-Jeff

"Rob Teixeira" <RobTeixeira@@msn.com> wrote:
>
>Since people seem to believe their code is safe(er) in VB6, despite all
the
>stuff that has been posted, I went and did a quick check.
>In the span of a half an hour, i've downloaded a half dozen VB decompilers
>and dissassemblers, and found them for VB3,4,5, and 6.
>The majority work on P-Code. In some cases, you get back what looks pretty
>much like the ILDasm.exe display (the .NET IL disassembler). In others,
it
>was scary just how much the output looked like the original code.
>I looked at the VB5/6 token reference that someone posted, and with that
>information, i could write my own decompiler blind-folded.
>Another issue is that with the exception of one of the programs i downloaded,
>the rest were not professional software. The one professional decompiler
>was supposed to help companies rescue code that was lost. Someone sent me
>a VERY good decompiler, but only after i emailed him several times.
>So what about native code? I found nearly 15 disassemblers for Win32 PE
binaries.
>The output, again, is nearly identical to ILDasm.exe. Some even let you
modify
>the code, which is how people make cracks and introduce viruses to programs.
>
>By the way, here's a quote from the person who developed the original decompiler
>for VB3:
>"VB4 programs contain no information, that can be modified or removed. That's
>better than with the previous VB versions, that included most of the source
>code ([[note from Rob: including some comments]]). On the other hand, there
>is no (I guarantee: NO) way to protect VB4 (and following versions) executables
>against a decompiler."
>[snip]
>"BTW, possibly I'll include VB5 token code into the disassembler, before
>the redesign of the decompiler. Then both VB versions can be handled with
>a single decompiler. A VB5 native code decompiler won't be more difficult,
>but the handling of the executables differs significantly from handling
tokenized
>code."
>
>And this guy writes honest to goodness developer tools, such as profilers
>and optimizers. IOW: he's not out to steal your code. You can just imagine
>what *those* people are capable of.
>
>Which brings me back to my original point:
>I found a monstrous amount of material, articles, etc. that talk about how
>to secure your code. In all cases, it involves locks, encryptors, and obfuscators.
>You'd be surprised how many such tools are out there for VB3-6. In essense,
>nothing has changed. Someone can, at the click of a button, materialize
all
>the good bits of your private code.
>Which leads us back to - exactly how much code is really worth locking?
And
>why exactly are people making such a big deal about it now, when the problem
>has existed for years? And guess what - the solution is still the same.
>
>-Rob

[Rob Teixeira]

"Jeff Pipes" <JeffP622@msn.com> wrote:
>
>Did you happen to find a VB1 decompiler? I have an old VB1 program but lost
>the source a long time ago.
>
>-Jeff
>

Sorry, no dice
The earliest version i found was 3.
Though i have to admit that after finding what i was looking for, i gave
up searching. You might have some luck if you poke around hard enough.

-Rob

[Bob]

In article <3c03f803$1@147.208.176.211>, "Rob Teixeira"
<RobTeixeira@@msn.com> says...
<snip>
>
> Which leads us back to - exactly how much code is really worth locking? And
> why exactly are people making such a big deal about it now, when the problem
> has existed for years? And guess what - the solution is still the same.
>
> -Rob
>

In this case, ignorance may be bliss:-)

Bob

[Jonathan Allen]

> And
> why exactly are people making such a big deal about it now, when the
problem
> has existed for years?

Most people did not realize how bad things really were.


--
Jonathan Allen



"Rob Teixeira" <RobTeixeira@@msn.com> wrote in message
news:3c03f803$1@147.208.176.211...
>
> Since people seem to believe their code is safe(er) in VB6, despite all
the
> stuff that has been posted, I went and did a quick check.
> In the span of a half an hour, i've downloaded a half dozen VB decompilers
> and dissassemblers, and found them for VB3,4,5, and 6.
> The majority work on P-Code. In some cases, you get back what looks pretty
> much like the ILDasm.exe display (the .NET IL disassembler). In others, it
> was scary just how much the output looked like the original code.
> I looked at the VB5/6 token reference that someone posted, and with that
> information, i could write my own decompiler blind-folded.
> Another issue is that with the exception of one of the programs i
downloaded,
> the rest were not professional software. The one professional decompiler
> was supposed to help companies rescue code that was lost. Someone sent me
> a VERY good decompiler, but only after i emailed him several times.
> So what about native code? I found nearly 15 disassemblers for Win32 PE
binaries.
> The output, again, is nearly identical to ILDasm.exe. Some even let you
modify
> the code, which is how people make cracks and introduce viruses to
programs.
>
> By the way, here's a quote from the person who developed the original
decompiler
> for VB3:
> "VB4 programs contain no information, that can be modified or removed.
That's
> better than with the previous VB versions, that included most of the
source
> code ([[note from Rob: including some comments]]). On the other hand,
there
> is no (I guarantee: NO) way to protect VB4 (and following versions)
executables
> against a decompiler."
> [snip]
> "BTW, possibly I'll include VB5 token code into the disassembler, before
> the redesign of the decompiler. Then both VB versions can be handled with
> a single decompiler. A VB5 native code decompiler won't be more difficult,
> but the handling of the executables differs significantly from handling
tokenized
> code."
>
> And this guy writes honest to goodness developer tools, such as profilers
> and optimizers. IOW: he's not out to steal your code. You can just imagine
> what *those* people are capable of.
>
> Which brings me back to my original point:
> I found a monstrous amount of material, articles, etc. that talk about how
> to secure your code. In all cases, it involves locks, encryptors, and
obfuscators.
> You'd be surprised how many such tools are out there for VB3-6. In
essense,
> nothing has changed. Someone can, at the click of a button, materialize
all
> the good bits of your private code.
> Which leads us back to - exactly how much code is really worth locking?
And
> why exactly are people making such a big deal about it now, when the
problem
> has existed for years? And guess what - the solution is still the same.
>
> -Rob

[Dan Barclay]

On 27 Nov 2001 20:46:03 GMT, "Jeff Pipes" <JeffP622@msn.com> wrote:

>
>Did you happen to find a VB1 decompiler? I have an old VB1 program but lost
>the source a long time ago.

I haven't done this, but I think all you need to do is get a binary
editor and save the modules (you'll have to play with a few files to
figure out how to block the modules).

Like I said, your mileage may vary, but I recall looking at several
years ago and it appeared that all they did to create an EXE was save
the tokenized "project" (comments and all) behind a loader. Heck, my
guess is that you could probably suck code modules up as a binary
saved QuickBasic file <g>.

Dan

Language Stability is a *feature* I wish VB had!
(#6)