Jump to content
Tuts 4 You

calloc question


ToMKoL

Recommended Posts

I've got question about calloc. From what i know calloc uses two paramas - size of element & number of elements. It allocates memory of size of elements * number of elements and returns a pointer to that memory in eax. Memory allocated is filled with 0. My question is what is in four bytes before the pointer? I.e.:

push size of elements

push number of elements

call calloc

;now eax holds pointer to mem

mov edx,[eax-4] - what will be in edx

Is it totally random or is it somehow determined?

Link to comment

Going outside the documented/supported methods is 'no-mans-land' and as such there is no definitive answer to that one. Being that it allocates from the process heap, i would imagine that there would be areas marked as no-access and areas that are at least read-access, but poking around in areas you haven't allocated is interesting for reversing and sometimes not much fun for the application, your choice.

I'm not that informed when it comes to the heap, is the memory just prior to the returned pointer used for the linked list to store next and last members in the chain?

HR,

Ghandi

Edited by ghandi
Link to comment

I always figured it saves the allocated size there, but that's more of a guess.

But as Ghandi said, it's not defined and is pretty much garantueed to vary between platforms and sometimes even compilers.

Why don't you just go ahead and take a look?

This is an RE forum after all, and these kinds of problems are solved best with a debugger :)

Link to comment

I've debugged it. For first few times it's random. After few restarts of program under olly it's constant. It's definitely isn't size of allocated memory. I've found it in old crackme protection scheme. It's used to generate key check parameter.

Link to comment

Debugging it, my hwbp was triggered inside ndtll.RtlAllocateHeap. Looking in the WINE source code for ntdll (i know it isn't ms code), it was writing the size of the heap block (not allocated by the application but how big the block the memory manager is describing) and the remaining unused bytes left in the block.

Whether or not the WINE source is accurate, the memory manager does write information there which pertains to the block which follows it. On my PC, this was constant from the first debugging, but then again the returned memory was always the same pointer too though.

HR,

Ghandi

Link to comment

I must note that by memory manager, i'm not talking about a separate process or service. I simply mean the code which takes care of the allocation.

HR,

Ghandi

Link to comment

Thanks ghandi. Will need to go deeper in ntdll. On my xp sp3 this value is random for first three or four restarts under olly. After that it becomes constant. Memory address is constant for each restart of program.

Link to comment

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now
×
×
  • Create New...