Would love to see the source code for this and the underlying details like Classic or Carbon, and the libraries mentioned on Tinker Different for TLS, HTTP/2, and Unicode
Correct, but they stylized it as "eyePhone" (from MomCorp, the all powerful, caring conglomerate), and that episode is the origin of the famous "Shut up and take my money!" meme.
I'd guess some constraint on their end related to the Zero Data Retention (ZDR) mode? Maybe the 1M context has to spill something onto disk and therefore isn't compliant with HIPAA.
I wouldn't be surprised either. But the original formatting of the worm makes me think it was human written, or maybe AI assisted, but not 100% AI. It has a lot of unusual stylistic choices that I don't believe an AI would intentionally output.
Wow. This worm is fascinating. It seems to do the following:
- Inject itself into the MediaWiki:Common.js page to persist globally, and into the User:Common.js page to do the same as a fallback
- Uses jQuery to hide UI elements that would reveal the infection
- Vandalizes 20 random articles with a 5000px wide image and another XSS script from basemetrika.ru
- If an admin is infected, it will use the Special:Nuke page to delete 3 random articles from the global namespace, AND use the Special:Random with action=delete to delete another 20 random articles
EDIT! The Special:Nuke is really weird. It gets a default list of articles to nuke from the search field, which could be any group of articles, and rubber-stamps nuking them. It does this three times in a row.
I will say that 26.4 beta 2 was the first time I've regretting using betas since Sonoma beta 2. The Sonoma beta ruined the firmware on my machine and Apple had to replace the logic board; the latest Tahoe beta broke all networking on my machine and I had to erase the installation to fix everything. I've since dropped off the beta train for the time being.
I already left the beta train on my iPhone because I had too many issues getting my grocery apps to allow me to place orders without going to my laptop and doing it in a web browser.
That's the right chip. The other comment shows off the article. I forgot that it was called the "sensor hub", that's why I couldn't find the post showing how it works.
I had never heard about this app. I thought the era of advertisements taking over the lock screen ended back in the Android 4.x days!
But also, thinking from the business perspective, it's difficult to make phones meet such a low price point without either significantly compromising their performance or stuffing them full of ads to subsidize the price.
While I generally agree with your sentiment, these tools aren't bad ones:
- Santa is a very common tool used by macOS admins to lock down binary and file access privileges for apps, usually on managed machines
- Disk Inventory X and GrandPerspective are well-known disk space usage tools for macOS (I personally use DaisyDisk but that requires a license)
- WizTree and WinDirStat are very common tools from Windows admin toolkits
The only one here I can say is potentially suspect is ClearDisk. I haven't used it before, but it does appear to be useful for specifically tracking down developer caches that eat up disk space.
One of the important reasons that it works so well is because it uses the Hexagon DSP in the Snapdragon processors to catch the events. That's why it's so hard to replicate. It's possible to do it entirely in software, but it chews through battery if you do it that way. I can't find it now, but there was an article a few years ago that explained how the feature worked.
And there's no way to program the DSP without being the creator of the device because Qualcomm requires DSP programs to be signed, as far as I'm aware, and the key has to be trusted by the device vendor.
Dell likes to pull this stunt on other devices too. Like their 1L desktops in the OptiPlex line that I managed for many years. Even though we were using genuine Dell power adapters, if they became slightly unplugged but remained powered, they would enable PROCHOT.
This was fine until the machines randomly started setting PROCHOT on genuine power adapters that were fully plugged in. Eventually I just deployed a configuration with PDQ to all the machines that ran ThrottleStop in the background with a configuration that disabled PROCHOT on login.
Unfortunately, I couldn't get it to consistently disable PROCHOT pre-login, so students and teachers in my labs would consistently wait 3-4 minutes while the machines chugged along at 700 MHz as they prepared their accounts.