From 999d7fe2ceb29fde3a534b298e1648b22bbc7e74 Mon Sep 17 00:00:00 2001 From: Davide Guerri Date: Tue, 3 Sep 2024 09:34:01 +0200 Subject: [PATCH] fix typos --- _posts/2024-09-02-one-byte-challenge.md | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/_posts/2024-09-02-one-byte-challenge.md b/_posts/2024-09-02-one-byte-challenge.md index 452a62f..19e1891 100644 --- a/_posts/2024-09-02-one-byte-challenge.md +++ b/_posts/2024-09-02-one-byte-challenge.md @@ -194,7 +194,7 @@ chunk_03 = malloc() # Spacer chunk chunk_vt = malloc() # This will be our fake vtable. ``` -Leveraging the off-by-one bug, we resize `chunk_01` from `0x60` to `0xc0` bytes (`0xc0,` as we need to account for the `prev_inuse` flag). +Leveraging the off-by-one bug, we resize `chunk_01` from `0x60` to `0xc0` bytes (`0xc1`, as we need to account for the `prev_inuse` flag). ```python # Create a fake 0xc0 bytes chunk @@ -450,4 +450,4 @@ For the curious, we could get `0x7X` bytes chunks in the corresponding fastbin, 3. allocating 2 `0x60` chunk, and receiving for the second allocation the `0x70` by exhaustion of a reminder chunk; 4. freeing the `0x70` chunk. -Unfortunately, since malloc always allocates only by exact size match from fastbins, there is no way we can claim that memory back to follow the `fd` pointers and get the target memory region on the heap or GLibC. \ No newline at end of file +Unfortunately, since malloc always allocates only by exact size match from fastbins, there is no way we can claim that memory back to follow the `fd` pointers and get the target memory region on the heap or GLibC.