Ristovski

> In midvalues you will see a slight dot pattern.

Is this not simply some sort of watermark instead of an artifact?

A similar tool to this (includes interactive TUI) is https://github.com/wagoodman/dive

FastEndpoints is nice but they don't seem to plan on supporting NativeAOT anytime soon https://github.com/FastEndpoints/FastEndpoints/issues/565#is....

For those wondering what the exact attack vector is, the AMD advisory has some details:

> Improper validation in a model specific register (MSR) could allow a malicious program with ring0 access to modify SMM configuration while SMI lock is enabled, potentially leading to arbitrary code execution. [0]

[0]: https://www.amd.com/en/resources/product-security/bulletin/a...

> nvtop stands for NVidia TOP, a (h)top like task monitor for NVIDIA GPUs.

The Github repo[0] disagrees: > NVTOP stands for Neat Videocard TOP, a (h)top like task monitor for GPUs and accelerators.

I have been using this on AMD for a long time now.

[0]: https://github.com/Syllo/nvtop

One of the major downsides of the Hexagon DSP is that its near impossible to actually run anything on it unless you somehow get your hands on an unprovisioned/unlocked SoC.

The HLOS (High-level OS) running on the Hexagon requires every "applet" to be signed by either the Qualcomm root cert or the OEMs cert. Usually, every phone has a set of generic Hexagon applets (or "skeleton libs") that are provided and signed by the OEM, which seem to be freely usable to offload some computational work to the DSP (mainly FastCV et al - https://developer.qualcomm.com/sites/default/files/docs/qual...). Those of course come with their own bugs: https://research.checkpoint.com/2021/pwn2own-qualcomm-dsp/

On some older SoCs, you were able to use a TOCTOU (Time of check to time of use) exploit to bypass the signature check by patching the applet loader shim in-memory, once it itself got authenticated: https://github.com/geohot/freethedsp/ (I have personally ported this to the msm8953, and it seems to work)

IIRC there is some rudimentary AVR5 support in https://github.com/ZigEmbeddedGroup/microzig (https://github.com/ZigEmbeddedGroup/microzig/blob/main/src/m...)

I believe that should be possible, yes.

Here is an interesting paper about Computrace: https://www.coresecurity.com/sites/default/files/private-fil...

For anyone interested in efivars, I have an old blog post about essentially the same thing but going a bit more in-depth, including how to actually modify the efivar entries: https://ristovski.github.io/posts/inside-insydeh2o/

An interesting comment made in the Phoronix forums:

> My theory is that fixing the Spectre V2 vulnerability on a hardware level would lead to fundamental architecture changes that AMD is not willing to make, because it may add so much more complexity to the architecture or it may just be too unconvenient. They probably realized that optimizing the code paths that the Linux kernel utilizes on the default mitigations mode is faster, simpler and it may involve less deeper changes, while still being secure.

> As far as I know, pretty much every CPU architecture that implements speculative execution is vulnerable to some version of Spectre, so note that this is not a fundametal flaw of AMD64.

I wonder, do those sensors have some built-in battery that lasts a long time, but ultimately the whole sensor needs to be replaced due to the electronics being potted-in?

Or is it so low power that it can use some sort of piezoelectric/MEMS power source that charges it as the wheel is spinning?

A similar thing once happened to me as a kid, albeit with a twist. I counted down from 10 quite slowly and opened my eyes once I reached 0 - only for it to be morning.

I am still wondering why Volt, the native desktop client for Slack/Discord et al only supports MacOS when V boasts about cross-platform support and cross-compilation.

This is very useful as well: https://gchq.github.io/CyberChef/ (CyberChef - The Cyber Swiss Army Knife)

A very handy tool for this is https://www.nongnu.org/atool/

Title is a bit misleading - this is merely enforcing that developers who create third party Telegram clients include the functionality of showing ads.

They seem to go up to 4 :)

Example: https://github.com/UCYT5040/Google-Sticker-Mashup-Research/b...

Edit: 6: https://github.com/UCYT5040/Google-Sticker-Mashup-Research/b...

I haven't had much experience with .NET on Visual Studio, but I would say that Jetbrains Rider is probably the best thing you can get for .NET work on Linux.

As a matter of fact, they implemented their own hot-reload functionality themselves [0][1].

[0] - https://twitter.com/JetBrainsRider/status/145148793146664961... [1] - https://www.jetbrains.com/rider/nextversion/

Discord [1] is taking a toll from the increased traffic as well:

"We're noticing an elevated level of usage for the time of day and are currently monitoring the performance of our systems. We do not anticipate this resulting in any impact to the service.

We have temporarily disabled typing notifications. We expect these to be re-enabled soon."

[1] https://discordstatus.com/

Have gotten multiple such emails the last couple of weeks.

I think Googles spam detection is a bit too much lax when the sender itself is using gmail.

These might as well be hacked accounts which have already proven themselves to be valid and "human" at a previous point in time? I doubt gmails spam detection would let a brand new account spam CC'd emails without any sort of detection.

Afaik, BlackHat talks/presentations go public after around half a year.

Today I found about Organic Maps[0], and it seems like a viable alternative to Google Maps, albeit with some annoying quirks.

It is offline - meaning you download the areas you are interested in first, after which all the data is available fully offline (including stuff like directions, metro maps etc). The interface takes a bit to get used to, but the biggest let down is the fact that you can't edit a route in the route planner - you need to start all over again (selecting start/destination, no way to modify either).

[0] - https://f-droid.org/en/packages/app.organicmaps/ (also available on Play Store)

A thing I noticed: The Linux AppImage version bundles a non-stripped binary of CEF, which unnecessarily inflates the download size.

I never anticipated people would find it this interesting which is why I barely got enough motivation to write the first part, so thanks for the encouragement!

While doing my initial research, I stumbled upon a patent [0], where Motorola was listed as the applicant, it seems to be similar in concept to the current sensor hub implementation.

It also mentions "training" and more advanced processing (which would be ideal for the Qualcomm Hexagon DSP, shame it's practically unused on non-Pixel phones).

[0] https://patentimages.storage.googleapis.com/cc/ee/a2/e631f84...

You're right! However, I don't remember the exact issue, but Ghidra behaves differently when loading a raw binary vs when you load an ELF file. Perhaps it was something with the analyzers, I can't recall (there are ELF-specific ones for example).

> I'm curious if the use of little add on MCUs to cellphone designs like this opens up the opportunity to back door into the OS

I would say that the possibility is there - imagine a buffer overflow (or something as bad) in the driver running in the kernel.

However, getting the malicious firmware onto the MCU would be the difficult part. But I suppose even a purposefully "bad" batch of MCUs that have an extra core executing malicious code is not exactly science fiction in these times :P

> could be hard fault handler getting invoked due to either div by 0 or incorrect linkage

Interesting! I will look into this, cheers.

> Great write-up BTW - subscribe!

Thank you, much appreciated!