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.
Okay I did the simulation. I don't think this strategy actually works, but I initially thought it might like you did. One such nash equillibrium my sim found was having the Ballmer player mix between picking either end of the range (not always 1 or 100 but around those numbers). I have the Ballmer player winning with around $.85-$1.00 EV per round. The resulting player strategy was to also try to start their binary search at the extreme ends of the range and hope they guessed the right side. It's kind of like the soccer penalty kick dynamic between the shooter and goalie. Goalie wants to pick the same side, shooter wants opposite sides. But with 100 choices, the goal is too wide I think.
I now think that not constraining the players remaining choices to follow binary search pattern would completely change the resulting equilibrium and improve the results for the player. But that would be more computationally demanding to calculate because there's a strategy choice for every range of choices. And also I've avoided work for 2 hours by working on this so that's not great haha. I _am_ curious what not constraining the player to binary search would do though...
Yes, this has been a trend for a little while now. For example this gist[1] gives linux boot parameters to make linux significantly faster and all it does is basically turn off all default security mitigations. I would make the distinction between vulnerabilities and "exploitable" vulnerabilities though. Mitigations usually give a runtime performance hit but don't remove the underlying flaws, it can just make it harder, or sometimes impossible, to escalate a little flaw into full blown code execution. But also know that offensive techniques advance along side defensive ones. For example ASLR was once considered the death of vulnerability research, but new methods and ideas were found and bypassing ASLR is now just part of the job. Each mitigation must be regularly evaluated against the state of the art, and against the cost to performance (and complexity, etc.). You ideally don't want to be paying performance costs when they aren't helping security.
Rust, Zig, and others, are additionally paying compile time performance costs to remove some underlying vulnerabilities. Which is interesting and probably a good thing for software.
I am this person. I work as a researcher finding 0-days.
From the employee perspective: Wages are equal. Big Tech work is less interesting (build big bug finding machines that find have high quantity of bugs) and report the bugs that sit into some bug tracker only to maybe be fixed in 3 months. Offensive security work is more interesting. It requires intimate knowledge of the systems you research, since you only need a handful and the shallow ones get found by Big Tech. You must go deep. Additionally offensive security requires the know-how to go from vulnerability to code execution. Exploitation is not an easy task. I can't explain why engineers work for companies that I deem immoral, but that's probably because they don't feel the same way as I do.
From the employer perspective: How much does the rate of X vulnerabilities per year cost me? If our code has bugs but is still considered the securest code on the market, it may not benefit the company to increase the security budget. If the company expands the security budget then which division is getting cut because of it, and what is the net result to the company health?
If you want to fix the vulnerabilities you need to make the price of finding and exploiting them higher than the people buying them can afford. And you must keep the price higher as advances in offensive security work to lower the price of finding and exploiting them. Since defensive companies don't primarily make money from preventing bugs and offensive companies do primarily make money by finding bugs, there is a mismatch. The ultimate vulnerability in a company, or any entity, is finite resources.
I love thinking with a pencil/pen compared to a keyboard since there seem to be so many more expressive possibilities: Size, Position, Drawings, Arrows, etc. Not to mention research suggesting it's better for memory.
This is a demo of making a handwritten blog but using SVG rather than images. There are advantages of this including but not limited to reducing bandwidth. This blog was made on a tablet, images of the handwriting exported to Inkscape, and SVG placed into a html wrapper. I really wish the workflow from pen, pencil, and paper to blog post was smoother.
I experimented with this approach on my blog[1]. I had an image of the handwritten blog post and used a feature in Inkscape to get SVG and make clickable text. I decided to place a little plain text in there to help Google search crawlers know what content is on the page. I really would prefer handwriting more.
My problems boil down to just that flow of the tools sucked. I didn't want to have to attach multiple pages together. Inkscape was honestly a bit clunky to work with and I didn't have any personal tools to generate the full html from the svg.
If we improve our programming languages and practices to make code bases more easily understood we will simply increase the scope of what the projects attempt to solve, not reduce their complexity. While this is a good for software it still means we’re going to be moaning about working on complex software.
It’s like how the increased economic productivity due to technology has not made the work week shorter.
If you read the resulting articles you'll find a few of them suggest that all the deaths were staged or committed by Ukrainians. Headlines like "The truth is out there..." or "Global lies..." are examples. There still are many results from mainstream western media on the other hand.
Google, in contrast, has zero results implying the deaths were staged or committed by Ukrainians.