[Dailydave] (windows is vulnerable too) & final comments on naming

[Dave Aitel]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

You can find some funny bugs in your debuggers when you're mapping 0.
Most of them (Olly/ImmDBG at least) will refuse to view the memory
section, but if you force them to view address 1, they'll see the data
there. I happen to be porting a kernel exploit from C to Python/MOSDEF
right now which uses this trick. :>

- -dave
(I'm sure ImmDBG will be fixed shortly. )


intropy wrote:
> On 3/7/07, Brad Spengler <spender at grsecurity.net> wrote:
>> What version of Windows are you using?  Maybe you're getting
>> confused with the behavior that giving a NULL address as a hint
>> to any allocation/mapping function is a special case within the
>> OS to select its own address.  Luckily though, the address passed
>> in is rounded down internally, so giving an address of 1 will let
>> you allocate at the 0 address.
>
> Microsoft's own driver verifier does this to trap NULL derefs when
> exercising code.  In the dc2 application specifying /n will map the
>  0x0 page.
>
> "/n      Map zero page so that NULL pointer de-references don't
> raise"
>
> And its done just like you.
>
> 45C push    4 460 push    3000h 464 lea     ecx, [ebp+var_1C] 464
> push    ecx 468 push    1 46C lea     edx, [ebp+var_14] 46C push
> edx 470 push    0FFFFFFFFh 474 call    ds:NtAllocateVirtualMemory
> _______________________________________________ Dailydave mailing
> list Dailydave at lists.immunitysec.com
> http://lists.immunitysec.com/mailman/listinfo/dailydave

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.6 (GNU/Linux)

iD8DBQFF7xzMB8JNm+PA+iURArOVAJ0ZVTXe2+b2lf2euwEGaHLb+DIR6gCfca1Y
eziDI9714wjFfhK94lSqD7I=
=ODKb
-----END PGP SIGNATURE-----