Body

I’ve been playing with the current crop of AI agent runtimes and noticed the same pattern over and over:

• One process both reads untrusted content and executes tools
• API keys live in plaintext dotfiles
• There’s no audit log of what the agent actually did
• There’s no concept of the agent’s goal, so drift is invisible
• When something goes wrong, there is nothing to replay or verify

So I built ClearFrame, an open-source protocol and runtime that tries to fix those structural issues rather than paper over them with prompts.

What ClearFrame does differently

• Reader / Actor isolation Untrusted content ingestion (web, files, APIs) runs in a separate sandbox from tool execution. The process that can run shell, write_file, etc. never sees raw web content directly.
• GoalManifest + alignment scoring Every session starts with a GoalManifest that declares the goal, allowed tools, domains, and limits. Each proposed tool call is scored for alignment and can be auto-approved, queued for human review, or blocked.
• Reasoning Transparency Layer (RTL) The agent’s chain-of-thought is captured as structured JSON (with hashes for tamper‑evidence), so you can replay and inspect how it reached a decision.
• HMAC-chained audit log Every event (session start/end, goal scores, tool approvals, context hashes) is written to an append-only log with a hash chain. You can verify the log hasn’t been edited after the fact.
• AgentOps control plane A small FastAPI app that shows live sessions, alignment scores, reasoning traces, and queued tool calls. You can approve/block calls in real time and verify audit integrity.

Who this is for

• People wiring agents into production systems and worried about prompt injection, credential leakage, or goal drift
• Teams who need to show regulators / security what their agents are actually doing
• Anyone who wants something more inspectable than “call tools from inside the model and hope for the best”

Status

• Written in Python 3.11+
• Packaged as a library with a CLI (clearframe init, clearframe audit-tail, etc.)
• GitHub Pages site is live with docs and examples

Links

• Homepage / docs: https://ibrahimmukherjee-boop.github.io/ClearFrame/
• Code: https://github.com/ibrahimmukherjee-boop/ClearFrame

I’d love feedback from people building or operating agents in the real world:

• Does this address the actual failure modes you’re seeing?
• What would you want to plug ClearFrame into first (LangChain, LlamaIndex, AutoGen, something else)?
• What’s missing for you to trust an agent runtime in production?

Root cause: the $forbiddenphpstrings blocklist is only enforced in blacklist mode -> the default whitelist mode never touches it. The whitelist regex is also blind to PHP dynamic callable syntax (('exec')('cmd')). Either bug alone limits impact; together they reach OS command execution. Coordinated disclosure - patch available as of 4/4/2026.

The latest YARA-X release now has an official browser playground:

https://virustotal.github.io/yara-x/playground/

You can just run rules in the browser with the WASM build, which is nice when you don’t feel like using the CLI for small tests

LSP runs in a worker, so you get diagnostics/autocomplete and the UI doesn’t hang

Everything is local, nothing gets uploaded. Pretty handy for quick rule testing.

Hi everyone,

I recently bought one of those popular, cheap Android projectors and noticed some suspicious network activity. Being curious, I decided to set up a lab, intercept the traffic, and dig into the firmware.

I ended up uncovering a factory-installed malware ecosystem including a disguised dropper (StoreOS) and a persistent RAT (SilentSDK) that communicates with a C2 server in China (api.pixelpioneerss.com).

Key findings of my analysis:

• The malware uses a "Byte-Reversal" trick on APK payloads..
• RAT Capabilities: Decrypted strings reveal remote command execution, chmod 777 on secondary payloads, and deep device fingerprinting.

This is my first independent technical report and deep dive into malware research. I’ve documented the full kill chain, decrypted the obfuscated strings, and written scripts to repair the malformed payloads for analysis.

Full Report: https://github.com/Kavan00/Android-Projector-C2-Malware

I'd love to get your opinion on the report.

Looking forward to your feedback!

Taiwanese authorities have seized over NT$200 million ($6.67 million USD) in real estate and bank savings from 24-year-old Lin Rui-siang, the alleged mastermind behind the Incognito Market.

Lin, who operated under the alias "Pharoah," was arrested by the FBI at JFK Airport in May 2024 while in transit from Saint Lucia to Singapore. The seizure follows his December 2024 guilty plea in a U.S. court for narcotics conspiracy, money laundering, and selling adulterated medication.

I've been doing iOS security assessments professionally for about 15 years — banking apps, fintech, enterprise platforms. Over that time, certain patterns keep showing up in production App Store binaries. Figured it's worth sharing what I see most frequently, since many iOS developers seem genuinely unaware these issues exist.

What keeps showing up:

The most common finding is hardcoded secrets in the binary — API keys, backend URLs, authentication tokens sitting right there in plaintext strings. Developers assume compilation somehow obscures these. It doesn't. Extracting them is trivial with standard tooling.

Insecure local data storage is a close second. UserDefaults for sensitive data, unprotected Core Data databases, plist files with session tokens. On a jailbroken device (or via backup extraction on a non-jailbroken one), all of this is readable.

Weak or misconfigured encryption comes third. I regularly find apps that import CryptoKit or CommonCrypto but use ECB mode, hardcoded IVs, or derive keys from predictable inputs. The encryption is technically present but functionally useless.

Then there's the network layer: disabled ATS exceptions, certificate pinning that's implemented but trivially bypassable, and HTTP endpoints mixed with HTTPS.

Methodology:

Most of this comes from static analysis — no runtime instrumentation needed. Download the IPA, unpack, run string extraction, inspect the Mach-O binary, check plist configurations, review embedded frameworks. You'd be surprised how much is visible before you even launch the app.

I've built custom tooling for this over the years that automates the initial triage across ~47 check categories. Happy to discuss methodology or specific techniques in comments.

I've also been running a monthly live session ("iOS App Autopsy") where I walk through this process on real apps — follow the link if interested.

For those who don't know: NaClCON is a new, intentionally small (300 person cap) conference focused on hacker history and culture, not zero-days or AI hype. Beach venue, open bars, CTF, the whole deal. $495 all-in.

The speaker list is a who's-who of people who built the scene:

Speakers:

• Lee Felsenstein — Homebrew Computer Club OG, designer of the Osborne 1 (the first mass-produced portable computer)
• Chris Wysopal (Weld Pond) — L0pht Heavy Industries, testified before the Senate in 1998 that they could take down the internet in 30 minutes, co-founder of Veracode
• G. Mark Hardy — 40+ years in cybersecurity, talking "A Hacker Looks at 50"
• Richard Thieme — Author/speaker who's keynoted DEF CON 27 times, covering the human impacts of tech since the early internet days
• Brian Harden (noid) — Helped build the LA 2600 scene, DC206, and DEF CON itself. Now farms and writes about himself in third person
• Izaac Falken — 2600 Magazine / Off The Hook, 30 years in professional security
• Mei Danowski — Natto Thoughts, speaking on ancient Chinese strategy and the birth of China's early hacker culture
• Josh Corman — "I Am The Cavalry" founder, CISA COVID task force, currently working on UnDisruptable27
• Casey John Ellis — Bugcrowd founder, co-founder of disclose.io, White House, DoD, and DHS security advisor
• Jericho — 33+ years in the scene, speaking on life in an early 90s hacker group
• Andrew Brandt — Threat researcher (Sophos, Symantec), demoing early hacking tools on obsolete hardware
• Johnny Shaieb: IBM X-Force Red, speaking on the history of vulnerability databases
• B.K. DeLong (McIntyre) — Attrition.org, the team that manually archived 15,000+ web defacements in the late 90s
• Jamie Arlen — 30+ years, Securosis, Liquidmatrix; "an epic career of doing all the wrong things and somehow still being right"
• Heidi and Bruce Potter — Developers of Turngate and founders of ShmoonCon
• Dustin Heywood (EvilMog) — IBM X-Force, Team Hashcat, multi-time Hacker Jeopardy World Champion

Fireside chats include noid doing DEF CON war stories and Edison Carter on old-school phone phreaking in the 80s/90s and a grog filled night with the dread pirate Hackbeer'd.

A couple things worth knowing before you register:

The conference hotel (Courtyard by Marriott Carolina Beach Oceanfront) has a room block at $139/night (roughly 70% off the peak beach-season rates) so book through naclcon.com/hotel or use group code NACC. Block expires May 1st so don't sit on it.

P.S. If the tickets are too large a hurtle for you, DM me and I'll see what I can do to get you a discount code.

naclcon.com | Register

Hi everyone, I’m a Cybersecurity student at HFU in Germany and recently submitted a vulnerability to the Google VRP regarding the Google Password Manager on Android (tested on Pixel 8, Android 16).

The Issue: When you view a cleartext password in the app and minimize it, the app fails to apply FLAG_SECURE or blur the background. When opening the "Recent Apps" (Task Switcher), the cleartext password is fully visible in the preview, even though the app actively overlays a "Enter your screen lock" biometric prompt in the foreground. It basically renders its own secondary biometric lock completely useless.

Google's Response: Google closed the report as Won't Fix (Intended Behavior). Their threat model assumes that if an attacker has physical access to an unlocked device, it's game over.

The BSI Discrepancy: What makes this interesting is that the German Federal Office for Information Security (BSI) recently published a study on Password Managers. In their Threat Model A02 ("Attacker has temporary access to the unlocked device"), they explicitly mandate that sensitive content MUST be protected from background snapshots/screenshots. So while Google says this is intended, national security guidelines classify this as a vulnerability. (For comparison: The iOS built-in password manager instantly blurs the screen when losing focus).

Here is my PoC screenshot:
https://drive.google.com/file/d/1PTGKRpyFj_jY9S76Jlo62mSCDJ3c6uLO/view?usp=sharing
https://drive.google.com/file/d/1nIJMQbM4R17EMt9f1Ffb4UmCPYY7-GXb/view?usp=sharing

What are your thoughts on this? Should password managers protect against shoulder surfing via the Task Switcher, or is Google right to rely solely on the OS lockscreen?