[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [Full-disclosure] In-band signalling (was: Re: NuralStorm Webmail Multiple Vulnerabilities)
- To: Dan Kaminsky <dan@xxxxxxxxxxx>
- Subject: Re: [Full-disclosure] In-band signalling (was: Re: NuralStorm Webmail Multiple Vulnerabilities)
- From: coderman <coderman@xxxxxxxxx>
- Date: Sat, 17 Jul 2010 17:06:38 -0700
On Sat, Jul 17, 2010 at 3:31 PM, Dan Kaminsky <dan@xxxxxxxxxxx> 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/