Re: reverse engineer c or java

[za () boo ma fu (za () boo ma fu)]

Helloooo,
        Well, in some sense, I think that copy protection is valid to this
mailing list as 'crackability' is a vulnerability itself, obviously, and
the simple solution is good programming style and an advanced
understanding
of how your code works. Heh, personally, though, I don't believe that
there is such a thing as 'uncrackable' shareware. If it dumps hex it can
be cracked. This is why it is necessary to understand advanced
programming
techniques and common bugs in order to circumvent a cracker's full
under-
standing of the program. For example, what about random number
sequencing
that is involved with challenge/response authentication
programs/protocols?
Because the number generation is so randomized and unpredictable, it is
hard for a cracker to use his knowledge even if he reverse engineers the
program or has the source code. This is why session hijacking is a real
threat with protocols such as telnet but not ssh.

> Most likely the sender is intrested in copy protection, creating
> 'uncrackable' shareware etc. That's a different topic, which is more
> suitable in mailinglist etc which deals with such things.
>
> Anyway; given access to files, it is easier to create backdoored variants
> if the source code is open, or you use java (seems to be close to the same
> thing ;) But to rely upon C with none-open sourcecode is not the solution,
> because it simply makes it harder, it doesn't stop an inventive attacker
> with good programming knowledge.

        About 'backdoored variants'. If the end user isnt downloading the
client (open source or not) from its home site there is a threat of a
trojaned binary/source. Should I, as a programmer, worry about people
using my source code to make trojaned variants? I shouldn't. Why? If
someone is downloading my program from a site that is not my own and is
not authorized as a distributor it is not my liability when some warez
kiddie gets Sub7'd with a backdoored windows version of 'veggie the
encryption program'. lol! However, if I am notified of the unauthorized
distributor I will send them an email telling the person to take my
program
off the site.

> Btw, on the topic of java! Has there been published any research upon
> buffert overruns in java? I assume the class String is more or less
> secure, but are there security concerns related to usage of e.g. arrays?

        A note on buffer over-runs in Java. A buffer overrun will stop
the program execution as soon as the OutOfBounds Exception occurs in
Strings, Arrays, etc. So there is no immediate threat of putting a
0x310xdb0xb80x170xcd0x80 on the stack, heh...

> True, in most cases. Concider distributed.net who publish almost the
> entire source code to aid development, but not the validation routines
> which are used to check that client hasn't been tampered with by malicious
> users.
        A final note on what I exactly meant with my 'If you aren't secure
about releasing your program to the public open source, you didnt secure
your program' motto. That doesn't mean you have to release every program
open source, it is just a good measurement tool when finalizing your
program.
I may not release a program open source, but I will sure make certain I
know the code is safe via my motto before I release it.

Take care ;)
        initd_

initd_ () digital net
http://digital.net/~initd_