Ability Analysis

ABILITY_ANALYSIS Skill

Trigger Pattern: Always (Aptos Move) --- foundational security check Inject Into: Breadth agents, depth agents

For every struct defined in the audited modules:

STEP PRIORITY: Steps 2 (Copy Ability Audit) and 6 (Ability Combination Analysis) are where HIGH/CRITICAL severity findings most commonly hide. Do NOT rush these steps. If constrained, skip conditional sections (7) before skipping 2 or 6.

1. Struct Ability Inventory

Enumerate ALL structs defined in the audited modules:

Classification guide:

• Value-bearing: Coins, LP tokens, shares, receipts, vouchers, NFTs --- anything that represents transferable economic value or a claim to value
• Obligation-bearing: Hot potatoes, flash loan receipts, callback obligations, lock receipts --- anything that MUST be consumed before transaction ends
• Resource: Singleton state containers, registries, configuration stores --- things that should exist at most once per address/globally
• Data: Purely informational structs with no security-sensitive lifecycle (events, parameters, intermediate computation results)

For each struct: What abilities does it NEED vs what abilities does it HAVE? Excess abilities are the attack surface.

2. Copy Ability Audit

For each struct with the copy ability:

2a. Value Duplication Check

CRITICAL: copy on a value-bearing type means the value can be duplicated at zero cost. This is the Move equivalent of a double-spend.

Check for each copy struct:

1. Can this struct be copied and then used multiple times? (e.g., copied receipt redeemed twice)
2. Does the module rely on move semantics to enforce single-use? If yes, copy breaks that assumption.
3. Is copy needed for legitimate operations? (e.g., snapshot reads, event emission) --- if not, it should be removed.
4. Trace all functions that accept this struct as a parameter: do they consume (move) or borrow (&) it? If they consume, copy lets callers retain the original.

MANDATORY GREP: Search all .move files for has copy and copy, in struct definitions. For each hit: (1) classify the struct, (2) if value-bearing, mark as FINDING.

2b. Copy-Then-Use Trace

For each copy struct identified as potentially dangerous:

1. Caller obtains instance I of struct S
2. Caller copies: I_copy = copy I
3. Caller uses I in function F1 (consumed/moved)
4. Caller uses I_copy in function F2 (consumed/moved)
5. Impact: {double-spend, double-claim, double-vote, obligation bypass}

Tag: [TRACE:copy S → use1 in F1 → use2 in F2 → impact: {X}]

3. Drop Ability Audit

For each struct with the drop ability:

3a. Obligation Bypass Check

CRITICAL: drop on an obligation-bearing struct means the obligation can be silently discarded. This is the Move equivalent of skipping a required finally-block.

Hot potato pattern check: The hot potato pattern relies on structs having NO drop ability, forcing the caller to pass them to a consuming function. If drop is present, the pattern is broken.

Check for each drop struct:

1. Is this struct a receipt or proof that must be returned to a specific function? (flash loan receipt, lock receipt, callback proof)
2. Does any function create this struct with the expectation that a corresponding "finalize" function will consume it?
3. What state changes happen in the finalize function? If the struct is dropped instead, those state changes never occur.
4. Does dropping this struct leave the protocol in an inconsistent state? (borrowed funds not returned, locks not released, counters not decremented)

3b. Drop-Instead-of-Consume Trace

For each obligation struct:

1. Function F_create creates struct S (e.g., flash_loan returns receipt)
2. EXPECTED: Caller passes S to F_consume (e.g., repay(receipt))
3. ACTUAL (if drop): Caller drops S, F_consume never called
4. Impact: {funds not returned, lock not released, state inconsistent}

Tag: [TRACE:drop obligation S → F_consume skipped → impact: {X}]

4. Store Ability Audit

For each struct with the store ability:

4a. Module Control Escape Check

Check for each store struct:

1. store allows the struct to be placed inside other structs, into Table/SmartTable, or moved to global storage via a wrapping resource. Can an attacker store this struct in their own resource, bypassing module-controlled access?
2. Does the module rely on controlling where instances of this struct live? If instances escape to user-controlled storage, can they be replayed, hoarded, or used out of context?
3. For structs with store but without key: can they be wrapped in a user-defined key struct to achieve unauthorized global storage?
4. If the struct contains mutable references to shared state (e.g., via &mut in the functions that operate on it), does escaping the module allow stale or orphaned references?

4b. Unauthorized Persistence Trace

For structs not intended to persist outside module control:

1. Module M creates struct S with `store` ability
2. Attacker wraps S in their own struct W (has key + store)
3. Attacker calls move_to<W>(@attacker, W { s: obtained_S })
4. S now persists at attacker's address outside M's control
5. Impact: {replay, hoarding, context-escape, stale state}

5. Key Ability Audit

For each struct with the key ability:

5a. Resource Lifecycle Check

Check for each key struct:

1. Who can call move_to for this resource? Is creation properly gated by access control (signer capability, admin checks)?
2. Who can call move_from for this resource? Can an attacker remove a critical resource from an address?
3. Is the resource intended to be a singleton (one per address/globally)? If yes, can an attacker cause duplicate creation or premature deletion?
4. Does the module use exists<S>(addr) checks? Can an attacker manipulate resource existence to bypass guards?
5. For resources published at a shared/module address: what happens if the resource is removed? Does the protocol become non-functional?