 So this is a very short explanation on how to solve the unresolved stack usage warning in binaryNinja. This is a keyword sample and this is a start function. You are already greeted with this message. You should definitely resolve this because if you don't do that, the decompilation will be wrong and you don't want that. So it's very important to get the stack pointer values right. Now the way I can deal with that is by going to the low-level iL and then you need to set the advanced show stack pointer value, which I already did here obviously. And then you get comments saying what the stack frame offset is at this current location. Furthermore I would like to switch to the graph view for that. So you may have to set this again if you're on graph view. And now you can see the stack frame offset in all of these blocks. Now you need to find where the issue with the stack pointer starts and that's here. So here are the question marks. Over that should, okay, sometimes it tells me, it doesn't seem to want to tell me what's wrong, but usually when I hover over that, no, it works, unresolved stack pointer value. So at this point, binaryNinja cannot determine what the stack pointer value is, why? Is that the case? Because there is a discrepancy between the blocks that arrive here. So we have here this block arrives here and it says minus 2b8 is the current stack frame offset whereas let's go to a different block. Here it's minus 2a0. So this is the difference of the stack pointer and why it cannot be resolved. So let's look at another one and we see here it's also minus 2a0. So just based on that, I suppose the issue is here since this is like a different value from the other blocks where it comes from. So now you start analyzing this block of code. How does this work though? Whenever you have a pub, the difference of the stack pointer is decreased and whenever you have a push, difference of the stack pointer is increased. So this value, so here you have push EAX and that means it substrates 4 because EAX is a 4 byte register. Same here, same here, same here. If there's a pub of EAX for instance, this would add 4. And the calls, that depends on the calling convention and how the registers are cleaned up obviously, but this call doesn't seem to have any adjustment at all. So there's nothing, no comment after that explaining what the ESP after the call is which is what is missing here. So for this call it's not determined how many values are being cleaned up from the stack. So that is actually the culprit here. Now how do we know what to adjust? Well firstly we know the difference of this stack frame offset versus the other blocks. So you can just use this difference, calculate that, but you can also see how many values this is using. So based on that it's 1, 2, 3, 4, 5, 6 and a 6 times 4 is 24. So we're gonna mark this call, go right click, set stack adjustment and say 24, press accept and now we see that this has been resolved. Now we have also minus 2A0 and this aligns with all of the rest. So let's go to the high level IL and that should improve the output of the disassembly considerably. If you wanna learn math analysis from the ground up then check the link in the description below. There's a link to my Udemy course for beginners. It contains 11 hours of video content and the link is a coupon link that's a little bit cheaper for you than buying it from Udemy itself. So check it out and maybe I see you there.