0x0

I find it's a shame the article is absolutely littered with AI-isms, again, like another cool hack project the other day here on HN. It is incredibly jarring to read a line like "No Platform Builder, no SDK install, no CD key.".

Sounds like a cool project but I find it a bit offensive that the article author doesn't value the article reader's time enough to edit the AI-isms out.

On the other hand, trying to point this out usually results in downvotes, so maybe it's useless to complain about this trend?

Shame the article is absolutely littered with AI-isms.

I just wish Valve could add official macos-arm64 builds of the various hl2 games on Steam :-/

Just recently noticed this got posted to deb-multimedia, although I think there is a typo in the package description....

https://www.deb-multimedia.org/dists/unstable/main/binary-am...

... it says "fast and small AV1 video stream decoder"

... should probably be "AV2" ?

Details here: https://eclecticlight.co/2023/09/25/postscripts-sudden-death...

Such a shame that macOS lost all its built-in postscript support including Preview.app in recent versions :(

I find it curious to call someone dropping a weaponized root exploit before major distros or even LTS kernel git branches have patches ready "good guys". This could have been handled with much more grace.

The disclosure doesn't appear very "full". Looks like this was slipped into mainline linux among dozens of other mostly-irrelevant "CVEs" with nobody highlighting the fact that it is in fact dirty-cow-on-steroids.

https://x.com/spendergrsec/status/2049566830771970483

https://lore.kernel.org/linux-cve-announce/2026042214-CVE-20...

Or is everyone expected to upgrade and reboot every 48 hours for all eternity and just deal with potential regressions all the time?

I think this reflects poorly on the original reporters. If you have a weaponized 700-byte universal local root exploit script ready to go, perhaps you should coordinate with major distros for patches to be available before unleashing it on the world. No matter how "veteran" you are.

Dropping a public exploit on github before distros have patches available isn't very cool, or is that just how veterans roll these days?

Enumeration of the entire DNS space is not available in general, but it does appear that some TLDs offer complete zone files for legitimate research purposes, see for example https://czds.icann.org/help#zone-files

The breakout engineering to exploit Dolphin has already happened, see for example:

* https://dougallj.wordpress.com/2016/11/13/exploiting-dolphin...

* https://gist.github.com/hthh/502ae16db55612f64d3966769a154c3...

* https://github.com/dolphin-emu/dolphin/pull/4447

"they can't be provisioned by the website itself."

It's funny, we used to have a html tag that would exactly that: <keygen />

They were great in the beginning, and then when you issued a few more certs than they liked you were asked to pony up some $$$, and then when you did that and actually "verified" who you were on a personal international phone call, you got a grace, and then issued a few more, they decided they didn't like you so they would randomly reject your renewals close to the expiration date, and then they got bought out by some scummy foreign outfit which apparently caused the entire CA to be de-listed as untrustworthy in all major browsers. Quite the ride.

Also, the only website I've ever encountered that actually used the HTML <keygen> tag.

Same here, and the worst part is the duplicates appear to reuse the same Message-id, which confuses macOS Mail.app to no end :-/

It's actually a requirement by app store connect to use a modern sdk for uploading binaries, and modern sdk versions will often raise the minimum supported ios version, so this is not always the developer's fault. See for example https://developer.apple.com/news/upcoming-requirements/?id=0...

I'm sure there's lots of x86_64 specific code in the macOS userland that is much more than just a recompile - things like safari/javascriptcore JIT, various quartz composer core animation graphics stack and video encoder decoder stack libraries, as well as various objective-c low level pointer tagging and message passing ABI shenanigans and so on. This is probably why 32bit intel mac app support was dropped pretty hard pretty fast, as the entire runtime and userland probably required a lot of upkeep. As just one example, 32bit intel objective-c had "fragile instance variables" which was a can of worms.

I'm guessing they don't want to maintain and build and test x86_64 versions of all the macos libraries like Appkit and UIKit (including large changes like liquid glass) when they are no longer shipping x86_64 macOS versions. Which is not entirely unreasonable as I'm sure it takes a lot of effort to keep the whole ui library stack working properly on multiple archs.

Perhaps that's what they're hinting about with the note about a "subset of Rosetta". So maybe there is hope that the core x86_64 binary translator will stick around for things like VM and emulation of generic (linux? wine?) binaries, but they don't want to maintain a whole x86_64 macOS userspace going forward.

Space savings from not shipping fat binaries for everything will probably also be not insignificant. Or make room for a new fat binary for a future "arm64v2" :)

Surprised to see no patch available for watchOS, which can also receive images via iMessage. Not important enough to patch, or not vulnerable, or just not exploited in the wild yet?

I was hoping this would work over ssh in a macOS Terminal.app, but last I tried it was inserting all kinds of weird characters into the edited text files.

Windows ships an official OpenSSH server these days, but so far there haven't been any good official text editors that work over OpenSSH, as far as I know.

I've had to resort to "copy con output.txt" the few times I needed to put things into a text file over windows-opensshd...

If linux kernel security really is so bad that google had to add a proof-of-work to introduce a 4 second race for 0day submissions, I'm surprised they're ok with still using the Linux kernel as the base for Android.

Safari only exist on Apple devices

Webkit, at least, builds on a lot more platforms than you think. Take a look at https://build.webkit.org/#/builders

I'm seeing at least three other MAJOR platforms:

  • GTK-Linux-64-bit-Release-Build
  • PlayStation-Release-Build
  • Windows-64-bit-Release-Build

So I guess you couldn't get certificates for any random (MX) domain, only for those where you can obtain an inbox / user account. Still really bad, especially for things like gmail.com, but also larger enterprises. Intense.

I saw this on twitter a few hours ago on my phone, and misread the price as $25, so I was considering maybe putting in an order or even two, but when I revisited the site on my laptop and discovered it was $250, my curiosity hit a wall. Looks like a super neat product but unfortunately a bit overpriced for a gimmick.

I recently ran into an issue with this because building an iOS .ipa from the command line with xcodebuild apparently ends up shelling out to call rsync to copy some files between local directories, and because I had homebrew rsync earlier in $PATH, it would end up running homebrew rsync, but xcodebuild passed an openrsync-only command line argument "--extended-attributes" that homebrew rsync doesn't understand and would exit with a failure.

Probably because the 6502 CPU had instructions for optimized access to the zero page (first 256 bytes of RAM), this would also apply to C64 and NES etc. If you want to use "Indirect Indexed" memory accesses then I think it also has to go through an address held in the zero page.

See https://www.nesdev.org/obelisk-6502-guide/addressing.html

Most email providers support mail forwarding and distribution lists, but maybe they should have added some sort of opt-in confirmation when adding recipients outside the local domain...?

I think I read somewhere that scammers set up an email distribution list / alias / forwarding from one something.onmicrosoft.com account to dozens of victims, and then they trigger a (real!) paypal email with that one something.onmicrosoft.com address as the recipient. So the email has a valid DKIM signature from paypal, then microsoft forwards that email to all the victims, which will still pass DKIM while amplifying the attack (and maybe boosted by microsoft's SPF reputation as well) to hit as many people as possible. Apparently the paypal emails are real but dangerous as they will allow the attacker to somehow take over the victim's account if they log in, as the "middleman" onmicrosoft.com alias then becomes associated with the account which was the original "to"-email from paypal. Something like that, at least.

I usually avoid logging in to xcode. I prefer to manually configure provisioning profiles and code signing certificates by hand in the developers.apple.com web interface anyways. You can use xcodebuild on the command line to get a signed ipa, and then you can use altool or application loader to upload the ipa to appstoreconnect. I don't trust xcode to not stomp all over my carefully configured provisioning profiles and app ids.

Also worth noting that "_new" is NOT a reserved keyword, but it is sometimes mistakenly used instead of "_blank". Which can lead to funny behavior if you are visiting 2 or more sites making this mistake, as the links could then start opening in windows that were initially opened by the other site. Or least that's how it was back in the days of popup windows, before tabs and popup blockers became the norm.

Looks like the security/integrity of SSL isn't taken too seriously as the build recommends to use a hex editor to replace "_strtoi64" and "_strtoui64" with "functions likely to return 0 such as iswxdigit" in order to successfully link OpenSSL on windows 2000 and earlier. Unclear what impact such a hack would have on the integrity of the crypto operations performed by OpenSSL?