Re: huge array

On 2009-09-03, Eduardo <mm@xxxxxx> wrote:
Tom Shelton escribió:

A person with the right tools and knowledge can peek inside your executable
and learn enough to replicate your functionality.

Sorry, but I don't think so.


What you think is irelavent. The facts are that the disasembly tools exist.
Have done so for years. You need to be sufficiently skilled in assembly and
C, to understand the output - but, you can get usable results.

Anyway, you can always replicate the functionality of a program if you
write your own code, but it will be different for sure.


Anyone can do that.

Of course, you can also look byte by byte in the other program and after
years of study it, replicate the functionality very close, but I think
it will be easier and faster to write your own program.


You don't even have to go to that level.

And I think that the situation with dotnet exes is different.


It is to a degree. It's a lot easier by default, though there are tools that
can make it almost as difficult, if you think it's that important.

I'm not necissarily one of
them - it's been a long time since I played with assembly :)

Though, a search on google is yeilding tons of results - some even commercial
that can assembly and c source code.

They don't really decompile VB6, they just extract some information
mostly of the interface.
They can say they decompile, but that's not true.

Actaully, it's disassembly - and yes they do. The convert the binary into
assembly language (and some can reverese at least part way to c). Some have
debugers that you can attach to the process and watch as you run it. The
point is, that native code is a false protection against the determined
hacker.



The point is, that if a person cares enough, they will be able to figure out
your logic and algorithms to sufficient degree to reproduce what you are
doing. No amount of native code is going to stop that.

Sorry, it's not that easy.


I didn't say it was easy. You have to have a level of skill beyond what many
here posses. But, it can be done. Especially with the commercial tools that
have integrated debugers, etc.

Remember - they don't need your exact code (which is not what they get from a
..NET executable either), they just need to get enough to understand the
implementation (and even then only of the parts that matter) and from there
they can write their own code.

It's a bit harder with native compiled simply because different compilers
generate code in different ways. Different compilers provide different
optimizations. In fact, the one free disassembler I downloaded today, has
profiles for a bunch of well known compilers. So, if you know what generated
the exe it's even easier to get back to something resembling working code.

Just look the questions and answers here in the newsgroup and you can
realize that not everybody knows how to to everything (in fact, nobody
does).

If you mean that looking to the assembly and running step by step they
will figure your code, well, may be some things, but others things will
be very hard to figure.

The point is:

If I spend one year working in a program, with VB6 I can more or less
rely that other person will have to spend more than twice that time
looking at the assembly to reproduce my original code.


Not even close. A lot of your code isn't what a hacker is going to really
core about. Generally, they are only going to care about the small percentage
that makes up the core logic.

But if it's decompilable easier, he'll have to run a couple of utilities
and spend a couple of weeks to have the code working.


You act is if every line of your code is important. I guarentee you it is
not. In fact most of the code in any given application is going to be able to
be reproduced just by seeing what it does.

The problem is not that person to have your code, the problem is if he
post the code on internet. It's your work and your livelihood.

It is an important thing, not a minor issue.

Minor issue. There is very little that a skilled developer can't reproduce -
and that's without actually looking at your code. The only things that maybe
difficult is if you have some nifty proprietary algorithm - and I can tell you
right now if they have a good working knowledge of assembly and a couple of
tools it isnt' going to take them long to figure that out either.

--
Tom Shelton
.

Relevant Pages

  • Re: huge array
    ... years of study it, replicate the functionality very close, but I think it will be easier and faster to write your own program. ... It's a bit harder with native compiled simply because different compilers ... If I spend one year working in a program, with VB6 I can more or less rely that other person will have to spend more than twice that time looking at the assembly to reproduce my original code. ...
    (microsoft.public.vb.general.discussion)
  • Re: huge array
    ... and learn enough to replicate your functionality. ... It's a bit harder with native compiled simply because different compilers ... looking at the assembly to reproduce my original code. ... What you say is just your opinion, your fantasy. ...
    (microsoft.public.vb.general.discussion)
  • Re: Phantom Build Errors in Task List
    ... > Thanks for your response. ... Creating a very simple sample does not replicate the problem. ... > Scott Simms. ... Could you post a simple project which is able to reproduce the ...
    (microsoft.public.vsnet.debugging)
  • RE: Phantom Build Errors in Task List
    ... Creating a very simple sample does not replicate the problem. ... Scott Simms. ... changing code in an inherited form ... Could you post a simple project which is able to reproduce the problem? ...
    (microsoft.public.vsnet.debugging)
  • Re: Newbie Question
    ... different machine code for a wide range of different machines and CPU's. ... particular platform. ... > Do different CPU chips provide different functionality that you must ... Do compilers interpret the same way? ...
    (comp.lang.cpp)
Loading