2025 02 14

    Today I read more of Smashing The Stack For Fun & Profit, & made substantial progress. Unfortunately did not manage to finish it, but I think I have regained a firm grasp on buffer overflows. After overwriting the return address of the caller stack frame alongside the parameters of the current, we can use the stack frame owning the vulnerable buffer to store shellcode. We can direct the return address we control to the start of our shell code as well. I found their shellcode execution using execve & string “\bin\sh” quite clever. I would think to define a parameter string inside the shell code, but instead they had the return address point to a jump that points to a call instruction close to the overwritten ret address that had the address of the “\bin\sh” string right after (in place of original parameters). This way, the address string is pushed onto the stack (recall function prologue action) & when redirecteed the shell code is immediately popped right back into a register to use. We do not have to finish the function prologue & just needed a convenient way to retrieve the string, so all is needed is a pop & the rest of the shell code can be whatever it can, mostly. It cleverly saves a lot of space, bringing us to the limitation (at this level) hinted that shell code is limited by the size of the stack frame, since there is only so much space left from the buffer’s offset to the return address. Remember that in addition to the stack illustrated yesterday, the exploited buffer grows as such towards the return address: [CUR SF ] (vuln buffer) ——>…(ret address) [CUR SF]. Of course, these can be remediated by techniques such as storing shell code in environment variables, but we will cross that bridge when we get there. For now, I suppose I can rejoice in relearning the basics of overflow attacks…except for one caveat. In the POC attack on xterm to gain shell with buffer overflow, the illustration showed the exploit executed before xterm. The usage of environment did not stick too well with me either. I am not unfamiliar with using environments in overflow attacks, albeit not an avid practitioner myself, but I cannot imagine how executing the exploit before the vulnerable program within the same environment runtime works. It might have to do with xterm’s inner workings, though I highly doubt it as it will make the paper too niche & detached from explaining buffer overflows. Might need to do research on my own end while finishing the book. Something I have realized here is that I should be more firm on my usage on various overflow types. I think I was mostly right in this case, but I tend to refer to most overflow attacks as buffer overflows.
    Although I wished to practice format string exploits to the level of practical use, one can only have so much time in a day. I did manage to do all the readings needed to get more than started, however, so I’m itching to get my hands dirty tomorrow. Embarassingly, I realized I only remembered how to do disclosure attacks through format string attacks, but am glad that I understand the core concepts enough to as easily comprehend the arbitrary writes portion. As printf acts like a normal function with the special trait that it can take in as many parameters as possible (thus causing this vulnerability), unsafe printf practices could use special characters to leak & write to unintended areas. For every special character occuring in the format string, printf tries to read a parameter. The stack does not demarcate what is a parameter or not, so what was not intended as a parameter is read instead, this case frequently being values from the caller’s stack frame. This is the basis of how we could perform simple disclosure attacks using mixtures of %x & %s etc. Things get interesting, however, knowing that the format string is itself, a parameter, & stored somewhere close to other function parameters. Now, this might sound bland, but is very powerful. From earlier, you could only continually read downwards the stack from your stack frame, but if you can access your format string, you can read onto yourself. Pairing an address, followed by a %x, %s, or whatever that coincides to read into that address means you can read any memory belonging to runtime. Isn’t that fantastic? Now here comes the holy grail though. %n is a unique format character that writes the amount of bytes written into console into a parameter. Are you catching on? With padding specifications paired with %xs, we can line the %n to write into an address within the format string like in the more advanced disclosure we defined earlier! This is absolutely phenomonal. However, work still is not easy, as one has to craft their format string masterfully. In addition to lining up the %ns, %xs, & addresses,bytes must optimally be sequentially writen one byte at a time. Memory addresses are big, so writing in huge paddings waste a lot of resources in order to print said bytes before writing number of printed into the parameter. Furthermore, the amount of bytes written only increases, not decreases, so you might need to account for wraparound (working out congruent values in mod 256 iirc) to write in a relatively lower value. Worst by far comes my traume through x64 format string exploits, as printfs stop at null characters. 64-bit addresses almost never not have null characters in their addresses, so it is an absolute pain to circumvent. I did solve one such challenge before, but I do not remember how. Well, at least my work seems to be cut out for me.
    I’ve finally finished the last Riddle Joker route, Nanami (I’m ignoring the Normal route that I found out afterwards, idgaf). By far the best, with a meaningful theme, better screentime balance for cast, W chara theme, W CGs, & an adorable heroine. The backstory did a lot for me imo, as it was nice seeing a not so superficial reason behind not only Nanami’s affection but her & the protagonist’s dynamic throughout the story. Similarly, the themes were the most well established & wholly resolved, making the strongest narrative in the vn. I think it owes a lot to the biased exposure to Nanami in the common route, though I’m not complaining. I really liked her character, being a loyal comrade who is cute & funny etc. I doubt there are any sane out there who can dislike her. These then culiminate to the relatively unique dynamic mentioned earlier, creating a strong repertoire with the reader (me). Her character felt raw & transparent, unlike others where I felt their portrayal was kinda contrived. The route also had the most favorited VLs & CGs for me, especially the chibi scenes where she hides under the blanket & her talking with Chiaki. I also loved her B< face, it’s so cute & funny. I did wish they expanded more on her otaku side, felt like they scrapped another heroine trait. Nevertheless, Nanami on top. I still have the Afters left to read, so I’m not actually finished yet, so I will leave the general remarks for then. Boy, I did not expect the Afters to be such a burn. Completed Chisaki’s & Mayu’s, tracing the order of route completion. Expected some chill banter after the accomplished feeling of clearing all routes, but all the Afters so far ain’t delivered. iykyk.



    Nanami, uogh.