The AI research centre at Torrens University Australia has helped produce a review of 110 studies on digital twins and IIoT security.

What were the main takeaways? They have found that DTs are shifting away from passive monitoring to being a part of the defence architecture.

One of the biggest weak points they found was in legacy sensors with low bandwidth. In these situations, there is a lag before the digital twin reflects a real-world change, and that lag is where attacks tend to slip in.

Would be interested to hear your thoughts! Has anyone here dealt with that sync-gap problem on older hardware?

Recently, I saw someone selling a well-known second-hand market in China. Except for some functions that need to be connected to networking, the 4th generation is used normally. However, because AXON is not in the Chinese market, most of them purchase the activated version from eBay and then reverse. Will such a problem lead to the body camera video of some American enterprises and some unpublished videos of the police will be leaked. Then he sells these body3 and 4th generations at prices ranging from 1,000 dollars and about 1,500 US dollars respectively, and gives a unique software to read and delete it. The question is whether it is feasible or not, but it is not fake to see the real shot.

Family of 11 same-codebase extensions (ChatGPT/Claude/Gemini/etc), ~5.5k users on the main one. Sold as local-only: the store listing says "No uploads to external servers," "Everything processed locally," "No tracking or telemetry."

Observed in the tested version:

• PDF export POSTs the full conversation to the developer's Cloud Run backend. A local renderer is bundled but only runs as a fallback.
• Markdown/Text/JSON exports beacon title + source URL to /api/usage. The title is derived from your first message, so it can contain chat content.
• Every request carries an X-Client-ID in chrome.storage.sync, so it follows you across machines.

Detection + full writeup: https://malext.io/reports/ExporTheft/

I wrote this after spending an unreasonable amount of time making CET-compliant callstack spoofing work end-to-end on hardware with Intel CET enabled.

The technique combines three primitives: thread pool execution for a clean stack base, enum callback trampolining for a real signed mid-stack frame, and indirect syscalls.

The actual contribution is the CET compliance mechanism: a jmp-based context switch combined with direct shadow stack pointer reconciliation via RDSSPQ/INCSSPQ, without touching unwind metadata. Different approach from BYOUD.

Implemented in Rust with inline assembly.