[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <AANLkTikrAl4g0D8s03epazhIJMNNjt00kSka5VOAByxs@mail.gmail.com>
Date: Sat, 17 Jul 2010 17:06:38 -0700
From: coderman <coderman@...il.com>
To: Dan Kaminsky <dan@...para.com>
Cc: "full-disclosure@...ts.grok.org.uk" <full-disclosure@...ts.grok.org.uk>
Subject: Re: In-band signalling (was: Re: NuralStorm
Webmail Multiple Vulnerabilities)
On Sat, Jul 17, 2010 at 3:31 PM, Dan Kaminsky <dan@...para.com> wrote:
> ...
> And nobody tunnels like telephony guys. If they ain't encapsulating,
> they ain't living.
are you making fun of my ATM AAL5 VBR IPoATM bearer established via
AAL2 VBR SSCOP out-of-band-and-works-fine-thanks signaling channel?
... it's just a little misunderstood.
> ...
> I'm having some good experiences with protocols that move around
> Base64-encoded blocks. The key is to not encrypt the block, because
> man, you're never finding the key during debug. Even then, it's being
> an interesting challenge to make standard tools unpack for debugging.
replay debugging with a virtual machine monitor is a great tool in
this regard. it is also indispensable when tracking down race
conditions or other intermittent failures.
just replay to desired pre-fail point and inspect execution from host,
easily extracting keys or other memory structures and altering state
with jump to "live"*.
best regards,
* with "live" being sort-of like a true resume at execution point.
network sockets, timers, and other aspects of runtime state cannot be
replicated in such a manner, but otherwise, this capability works
nicely.
_______________________________________________
Full-Disclosure - We believe in it.
Charter: http://lists.grok.org.uk/full-disclosure-charter.html
Hosted and sponsored by Secunia - http://secunia.com/
Powered by blists - more mailing lists