>_0xFORUM
Sign in

Heap grooming writeups from CTFs vs production allocators

in Exploits8 replies1.1k views

CTF libc is not your production allocator. If you paste a CTF grooming diagram into a Windows pool thread, I will lock it.

Class notes: allocator, version, patch. Not a grooming recipe.

Refs: CVE Program

Lab / educational. Public binaries and patched classes only. Isolated VM.

// 8 REPLIES

I want the listing, not the decompiler story. «Heap grooming writeups from CTFs vs production allocators» — specifically CTF libc is not your production allocator. Vendor bump is patch Tuesday. Forgotten trees grow extra years. Pinned a comment at 0x140000ee0 in the listing.

@nexor

I want the listing, not the decompiler story. «Heap grooming writeups from CTFs vs production allocators» — specifically CTF libc is not you

You are describing a live target. Stop. Patched class only. I disagree with the tone, not the bytes. «Heap grooming writeups from CTFs vs production allocators» — specifically CTF libc is not your production allocator. If you wrap memcpy, I want the check on every path. I will +rep a listing and −rep a vibe. That is the deal.

I ran this on a licensed corpus binary. «Heap grooming writeups from CTFs vs production allocators» — specifically CTF libc is not your production allocator. OOB read is a leak until proven otherwise. In the notes, not in a PoC. Same class as the October thread, different binary.

@paulflex

I ran this on a licensed corpus binary. «Heap grooming writeups from CTFs vs production allocators» — specifically CTF libc is not your prod

Take the telegram pitch to the bin. Market listing or nothing. Agreed on the class, not on the tool. You wrote «CTF libc is not your production allocator». That is the sentence I keep. Patched class only. Hunt the old immediate. Do not ask for a trigger file. Hash of the public file, or are we arguing a shape? Same class as the October thread, different binary.

@pwned

Agreed on the class, not on the tool. You wrote «CTF libc is not your production allocator». That is the sentence I keep. Patched class only

I would have written the opposite conclusion a year ago. You wrote «CTF libc is not your production allocator». That is the sentence I keep. system() on a user path is the class. execve with argv is the patch. I reproduced it on lab build 1246.

@riskr

I would have written the opposite conclusion a year ago. You wrote «CTF libc is not your production allocator». That is the sentence I keep.

Quote the bytes or sit down. Quietly the best note on this board this month. The load-bearing line: CTF libc is not your production allocator. If the thread slides toward a live target, lock it. I will report it. I reproduced it on lab build 1023.

I dumped after OEP and then did this. «Heap grooming writeups from CTFs vs production allocators» — specifically CTF libc is not your production allocator. OOB read is a leak until proven otherwise. In the notes, not in a PoC. I will +rep a listing and −rep a vibe. That is the deal.

@sn0op

I dumped after OEP and then did this. «Heap grooming writeups from CTFs vs production allocators» — specifically CTF libc is not your produc

You are treating a checksum as a signature again. Not fully convinced yet. On «Heap grooming writeups from CTFs vs production allocators»: CTF libc is not your production allocator. A saturating add that hangs is not a complete patch. Hunt the hang too. I wrote a 12-line script and then threw it away. The listing was enough.

Sign in to reply. Guests can read reversing, pentesting, coding and greyhat threads.