Embedded ARM Development

• Outcome: Pass
• Latest audit: Sep 16, 2026 · 4:41 AM UTC
• Version: 1.0.0

Overview

This is a Chinese embedded ARM reference skill with expected firmware and debugging examples, but some snippets should be reviewed before use on real hardware.

Install only if you want a Chinese embedded ARM reference. Treat code blocks as illustrative: review Flash address bounds, alignment, page coverage, write verification, power-loss safety, and MPU permissions before using them on hardware, because the examples can change firmware or device memory when adapted and run.

A.I.G

Vulnerability Patterns

• Insecure Skill Coding Practices: Finds exploitable flaws such as hardcoded secrets or command injection
• Skill Instruction Hijacking: Alters the agent's session goals or safety constraints when the skill loads
• Agent Memory Poisoning: Writes attacker-controlled rules into memory that affect later sessions
• Remote Payload Retrieval and Execution: Fetches external code whose behavior can change after review
• Embedded Malicious Code: Ships malicious scripts inside the skill and executes them locally

Findings (2)

T09 · Insecure Skill Coding Practices

Warning

• Location: SKILL.md:684

Finding

Insufficient Validation in Flash Erase and Write Routine

Content

View full analysis

Vulnerability Details

File Location: SKILL.md, lines 684–705
Vulnerability Type: Unsafe memory access and unrestricted Flash modification
Risk Level: Medium

c

HAL_StatusTypeDef flash_write(uint32_t addr, uint8_t *data, uint16_t len) {
    HAL_StatusTypeDef status;
    uint32_t page_addr = addr & ~(FLASH_PAGE_SIZE - 1);
    
    HAL_FLASH_Unlock();
    FLASH_EraseInitTypeDef erase;
    erase.TypeErase    = FLASH_TYPEERASE_PAGES;
    erase.PageAddress  = page_addr;
    erase.NbPages      = 1;
    uint32_t error;
    
    status = HAL_FLASHEx_Erase(&erase, &error);
    if (status != HAL_OK) { HAL_FLASH_Lock(); return status; }
    
    for (uint16_t i = 0; i < len; i += 2) {
        uint16_t half_word = *(uint16_t*)(data + i);
        status = HAL_FLASH_Program(FLASH_TYPEPROGRAM_HALFWORD, addr + i, half_word);
        if (status != HAL_OK) break;
    }
    HAL_FLASH_Lock();
    return status;
}

Technical Analysis

The example erases and programs Flash without validating that addr and the entire write range are within an explicitly authorized Flash partition. It also does not verify that the destination address is correctly aligned, that the data fits within the erased page, or that integer arithmetic used to calculate the end address does not overflow.

The loop reads two bytes from data during every iteration. If len is odd, the final iteration dereferences a 16-bit value when only one valid input byte remains, causing a one-byte out-of-bounds read. Depending on the MCU and alignment requirements, the cast and dereference may also cause an unaligned-access fault.

Only the page containing the initial address is erased. A write spanning a page boundary may therefore attempt to program a non-erased page. Conversely, a short partial-page write erases the entire containing page and may destroy unrelated data stored elsewhere in that page.

Attack Path

...[truncated 1613 chars]

Remediation

View remediation

Remediation Suggestions

• Define an explicit writable Flash partition and reject addresses outside its start and end boundaries.
• Calculate the end address with overflow-safe arithmetic before unlocking Flash.
• Require destination alignment appropriate for FLASH_TYPEPROGRAM_HALFWORD.
• Reject odd lengths or safely construct the final half-word using a defined padding value.
• Verify that the complete write fits within the erased page, or erase every required page after validating the complete range.
• For partial-page updates, read the existing page into a bounded RAM buffer, update the intended bytes, erase the page, and restore the complete page.
• Reject a null data pointer when len is nonzero.
• Protect bootloader, option-byte, executable, and security-critical regions with hardware write protection.
• Relock Flash on every exit path and verify the programmed contents before reporting success.
• Use a power-loss-safe format with versioning, checksums, committed-state markers, and redundant slots for persistent configuration.

T09 · Insecure Skill Coding Practices

Note

• Location: SKILL.md:68

Finding

MPU Example Grants Write Access to a Region Presented as Read-Only

Content

View full analysis

Vulnerability Details

File Location: SKILL.md, lines 68–81
Vulnerability Type: Incorrect memory protection configuration
Risk Level: Low

c

MPU_InitStruct.Enable           = MPU_REGION_ENABLE;
MPU_InitStruct.Number           = MPU_REGION_NUMBER0;
MPU_InitStruct.BaseAddress      = 0x20000000;
MPU_InitStruct.Size             = MPU_REGION_SIZE_256KB;
MPU_InitStruct.SubRegionDisable = 0x00;
MPU_InitStruct.TypeExtField     = MPU_TEX_LEVEL0;
MPU_InitStruct.AccessPermission = MPU_REGION_FULL_ACCESS;
MPU_InitStruct.DisableExec      = MPU_INSTRUCTION_ACCESS_DISABLE;
MPU_InitStruct.IsShareable      = MPU_ACCESS_SHAREABLE;
MPU_InitStruct.IsCacheable      = MPU_ACCESS_CACHEABLE;
MPU_InitStruct.IsBufferable     = MPU_ACCESS_BUFFERABLE;
HAL_MPU_ConfigRegion(&MPU_InitStruct);

Technical Analysis

Execute-never protection is enabled, but MPU_REGION_FULL_ACCESS leaves the region writable. This contradicts the surrounding description of the region as read-only and does not provide protection against data modification.

The region also covers 256 KB starting at 0x20000000, which may encompass most or all SRAM on the illustrated target. A single broad full-access region cannot enforce isolation between stacks, application data, privileged state, and security-sensitive buffers.

An MPU can mitigate memory-corruption vulnerabilities only when regions use permissions that match the intended privileged and unprivileged access model. Enabling the MPU while assigning full read/write access may create a false expectation that the represented data is protected.

Attack Path

1. A developer copies the documented MPU configuration into firmware and assumes the target SRAM region is read-only.
2. Another memory-safety defect, such as a buffer overflow or invalid pointer write, provides an attacker with a write primitive.
3. The write targets data within the MPU region.
4. Because the region uses `MPU_R ...[truncated 936 chars]

Remediation

View remediation

Remediation Suggestions

• Select an MPU access-permission constant that actually enforces the intended read-only policy.
• Define the required behavior separately for privileged and unprivileged execution modes.
• Split SRAM into narrowly scoped regions for stacks, immutable data, shared buffers, privileged state, and peripheral-facing DMA buffers.
• Retain execute-never protection for non-code memory.
• Configure guard regions around task stacks where the MPU and RTOS support them.
• Confirm that region bases and sizes satisfy MPU alignment requirements.
• Review overlapping-region priority so that a broader full-access region does not override the intended restriction.
• Add a startup self-test that attempts prohibited accesses and confirms that the expected memory-management fault occurs.
• Correct the accompanying documentation if writable access is intentional, avoiding a misleading claim of read-only protection.

SkillSpector

Vulnerability Patterns

• Data Exfiltration: External Transmission, Env Variable Harvesting, File System Enumeration
• Prompt Injection: Instruction Override, Hidden Instructions, Exfiltration Commands
• Privilege Escalation: Excessive Permissions, Sudo/Root Execution, Credential Access
• Supply Chain: Unpinned Dependencies, External Script Fetching, Obfuscated Code
• Excessive Agency: Unrestricted Tool Access, Autonomous Decision Making, Scope Creep

Findings (3)

Ae4

Medium

• Category: analysis-evasion
• Confidence: 80% confidence

Finding

Suspicious Unicode normalization or mixed-script content

Content

No source excerpt is available for this finding.

Natural-Language Policy Violations

Medium

• Category: Not specified by scanner
• Confidence: 92% confidence

Finding

This markdown skill begins entirely in Chinese and does not indicate that users may choose another language or that the skill is intentionally restricted to a Chinese-speaking audience. Under the language/locale policy, forcing a specific language without user opt-in is a natural-language policy concern.

Content

No source excerpt is available for this finding.

Missing User Warnings

Medium

• Category: Not specified by scanner
• Confidence: 94% confidence

Finding

The flash write example performs page erase and in-place programming of non-volatile memory, which is destructive and can corrupt configuration, calibration data, or firmware-adjacent storage if copied without careful adaptation. Because the markdown presents it as a reusable example without a prominent warning about irreversibility, alignment/length constraints, power-fail risks, and address validation, users may apply it unsafely and brick devices or destroy persistent data.

Content

No source excerpt is available for this finding.

Static analysis

No suspicious patterns detected.