landr0id

You can also use https://github.com/mstange/samply to make recording and viewing in the Firefox profiler easier.

It will spin up a localhost server after the trace ends, the profiler uses the localhost server and nothing is shared with Firefox servers unless you explicitly choose to upload the data and create a permalink.

A myth propelled by people who don't understand security continually saying "Anyone can read the code, therefore it's more secure".

Do not under any circumstances use rlottie for your application if it consumes untrusted animations. It is not secure software and Samsung does not service security issues.

*I will add though if you absolutely need to, use Telegram's fork. They've at least fixed most of the known issues (with very great commit messages like "fix bug")

Also https://github.com/burntsushi/biff

I had the same thought. The project's description:

>secure HTML/CSS engine

No offense to these folks, but I see no evidence of any fuzzing which makes it hard to believe there aren't some exploitable bugs in the codebase. Google has world-class browser devs and tooling, yet they still write exploitable bugs :p (and sorry Apple / Mozilla, you guys have world-class browser devs but I don't know enough about your tooling. Microsoft was purposefully omitted)

Yeah, very few of those bugs are in the renderer, but they still happen!

...this is for building apps targeting iOS and macOS on non-macOS platforms. Why would Android support be necessary?

So long as you're aware that you're not optimizing, it's fine. Trying to build something useful as a new Rust dev while worrying about lifetimes is going to be quite challenging, unless your intention is to specifically learn about lifetimes and the borrow checker.

Yes the borrow checker is central to Rust, but there are other features to the language that people _also_ need to learn and explore to be productive. Some of these features may attract them to Rust (like pattern matching / traits / etc.)

>> being explicit and making the programmer make decisions

>Why RAII then?

Their quote is probably better rephrased as _being explicit and making the programmer make decisions when the compiler's decision might impact safety_

Implicit conversion between primitives may impact the safety of your application. Implicit memory management and initialization is something the compiler can do safely and is central to Rust's safety story.

I think they’re pretty young too. Hoping for a bright future ahead of them!

Windows Defender believes that my Rust egui application is a trojan, but magically if I compile it with a different toolchain it's no longer flagged :p

There's something seriously wrong with A/V heuristics.

The World of Warships community has gone through similar steps, but the encryption is much more straightforward. Some of the packets are pickled Python, some are just binary blobs, so there are some undocumented packets but for the most part people have done a decent job of figuring it out and building tooling around it such as the minimap renderer: https://github.com/WoWs-Builder-Team/minimap_renderer

There’s an odd unspoken and somewhat understood agreement between the developer (Wargaming) and community though: the community actively reverse engineers the game to document the packets and WG kind of looks the other way (except when they recently threatened me with a perma ban :) — they even use the tooling the community creates for official tournaments.

In this article the author mentions Riot partnering with external companies to provide more rich data set and analytics. Do they use these tools/data sets for tournaments as well? Is it known at all how these partnerships are structured?

I haven't tried it but have been looking into the same problem. This is probably the best bet (does require an Azure account though): https://github.com/Azure/trusted-signing-action

Kind of a joke, but it could be useful for determining if they should serve light-mode or dark-mode ads. But I suppose they could just detect if dark/light mode are enabled.

Cool project! I remember back in the day having to poke my friends with xbins upload access to drop things for me. It wasn’t super clear who anyone involved with the service was in that capacity. I’m surprised xbins is still kicking and with the same model it used to have, but it’s kinda cool at the same time.

Signature scanning is just scanning for unique bytes from a compiled function that will remain consistent across builds. You search memory for those bytes and when you find them, you find the function you're interested in.

Here's an example from some shellcode loader I wrote: https://github.com/exploits-forsale/solstice/blob/c3fc9a55c6...

https://free60.org/ probably has all the information you need.

The flash chip is encrypted with the console's CPU key, and the CPU key is unique per-console and encoded in efuses. So even if one person manages to dump keys they're mostly useless for hacking other consoles. The exception to this is the "keyvault" which is the console's own private key used for signing save games. You can take save games from console A and load them on console B, so console B is able to verify console A's signature based off the public key certificate embedded in the save. Microsoft had a revocation process for revoking keyvaults if they ever leaked but they just gave up once too many were in the wild.

Dev kits are keyed differently and most of the console's keys for signing / encryption are in various SDK DLLs that if you reverse engineer you can find.

The Xbox 360 was overall a very, very secure device. While we don't know exactly how the folks who discovered the hypervisor syscall handler bug were able to get plaintext, it's theorized that it came from development kit and SDK leaks. With an SDK and dev kit someone could dump boot loaders and the HV.

Otherwise on a retail console you can't do much. The hard drives are not encrypted but all content that can possibly contain code / save data is signed. Save data cannot contain code but introduces scripting engine / save parsing attack surface, but you can't modify it without first dumping keys from a retail console.

To dump keys from a retail console you have to get code exec in the hypervisor. To attack the hypervisor you have be able to dump the hypervisor to audit it.

To dump the hypervisor you have to be able to read its contents or dump it from flash. The flash is encrypted with a per-console key (and I don't think you can sniff the bus?) and RAM is encrypted.

Realistically if it weren't for the original syscall handler bug and dev kits getting into researcher's hands, the Xbox 360 may have never been hacked.

Wait until you read Grimdoomer’s (yet to be published) write-up on his recent hypervisor exploit that works on the latest OS: https://x.com/grimdoomer/status/1847497275289063676

It’s going to be a doozy

Wezterm is also pretty good. It’s by far my favorite “new” terminal app I’ve tried.

It's a bit unfortunate wording but it basically requires any nightly toolchain version. It uses `std::intrinsics::breakpoint()` which is a compiler intrinstic. This has been available for a long time, but afaik will never be exposed on a stable toolchain.

Per https://dev-doc.rust-lang.org/nightly/unstable-book/library-...

>This feature is internal to the Rust compiler and is not intended for general use.

The pretty printers seem to break from time to time as well with compiler updates: https://www.reddit.com/r/rust/comments/1f28akn/invalid_value...

Things have certainly changed since 2012. Every Rust program uses TLS -- at least on Windows. Not sure about other platforms.

I recently wrote my own PE loader and found handling TLS data the most annoying aspect of the process: https://landaire.net/reflective-pe-loader-for-xbox/

Some algorithm improvements ripgrep uses could be brought into grep, but ripgrep at its core just operates differently. It uses threads by default, assumes unicode, has a completely different regex engine, amongst other things. It could also probably be argued that some things from ripgrep would be pretty difficult to port from Rust to C or C++ safely.

burntsushi has a blog post on it here: https://blog.burntsushi.net/ripgrep/

I'm kind of curious what Alex meant by this, as the security problems relating to io_uring are, to my knowledge, unrelated to the user-space program. It makes sense if you want to disable the feature in your own kernel or remove potential sandbox escape attack surface, but it's like saying "You might want to avoid win32k if you want to use features with a good security track record" (and I know this is kind of apples to oranges but you get the point).

Assuming Sky since the URL slug shows "Microsoft"

>Not sure what questions Microsoft have to answer.

The only thing I could think of is if it was a driver update, the driver has to be "WHQL" signed. WHQL stands for "Windows Hardware Quality Lab" -- what quality are they ensuring? (spoiler alert from my time at Microsoft: it's not terribly robust :p )

It's not realistic for Microsoft to test drivers in a manner that represents real-world usage, but perhaps they need to start doing some basic "it works with whatever integrated agent/etc is required" testing as a requirement for signing a driver.

If it was a user-mode update? Yeah no real fault on Microsoft here.

I wonder if this affects tvOS as well. I got my first Apple TV from a friend, wiped it, and recently bought a second brand new Apple TV.

My girlfriend was attempting to install an app on the new ATV and it prompted for my friend’s Apple ID to log in. The only association this new ATV should have is to my ID which is logged in on both devices.