remote buffer overflows -- first, how is any buffer overflow remote...their all local to your code...cap the max size of any message...0xffff.
remote heap overflows -- cahce, and cap it.
remote format string -- parse and error. simple verification....or....keep it binary.
vulnerabilities -- surrender...you won't know until you know.
remote memory leak -- what is a remote memory leak?
DoS vulnerabilities -- buy a fancy router
logic errors -- sho-ga-nai...this is called programming.
c -- if you write in C. you're hard-core...otherwise...pick your pletera of languages.
Karl Magdsick <[EMAIL PROTECTED]> wrote:
For clarity of discussion, please be more explicit about your threat model.
I don't think the original poster was soliciting advice about
implementing DRM or some other sort of scenario where the attacker is
assumed to be able to execute arbitrary code in the address space of
the application in question.
Presumably, the poster was asking about preventing remote buffer
overflows, remote heap overflows, remote format string
vulnerabilities, remote memory leak DoS vulnerabilities, security
logic errors, &c.
On 8/15/06, Lemon Obrien <[EMAIL PROTECTED]>wrote:
>
> yeah...but with java you can easily do it...find the encryption class you
> need...or get access to the data before encryption...just by creating an
> extension of a known class and over-riding it's virtual method....its not
> hard. I've done this plenty of times with professional products like
> 'weblogic' commerce server...i wanted funtionality from a class they
> provided. Of course when you do this; you busting the warrenty...but who
> cares.
>
_______________________________________________
p2p-hackers mailing list
[email protected]
http://lists.zooko.com/mailman/listinfo/p2p-hackers
You don't get no juice unless you squeeze
Lemon Obrien, the Third.
_______________________________________________ p2p-hackers mailing list [email protected] http://lists.zooko.com/mailman/listinfo/p2p-hackers
