Case study · Security Tooling
iOS Exploit-Kit Response and Security Check Tool
A security engineer is supporting the MIIT’s response to an iOS exploit-kit security incident: the intelligence comes from iVerify’s disclosure of the Coruna attack toolchain, and the tool must be zero-dependency, distributable offline, and aimed at ordinary users without security expertise. This article walks you through the session from that day, building the single-file HTML check tool from one instruction.
Target: iVerify’s public disclosure post on Coruna· Constraints: zero-dependency single file · opens and works in a browser · works offline· Model: Landi N2.5 (provided by AVL-Zero)· Deliverable: HTML tool for iOS version risk detection· Date: 2026-06-16
Session replays & reports are original records in Simplified Chinese · Built with AVL Code + the Landi model
Overview
- 01
Study the intelligence — pin the attack range to iOS 13–17.2.1
Hand AVL Code the iVerify blog link and the tool requirements, and you will see it extract Coruna’s version attack range and lay out a 5-item task list accordingly.
- 02
Parallel build — page and detection logic land on two tracks
Once the plan is set, two sub-agents split the work: one designs the HTML page structure and color scheme, the other implements the version detection and risk-grading logic.
- 03
Compliant delivery — a single-file check tool ready to distribute
With MIIT-perspective copy polishing plus the official Apple upgrade link and a footer attribution, you get a zero-dependency HTML check tool distributable offline.
Task for AVL Code
Based on the information at https://iverify.io/blog/coruna-inside-the-nation-state-grade-ios-exploit-kit-we-ve-been-tracking. Create an HTML interface that automatically fetches and detects the iOS version, determines whether it is within Coruna’s attack range, and if so guides the user through upgrading the phone’s operating system. Do not mention iVerify’s disclosure. Adequately warn users of the risk and give recommendations. Keep the color scheme plain and professional. Review and polish the wording from the MIIT’s perspective; for the upgrade, besides basic guidance, include Apple’s official link and contact information. For major version 15, 15.8.7 and later are safe; for major version 16, 16.7.5 and later are safe; for major version 17, 17.3 and later are safe; versions below 13 are outside the scope of this check; footer note: This web check tool is published by the MIIT Cybersecurity Threat and Vulnerability Information Sharing Platform & generated by the Antiy Landi threat detection and analysis (AI) vertical model.
Make a plan first, then dispatch sub-agents to work in parallel. Prerequisites: A working AVL Code (with the Antiy Landi model service built in); a public threat-intelligence source link (the iVerify blog post for this case); publisher attribution copy and safe-version thresholds (given by the publisher)
Reproduction materials at the end of this article Try it yourself ↓
Reading the Intel
The tool’s attack range is not guessed — it comes from public intel:
Based on the information at https://iverify.io/blog/coruna-inside-the-nation-state-grade-ios-exploit-kit-we-ve-been-tracking, create an HTML page that automatically obtains and checks the iOS version, determines whether it falls inside the Coruna attack range, and if it does, guides the user to upgrade the phone OS. Do not mention iVerify’s disclosure. Warn users of the risks fully and give advice. Plain, professional color scheme. Review and polish the text from an MIIT perspective; beyond basic upgrade guidance, include Apple’s official links and contacts — on major version 15, 15.8.7 and later are safe; on 16, 16.7.5 and later are safe; on 17, 17.3 and later are safe; below 13 is out of scope. Footer notice: this web tool is published by the MIIT Cybersecurity Threat and Vulnerability Information Sharing Platform & generated by Antiy Landi threat-detection analysis (AI) vertical model.
Plan first, then dispatch sub-agents to work in parallel.Fetches the iVerify blog → extracts Coruna’s version attack range iOS 13–17.2.1
→ Lists a 5-item task plan accordinglyParallel Build
Once the plan is set, two sub-agents execute separately:
Plan first, then dispatch sub-agents to work in parallel.Sub-agent 1: HTML page structure and color design
→ Sub-agent 2: version-detection and risk-judgment logic
→ Merged into a single-file toolCompliant Delivery
The publisher’s compliance review pushes the tool from "works" to "distributable":
(the same instruction still running, no new input)Polishes the copy from an MIIT perspective
→ Adds Apple’s official upgrade links: 15 → 15.8.7+ · 16 → 16.7.5+ · 17 → 17.3+ are safe; below 13 out of scope
→ Footer attribution (publisher & generator) → a zero-dependency single file, distributable offlineTry it yourself
To reproduce, copy the instruction from that day in AVL Code (replace the placeholders with your intelligence source and thresholds):
Based on the information at <threat-intel source URL>. Create an HTML interface that automatically fetches and detects the iOS version, determines whether it is within <attacker codename>’s attack range, and if so guides the user through upgrading the phone’s operating system. Do not mention <the intelligence source>’s disclosure. Adequately warn users of the risk and give recommendations. Keep the color scheme plain and professional. Review and polish the wording from the MIIT’s perspective; for the upgrade, besides basic guidance, include Apple’s official link and contact information. For major version 15, <15.x safe version> and later are safe; for major version 16, <16.x safe version> and later are safe; for major version 17, <17.x safe version> and later are safe; versions below 13 are outside the scope of this check; footer note: <publisher attribution & generator attribution>. Make a plan first, then dispatch sub-agents to work in parallel. - This session export contains no tool-call details (no code diffs, no per-step return values), so the duo right column’s action granularity stops at "sub-agent output → merged single file"; the specific five-state naming, UA parsing and three-segment comparison code details have no first-hand session evidence — defer to the case’s existing data and the published online tool. The session contains no timing records either.
Next question: When the next vulnerability disclosure lands, can you swap the new safe-version thresholds into this single-file tool and publish again the same day?
