Re: reverse engineer c or java

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

wooooooooo,

initd_ here again for one last post on this thread ;)

> Bluefish wrote:
>
> > standing of the program. For example, what about random number
> > sequencing
> > that is involved with challenge/response authentication
> > programs/protocols?
>
> It's may sound great on the surface, but I doubt it will be usefull in the
> end. Numerous 'inventive' approaches has failed before. It has to work on
> the computer, therefore it has to have a logic behind it. Once it is
> understood, it will be a five minute attack to crack it.

This question is for clarity for not only myself but all other
subscribers
to this list. So, you are saying, that if you understand the source code
for great programs like SSH/SSL you can create in 5 min a working attack
against these protocols? Even if you dont have the 128bit standard ssh
key
or the legitimate SSL key? I think I speak for the rest of us
./hacker(s)
when I say 'show me the Proof Of Concept'. Not to mention your resoning
behind the nonchalant attitude of changing the meaning of the word
'uncrackable'... I may just be a 21 year old kid but when someone says
something about being leet0r enough to crack some of the best encryption
algorithms in the history of open computing, I have to 'stop... drop...
shut em down, open up shop...'.

> > 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.
>
> Actually, I was more thinking about people with access to the binaries in
> use (administrators or people who has gotten write-access to the binaries
> somehow) making changes. At a singel company, not at a distributor. Open
> source / java makes it easier for such attacks.

Well, on this note, if you arent running some program on your box like
tripwire
off a readonly floppy stored back at your house or sending all logfiles
to
another boxen on your LAN that only u have access to (as a good sysadmin
should)
then this isnt an issue. Besides, if the attacker has admin access why
would he
need to backdoor a client =/

> Note that this is not a valid argument against java and/or open source,
> because the binaries could be backdoored by hexediting them, re-writing
> them (if it's a simple utility) or simply placing a backdoor frontend,
> like letting main.exe exectute main.ex_ or something like that...

/me smiles

> >       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.
>
> Yes. This is true. But there *are* situations where it isn't possible to
> do this, like with distributed.net. How do you let the public aid work
> with your system (alas, you invite malicious users as well) and expect
> their responses to be reliable if you give them the entire source code?

You aren't getting the message. My motto has to do with your confidence
in
your own code. I can totally understand distributed's point in keeping
part of the source code locked down. If they aren't asking the public to
contribute in a particular segment of code why should they post it?

> True, it would still be possible to duplicate the authentic client's
> responses by reverse-engineering the application, but at least it now is a
> task which requires more knowledge. And hopefully those who have the
> abilities to do this realises there's no reason to sabotage a public
> contest.

This isn't as simple as you make it sound. You cant guess a correct
128bit
key generated at random under certain environmental conditions just by
reverse engineering a program's code. If that was actually possible the
entire SSH project would be compromised.

I think it would benefit everyone to learn how a secure program like
ssh/ssl
works before claiming reverse engineering a program is all you need to
do in order to crack the protocol. First of all with these programs you
dont need to do any reverse engineering as ssh is released in a free
open source
form. SSL's code is available (I believe) in the Netscape source code
distros
and there is OpenSSL. Second of all simply understanding how the code
generates
keys is almost inconsequential to being able to guess the key itself
used by
a remote host which you have no authority to contact. Third, and
finally, the
mathematics that create radomized numerics generate keys without
duplication.
Grab a book from your local library/University on random number
generation and
advanced mathematics. I, personally, feel that until quantum computing
becomes
a working reality there is no need to pjeer the random number generator
cracker.
'Sneakers' was a good movie, but, I don't think there is a little black
box out
there with those capabilities. If there is, prove me wrong.

Btw, this discussion has gone on long enough ;) I'm outtie 5,000...

But, its aight...
I ain't mad at `cha...
Got nothin' but love for ya
Do yo thing, boy

initd_

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

#!0x7f > *;
127 lubb0r u...