I see it as the same problem of when to accept button input. In my view having the button give "ample warning a material change is about to happen" is making the button do something more than "one job." But maybe you're right if your point is that if you're showing a button it should do the work it says it will do.
They are both about when it is best to accept user input. In the specific example with rotating images nothing covers or moves the buttons so it is not relevant. My impression of the article was that the buttons one job was to accept input always, my argument is that there are times it's okay to not accept input, for example the short time after certain layout changes
It's not so simple. There are times where you intend to tap one thing and something else appears underneath your finger instantaneously. So sometimes while rendering a layout you want to stop accepting input.
Yeah :/ that’s how I read it too. It would make more sense if they motivated the reason to find libc because like you said you could likely just use the non aslr gadgets exclusively. I think the author tried to use non aslr gadgets but had issues so went to the approach of using the GOT libc address and called that approach “bypassing ASLR”.
It’s a matter of opinion I guess. In the early days of ASLR it was common to look for modules that were not position independent for your ROP chain and that process was probably called bypassing aslr. These days we’d probably just call that not being protected by aslr.
Good job. It’s early 2000s level stuff but it’s still exciting when it’s happening on your desk. There are lots of options in this scenario outside of bypassing ASLR so I do find it odd to be the main feature of the title, but a fun read nonetheless.
It’s fun working on targets with a less established research history. And I love a soup to nuts writeup, Thanks.
This is exactly my problem with LLM C code, lack of confidence. On the other hand, when my projects get big enough to the point where I cannot keep the code base generally loaded into my brains cache they eventually get to the point where my confidence comes from extensive testing regardless. So maybe it's not such a bad approach.
I do think that LLM C code if made with great testing tooling in concert has great promise.
This is why I love C. You can build these guard rails at exactly the right level for you. You can build them all the way up to CPython and do garbage collection and constant bounds checking. Or keep them at just raw pointer math. And everywhere in between. I like your approach. The downside being that there are probably 100,000+ bespoke implementations of similar guard rails where python users for example all get them for free.
It's funny the author says this was 90% written without AI, and that AI was mostly used for the json code. I think they're just new to C.
Trust me I love C. Probably over 90% of my lifetime code has been written in C. But python newbies don't get their web frameworks stack smashed. That's kind of nice.
It's interesting to hear these takes. I've never had problems catching unsigned wrap bugs with plain old memory sanitizers, though I must admit to not having a lot of experience with ubsan in particular. Maybe I should use it more.
I agree that it reads really well which is why I was also surprised the quality is not high when I looked deeper. The author claims to have only used AI for the json code, so your conclusion may be off, it could just be a novice doing novice things.
I suppose I was just surprised to find this code promoted in my feed when it's not up to snuff. And I'm not hating, I do in fact love the project idea.