ICYDK Kay 'neoeno' Lack makes nice materials (blogs, posters, videos) about file formats, analysis, crafting...
Ex: https://www.0de5.net/stimuli/a-reintroduction-to-programming/memory/binary-formats-through-bitmap-images

Iconv, set the charset to RCE: Exploiting the glibc to hack the PHP engine (part 3) https://www.ambionics.io/blog/iconv-cve-2024-2961-p3

#PSA #PayPal is changing their privacy statement/terms of service starting November so that they can sell your information to merchants.

You CAN opt out, but you have to do it before they start:

Settings > Data & Privacy > Manage shared info > Personalized shopping, and toggle that shit off

ETA: this is probably country specific, due to differing privacy laws.

You can try privacy>settings>recommendations

Check replies, people have found the same toggle under a different header.

New on blog: "The perils of transition to 64-bit #time_t"

"""
In the "Overview of cross-architecture portability problems", I have dedicated a section to the problems resulting from use of #32-bit `time_t` type. This design decision, still affecting Gentoo systems using glibc, means that 32-bit applications will suddenly start failing in horrible ways in 2038: they will be getting `-1` error instead of the current time, they won't be able to `stat()` files. In one word: complete mayhem will emerge.

There is a general agreement that the way forward is to change `time_t` to a 64-bit type. Musl has already switched to that, glibc supports it as an option. A number of other distributions such as Debian have taken the leap and switched. Unfortunately, source-based distributions such as #Gentoo don't have it that easy. So we are still debating the issue and experimenting, trying to figure out a maximally safe upgrade path for our users.

Unfortunately, that's nowhere near trivial. Above all, we are talking about a breaking ABI change. It's all-or-nothing. If a library uses `time_t` in its API, everything linking to it needs to use the same type width. In this post, I'd like to explore the issue in detail — why is it so bad, and what we can do to make it safer.
"""

https://blogs.gentoo.org/mgorny/2024/09/28/the-perils-of-transition-to-64-bit-time_t/

Them: “This is not a paywall.”
Me: “whew”

Them: Provide your Email address”

Me: “that’s a payment, though. Personal information is a payment”

Analog filters, part II: let it ring

https://lcamtuf.substack.com/p/analog-filters-part-2-let-it-ring/?1

I’m happy to see that the GOV.UK Service Manual’s “Building a robust frontend using progressive enhancement” page was updated this week and made it to the top of Hacker News today. The technology industry would collectively save unimaginable quantities of time, money, energy and stress if this single page were required reading for everyone involved in building a web site. https://www.gov.uk/service-manual/technology/using-progressive-enhancement

#patchfriday on #cups #vulnerabilities

https://patchfriday.com/158/

"Sometimes, hacking is just someone spending more time on something than anyone else might reasonably expect.”

— Jerry Gamblin

40th Weekly Vuln Research newsletter is OUT NOW 📰

iOS kernel exploitation from @alfiecg_dev

Elgato hacking from @dt_db

@_tsuro bypasses CET

RCU Internals from @u1f383

Google Teams check off their OKRs

➕ Jobs and more 👇

https://blog.exploits.club/exploits-club-weekly-newsletter-40-ios-kernel-exploitation-cet-bypasses-elgato-hardware-repair-and-more/

We had a short look at the buffer overflow found by fuzzing `process_browse_data` to determine its exploitability. Conclusion: this bug alone won't give you RCE, or even an info leak.

https://bird.makeup/@evilsocket/1839394447286751430

Here's my quick and dirty PoC for the CUPS vulns. I wrote it after spotting the patches in the public CUPS repo. As always, expect CTF-quality code :D

https://github.com/RickdeJager/cupshax

https://bird.makeup/@rdjgr/1838750230218436891