Re: Question regarding "The Shellcoder's Handbook"

[Nicolas Waisman <nicolas () immunitysec com>]

Hey,
  I didn't have the chance to read book (I should publicly ask my boss 
for it), but anyways, the FreeList[0] entry is a special entry where 
chunk between MAXIUM_FREELIST and Decommit Threshold. So, unless someone 
explain something before (i just read the phrase out of context), 
doesn't make much sense

Cheers
Nico
Immunity, Inc
On Fri, Jun 03, 2005 at 09:50:54AM -0700, Avri wrote:
> yes, the question was regarding the 260 bytes...
>
> Since FreeList[] has 128 entries -
> FreeList[1] used for 8 bytes allocation size,
> FreeList[2] used for 16 bytes allocation size,
> .
> .
> .
> FreeList[127] used for 1016 bytes allocation size.
>
> FreeList[0] would be used for allocations 1024 and above.
>
> Therefore 260 bytes - which are 32.5 (rounded up == 33) * 8, should
> use the dedicated FreeList[33].
>
> Thanks,
> Avri
> On 6/3/05, Andrew R. Reiter <arr () watson org> wrote:
> > Hi Avri,
> >
> > On Thu, 2 Jun 2005, Avri wrote:
> >
> > :Hello Dave,
> > :
> > :"In the event of an allocation (by a call to RtlAllocateHeap asking
> > :for 260 bytes of memory, for example) the FreeList[0].Flink and
> > :FreeList[0].Blink pointers are updated to point to the next free block
> > :that will be allocated"
> > :
> > :Could you please explain why FreeList[0] gets updated?
> > :
> >
> > I don't mean to say I am any sort of expert on NT's crazed heap management
> > system, nor an expert on "correct" (hah, correct) heap management systems,
> > but from what experience I do have on implementing my own, I would have to
> > say that they probably do this for possibly a number of reasons, but I
> > figure it's due to the fact that they keep look aside lists to help
> > improve heap allocation performance.  There are list_s_ to help suport
> > multithreaded programming -- the idea of being able to allocate an object
> > out of the heap without the heap manager having to hold a lock (mutex, et
> > al) on the list of free objects.  I assume FreeList[0] is for the parent
> > process/thread; possibly if another thread was created, FreeList[n] would
> > be used in that thread.  But the idea for the FreeList[] being updated is
> > that they keep a cache of chunks of memory ready for use.  When a
> > proc/thread allocates a block of memory and the heap manager deems that a
> > "chunk of memory" is now either no longer able to share itself (ie., give
> > up more memory to another allocation -- that is, it meets some pre-defined
> > low watermark), then the manager says "ok, we need to get to the next best
> > free chunk of memory that can be used, hence the updating of pointers.
> >
> > Many times in systems like this, they also provide the functionality where
> > if that FreeList contains only N chunk (of memory) objects, and N meets
> > yet another low watermark, it will allocate more chunks from another area
> > (acquiring the global lock on the heap) and insert them intot he FreeList
> > to, once again, help out in speed of heap allocation.
> >
> > Don't hold me to this :-)  I've done a thread safe implementation of a
> > "zone" like allocator for userland and done a similar system with
> > per-thread FreeList's and "in use" lists to speed things up... so it kind
> > of makes sense to me.
> >
> > However, if the question was more towards "why 260 bytes?" then, I can't
> > help :-)
> >
> > Cheers,
> > Andrew
> >
> >  --
> > Andrew R. Reiter
> > arr () watson org
> _______________________________________________
> Dailydave mailing list
> Dailydave () lists immunitysec com
> https://lists.immunitysec.com/mailman/listinfo/dailydave
_______________________________________________
Dailydave mailing list
Dailydave () lists immunitysec com
https://lists.immunitysec.com/mailman/listinfo/dailydave