full-disclosure - Re: [full disclosure] agile hacking?

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Date: Wed, 19 Mar 2008 14:42:55 -0500
From: reepex <reepex@...il.com>
To: Valdis.Kletnieks@...edu, full-disclosure@...ts.grok.org.uk, 
	"Petko D. Petkov" <pdp.gnucitizen@...glemail.com>
Subject: Re: [full disclosure] agile hacking?

I think this post sums up best the problem with the hacking exposed series
and the direction pdp's book is going.  Hacking exposed does not explain
anything it only teaches tools and results.  I much prefer books like
'hacking the art of exploitation', 'the art of software security
assessment', and 'secrets of reverse engineering' because they are tool
agnostic and teach the low level concepts that are going on. If I was hiring
people I would much rather someone who understand the details of how
something worked then someone who can only rely on tools and scripts.

Publishing these books only hurts the 'community' by breeding more kiddies
who rely on tools to do everything for them.


On Wed, Mar 19, 2008 at 1:35 PM, <Valdis.Kletnieks@...edu> wrote:

> On Wed, 19 Mar 2008 17:30:08 -0000, "Petko D. Petkov" said:
>
> > moreover, the project is not a Phrack knock-off as you said. It is
> > very different. As I said, it wont contain explanations but like hands
> > on tips/tricks and techniques even the most knowledgeable can learn
> > from or use as a base reference.
>
> Without an explanation of *why* a given tip/trick works, it's hard to
> learn from.
>
> For example, consider the question of "Tell me how many processes called
> 'xyzzy' are running on a system.  The naive answer is:
>
> % ps ax | grep xyzzy | wc -l
>
> However, that generates an off-by-one error because it catches the grep
> itself.
>
> % ps ax | grep '[x]yzzy' | wc -l
>
> Does what you wanted - but without an understanding of *why* that regexp
> doesn't match itself when the first example does, you can't apply the more
> general concept of regexps that do/don't match themselves to *other* uses.
> (The secret here - the second regexp is *effectively* identical to the
> first,
> but says "look for an x next to a y" in a way that doesn't itself have an
> x adjacent to a y).
>
> So you need an explanation.
>
> (The fact that a process can re-write its argv[0] and change the name
> displayed
> by ps is yet another "teachable moment" - does that mean that you really
> want
> the name it was invoked under and should add the 'ps' flag that gives
> that, or
> do you really want the number of processes that have that modified argv
> value
> set?  For instance, if you're using 'sendmail', there are a number of
> states
> a given copy can be in, and you can do a status summary by counting the
> number
> of 'accepting connections', 'rejecting connections', 'running queue' and
> other
> similar indicators.
>
> But again, you need an explanation.
>
> _______________________________________________
> Full-Disclosure - We believe in it.
> Charter: http://lists.grok.org.uk/full-disclosure-charter.html
> Hosted and sponsored by Secunia - http://secunia.com/
>

Content of type "text/html" skipped

_______________________________________________
Full-Disclosure - We believe in it.
Charter: http://lists.grok.org.uk/full-disclosure-charter.html
Hosted and sponsored by Secunia - http://secunia.com/