Malicious prompts and drainers

EN source master · P03-L05 · needs_review

Offline/read-only study only. Never provide secrets, passwords or authentication codes. No wallet connection, real approval, live revocation, transaction signature, transfer, funds or trade. Visuals are specifications only.

A drainer-style request is assessed through the capability it asks for, not its reassuring caption. Evidence of dangerous scope can justify stopping while execution and human intent remain unresolved.

Begin with the learner's stated purpose

The fixture's intended action is reading a public balance, requiring no authorization. R1 nevertheless asks for an allowance; R2 requests a direct transfer; R3 omits the effects entirely. Compare these capabilities to the stated purpose. This is not a test of whether the page uses alarming words: it is a test of whether the requested effects are justified and understood.

Read actual authority

ERC-20 permissions name a spender and amount [ERC20]. Permit-shaped messages can authorize allowances under applicable signed-approval rules [PERMIT]. Transaction instructions can instead request movement directly [ETH_TX]. None of these forms automatically identifies a malicious person. A legitimate application can use approvals, and an approval request alone is not proof of malicious intent.

The fixture makes the mismatch explicit: “view balance” versus permission for 1000 units. That supports a capability/purpose mismatch under its assumptions. It does not supply a signature, consumed message or transfer result. Report “the request exceeds the stipulated read-only purpose,” not “the user was drained.”

Treat opacity as unresolved

R3's opaque summary cannot be graded as harmless because the caption says verify. UNKNOWN effects are a stopping reason in this rehearsal; they are not an invitation to sign and observe what happens. A simulation or decoded summary, if supplied, would have a source, method, state context and coverage. This fixture does not fabricate a successful safety simulation.

R4's timer creates pressure but supplies no authorization need. Countdown language changes none of the missing evidence. Record it as part of the prompt while keeping the operator's identity and motive unresolved.

Preserve a safe record

Write a sanitized requested-capability table. Keep exact fixture IDs, intended purpose, requested authority, mismatch and missing outcome evidence. OBSERVED is the prompt summary, INFERRED is the scope mismatch, UNKNOWN is execution and operator identity, and INSUFFICIENT EVIDENCE applies to named-human blame or confirmed asset loss. No malware is generated, downloaded or run.

• Capability: effect an authorization could permit.
• Purpose mismatch: scope exceeding stipulated user intent.
• Opaque request: insufficiently decoded effects.
• Drainer-style pattern: descriptive request behavior, not verified person attribution.

ILLUSTRATIVE offline prompt cards; no signable bytes. Intended purpose: view public balance. R1 caption ‘verify wallet’, allowance-shaped request TOKEN-S/OWNER-A/SPENDER-B for 1000 whole fixture units. R2 caption ‘claim’, direct transfer request 7 SIM units to SIM-C. R3 caption ‘verify’, effects UNKNOWN. R4 timer ‘act now’. No authorization or execution record.

Transaction-request timeline with intent at start and R1/R2/R3 as separate capability cards. Mark mismatch/unknown effects, then an offline STOP decision. Keep executed-result lane empty, not a fabricated loss graph.

The stipulated prompt fields and inferred purpose/capability mismatches.

Actual malware execution, signature production, theft, malicious human intent or operator identity.

• Signing to discover effects.
• Calling every approval malicious.
• Treating pressure/caption as technical justification.
• Equating a risky request with observed loss.

For R1–R4, record intended purpose, requested effect, mismatch, evidence state and missing input. Write a safe offline decision for R3 and rewrite ‘the attacker stole seven units’ using only these cards.

Submit a table and bounded conclusion using only supplied offline material. Editorial time allocation: study 12 min, exercise 8 min, correction/quiz 10 min.

• Name intent.
• Read scope independent of caption.
• Pause if effects unresolved.
• Preserve sanitized request, not secret/signature.
• Separate risky capability and actual outcome.

Prompt assessment compares intended purpose with requested effects. Unsupported scope or unknown effects can justify stopping without inventing execution, losses or human attribution.

• Identify a harmful request from a sanitized transaction example
• Compare sanitized effects with claimed purpose.
• Identify unsafe scope without asserting attacker identity or executed loss.

P03-L06 after prerequisite and correction review.

NONE in authoritative catalog. Provided offline data suffice; no product purchase or wallet operation required.

• [ERC20] ERC-20 token standard — approve, allowance and transferFrom for compliant interfaces.
• [PERMIT] ERC-2612 signed approvals — Permit allowance authorization with owner, spender, value, nonce and deadline.
• [ETH_TX] Ethereum transactions — Signed instructions and inclusion distinct from submission.

Documentation explains mechanisms. Historical records retain their declared source class. Source inspection is not independent editorial acceptance.