Firmware Analysis Toolkit - rebuilt from the ground-up. The ultimate toolkit for firmware security research for IoT, Physical AI, Robotics and Mobile Devices. Try it out & share feedback. It's unpolished & quite a lot of rough edges; but done > perfect.

Progress doesn’t need Permission. Mathematicians boycotting OpenAI is the decision for when the field was intentionally guarded. Like a lot of other fields are still. It’s time we fix inefficiencies, and accelerate human capabilities, as a whole, not keep fields closed and exclusive for a select few.

Visual notebook included too for GUI enthusiasts. Making things simple is the most complex thing. Planning to open-source in the next 2-3 days.

Just tried out ASC for APK decompilation → massive performance boost. Great work @MGAldys4 ! Was a much needed improvement. Here's how it compared against JADx for me:

Try it out from : github.com/attify/firmware-a…

Humanoids - Who cares if they get hacked? The looming Humanoid hacks, and how we can prevent a Humanoid Mirai. Coming from a decade of Offensive IoT experience, in the Humanoid scene, what initially was somewhat of a shocker was that most of the Humanoid, Robotics and Physical AI industry - could not differentiate between Safety and Security. As Humanoids become normal, and with over a billion Humanoids expected to be among us in the coming decade, I think it’s time to raise some essential questions, and more importantly - share practical and actionable solutions. I have spent past many months interacting with these systems deeply, at various levels, and the future that I see is very (deeply) concerning - from a Security standpoint. First of all, Safety is different from Security. And like I said - this key thought process - is missing from the majority of robotics and humanoid scene. But wait - why does it matter? With Humanoids, what begins as a computation, ends as a change in the physical world. This physical authority can have impact on whatever is in the environment : including people, objects, but not limited to those. But how secure is the mechanism by which this physical authority is decided? And who’s responsible to secure it? Is it a responsibility of who is deploying it in their facilities, is it the responsibility of the one building the Humanoid, or is it a responsibility of the Integrators? And that’s the problem. There is no clear answer. But the threat is real. If you’ve heard of Mirai (the botnet) - my question to you is - what would a Mirai like situation for Humanoids look like - when there are millions of Humanoids among different locations - factory floors, office spaces, schools, retail stores, public areas, and probably even in your home. A Cross-Layer Problem The newer intelligent physical robots and Embodied AI systems have a number of moving parts. But as you explore the recent research, academic research is highly skewed in certain directions, which I think is making everyone miss the real picture. So what are the moving parts : from the specifics of the Deployment Context, all the way to the remote cloud endpoints, to on-device firmware, the embedded hardware, the VLAs and WAMs that run it, to the communication protocols - both for communicating and distributing decisions within internal joints, actuators, and systems, to the external communication interface — all of these, but also many further deeper layers in each of them, and even their interconnections. Humanoid Security is not a simple challenge. But it is not unsolvable. But the fact that noone’s doing anything about it, bothers me. Are we waiting for a major calamity - like a Humanoid Ransomware attack, and then we blame the regulators for not having the relevant standards - by saying things like I had all the needed certifications, or are we going to ignore because who cares - it’s all insured. Well everyone’s different - but I’m here to work with those, who want to be proactive - and help them secure their Humanoids - either as a builder of one, or a deployer, or an organisation who’s actively purchasing them. Humanoid Deployment Security For any Humanoid Deployment Security, it is important to have a clear evidence-backed inventory of Enforcement Points and Authority Path. Authority Path is about how a certain action gains authority, that it is safe to be executed or acted upon. Enforcement Points are where do we check that Authority. There is a 3rd aspect too - which is Consequences. Any Humanoid maker, integrator or deployer, should be able to state - with factual backing - of what are the possible Consequences. These Consequences can be defined in the form of actual physical action that can be taken by the Humanoid, but looked at from an outsider perspective. Outsider perspective mean that we are looking at what all in the physical world, can the Humanoid affect. Evidence-Backed Deployment Assurance A new kind of record is required - and should be mandated - which matches the security and safety standards, with the actual evidences. There should be clear distinction between what was observed, under what situations, what is inferred and what remains unknown. And while compliances and upcoming regulations are somewhat moving in this direction, there’s still a huge missing gap, which I don’t see being talked about. It’s not some esoteric knowledge, but it’s a deeper practice of thinking like an adversary, and not like a researcher. And this practice - should be a must - and mandated - by anyone who is purchasing humanoids and other robotics deployed within their facilities. And if you are building a Humanoid, you could probably get this as an external service initially, but it must be an internal capability that you build towards. And no, it’s not a Robotics Security role, or a Firmware Security role, it’s a new role that is yet to be named. Coming times, I’ll be sharing actionable solutions - which would make it easy for anyone to adopt, as well as to maintain the record of how granular security aspects change between releases. Whether you work with me directly or not, I will help you secure your humanoid. How can we work together? If you are building Humanoids, deploying them, or it’s being deployed in your facilities - I can work with you in different capacities, to both offer advice, un-released powerful tools, and suggest ways to build long-term internal capabilities.

congrats @axiommathai @CarinaLHong on the raise. mathematics is the right foundation for systems that reason - and essential for a safer future. the bet on verification infrastructure over benchmark scores is the right one, and AXLE proves it where - verify_proof tells you a proof is wrong. - repair_proofs tells you how it's wrong and tries to fix it. it’s a genius flywheel open-source verify_proof, repair_proofs - the whole toolkit. keep the prover proprietary. verification : public good feedback loop : product open-sourcing verification grows the ecosystem → more Lean proofs written → more training data available → better prover. & sustains both the advancement of Maths and advancing Axiom. maths is the first domain where this works. def. won't be the last. so many emergent possibilities.

things will never be the same again

doing my part to make the ai ecosystem safer. starting with llama.cpp Heap Overflow Bug identified using CFSE World Modeling. Just received : CVE-2026-27940 one step at a time. thanks @ggerganov for prioritizing security and fixing at such light-speed 🙏 github.com/ggml-org/llama.cp…

~$21B in market value disappeared in hours : CrowdStrike (CRWD) -8%, Cloudflare (NET) -8.1%, Okta (OKTA) -9.2%, Qualys (QLYS) -10.2%, Zscaler (ZS) -5.5% - lowest in the last few years. For many : Panic Mode. but Zoom out → → → This is a Huge Win for safer code and a pivotal moment in CyberSecurity. With OpenAI’s Aardvark and now Anthropic’s Claude Code Security : the game is evolving fast, for the better. There’s zero point in humans grinding away at tasks AI crushes at scale and depth - and it’s proven - like with the recent EVMBench, and others. But that doesn’t kill the industry. It frees it to level up. This is the foundation of all real progress. We've long been addicted to the adrenaline of breaking things (red team glory, bug bounties, pentest hero stories), but we’ve spent far less energy on making systems truly unbreakable. In that direction, it’s great that the frontier labs are taking it up. And more individual researchers should too. Vibe Coding is hitting security hard : what used to require expensive consultants, armies of specialists, is now in reach of every dev team. Selling “magic” products (snake-oil) is no longer sustainable. Selling Products & Services which are now vibe-codable and are in realm of everyone, is what advancement looks like. Its about democratizing deep reasoning so defenders can scale fixes faster than attackers scale exploits. It’s time for the true curiousity seekers to go deeper & pursue their true passion of figuring out how to break the unbreakable. But what’s next? What’s going to be relevant in the coming times? What is red team/sec research/exploitation expertise going to look like? Well, Expertise is no longer going to be about Information Arbitrage -- that untruth is disappearing quickly. Expertise is about: 1. Can you apply your Intelligence at the highest level, consistently? 2. Do you know where to apply your Intelligence? If you’re in cybersec and worried your current skills won’t keep you relevant → adapt now. How to adapt? By Mastering the Meta Layer: - How to Orchestrate Agents? - How to build longer Reasoning systems? - How to Engineer Reliable, Obserable Systems? - Building Supervision, Evals, Agentic Collaboration frameworks - Secure/Flexible Sandboxing These are the force multipliers, which you can apply across any surface : IoT, Web3, Mobile, Cloud, Web, Infra, ICS, OT, anything. The surface layer work? Humans won’t own that much longer. It’s time you face that reality. Value of Human output is diminishing rapidly there, whether you like it or not. Say Hello to an Era where Security looks radically different. It’s no longer fear-fueled “secret knowledge” sales, but proactive, curiosity-driven creation. If you’re a dreamer, it’s time to rethink what the future could look like. And it’s time to build that future. I’m in. Are you?

Research :: 1. How to Look (at x) 2. Where to Look (for x) 3. Redefine x →

Great work by OpenAI. Hacking, at its core, is about Curiosity and Thinking Differently. Instead of thinking that the game is over, the game is on. It’s time to build frameworks & systems, that can go beyond what the top models are capable of. The most interesting times.

This Opus 4.6 run went to 17h 6m before hitting weekly rate limits. But the most valuable output was not the solution. It was learning how the LLM navigates a hard problem over many hours, and then figuring out ways in which it can be steered better. long vs short llm sessions in longer sessions, it does things which are often invisible in shorter conversations. like hitting dead ends multiple times, retracing its paths, the llm figuring out why it took a certain path, updating its reasoning to choose a better path this time, what if it again goes down a rabbit hole or dead-end, when does it give up, generates conjectures, attempts to falsify its own conjectures, and decides when to abandon one approach for another. most of these decisions are okayish. some are remarkably good. A few are subtly wrong in ways that cascade (esp. in scientific domains / math problems). building the map If you treat a long autonomous run as an observation session rather than a solution session, you get something far more valuable than one answer. You get a map of the decision landscape — what forks matter, where backtracking happens, what evidence is needed before committing to a path, and how findings from different tracks need to merge. That map is what you use to build a research harness. Once you have the harness, you stop relying on a single LLM running for 17 hours and start running multiple LLMs in parallel — each on a scoped track with explicit entry/exit criteria, refutation gates, and evidence requirements. One track tries to prove. Another tries to falsify. A third explores an alternative construction. They share artifacts, not context windows. This is the actual hard problem in doing research with LLMs: not getting one model to run longer, but designing the infrastructure that lets multiple models work on parallel tracks with traceable, mergeable results. Long runtimes are the observation phase. The Harness is what Generalizes what’s next? Over the next few weeks, I'll apply it to other research areas - because the harness doesn't belong to a single domain, but can learn from all of them.

Just solved & submitted Q10 of #1stProof research-level math problems. If you can prove it, but can't trace what your proof depends on, or query which claims are still hypotheses, or machine-verify the core theorem - it's not really a proof. The initial bottleneck in solving it wasn't mathematical insight, but lack of a system for reliable research. Solving complex problems with LLMs requires a system composed of two things: 1. High-Quality World Model : the problem space 2. Traceable Way Finding : how the LLM experiments to find out the path to the ideal final state of the world model And the critical third layer: a mix of Semi-Formal and Formal Verification. For Q10 (RKHS tensor decomposition), I built: a #CFSE invariant library with explicit proved/hypothesis classification, ASIQL dependency graph queries, and a Lean4 machine-checked proof. Thanks to #FirstProof for doing this. It forced me to solve the hard infrastructure problems of doing research with LLMs - traceability, accuracy and scale. Submission at - github.com/adi0x90/firstproo… Invariant Library - github.com/adi0x90/firstproo… #Lean4 #AIForMath

❤️ decision trees

Great work Claude 👏🏻 10+ hours.

Claude Opus 4.6 running for 5+ hours, while delivering great incremental progress, and not going off-track.