Ton Vulnerability Scanner

TON Vulnerability Scanner is a community skill for detecting security issues in TON blockchain smart contracts, covering FunC and Tact language analysis, message handling flaws, gas management vulnerabilities, and common TON-specific attack patterns for secure contract development.

What Is This?

Overview

TON Vulnerability Scanner provides guidance on identifying security issues in smart contracts built for The Open Network blockchain. It covers FunC code analysis that detects unsafe patterns in low-level TON contract code including improper cell serialization, Tact language review that examines higher-level contract logic for state management and access control flaws, message handling validation that checks internal and external message processing for missing sender verification, gas management auditing that identifies contracts vulnerable to gas exhaustion or manipulation attacks, and bounce handling review that verifies proper processing of failed message callbacks. The skill helps developers write secure TON contracts.

Who Should Use This

This skill serves TON smart contract developers writing FunC or Tact code, blockchain security auditors reviewing TON protocol contracts, and development teams deploying financial applications on The Open Network.

Why Use It?

Problems It Solves

TON uses an actor model with asynchronous messaging that creates unique vulnerability patterns not found in EVM chains. Message bounce handling mistakes can lead to locked or lost funds. Gas forwarding errors cause dependent transactions to fail silently. FunC low-level cell operations can introduce serialization bugs that corrupt contract state.

Core Highlights

FunC analyzer detects unsafe cell operations and missing checks. Message validator verifies sender authentication on internal messages. Gas auditor identifies forwarding and limit vulnerabilities. Bounce checker reviews failed message callback handling.

How to Use It?

Basic Usage

;; Secure message handler
;; with sender verification
() recv_internal(
  int my_balance,
  int msg_value,
  cell in_msg_full,
  slice in_msg_body
) impure {
  slice cs =
    in_msg_full
    .begin_parse();
  int flags = cs~load_uint(4);

  ;; Check bounced messages
  if (flags & 1) {
    return ();
  }

  slice sender =
    cs~load_msg_addr();
  load_data();

  ;; Verify sender is owner
  throw_unless(401,
    equal_slices(
      sender,
      owner_address));

  int op =
    in_msg_body~load_uint(
      32);

  if (op == op::withdraw) {
    int amount =
      in_msg_body
      ~load_coins();
    throw_unless(402,
      amount <=
        my_balance
        - min_balance);
    send_raw_message(
      build_message(
        sender, amount),
      64);
  }
  save_data();
}

Real-World Examples

;; Gas-safe forwarding
;; with reserve
() forward_with_gas(
  slice dest,
  cell payload,
  int value
) impure {
  ;; Reserve minimum balance
  raw_reserve(
    min_tons_for_storage,
    0);

  var msg = begin_cell()
    .store_uint(0x18, 6)
    .store_slice(dest)
    .store_coins(value)
    .store_uint(1, 107)
    .store_ref(payload)
    .end_cell();

  ;; Mode 128: carry
  ;; remaining balance
  send_raw_message(
    msg, 128);
}

Advanced Tips

Always reserve minimum storage balance before sending messages to prevent contract deletion. Use raw_reserve with mode flags to manage gas forwarding precisely. Validate all external message signatures before processing any state changes.

When to Use It?

Use Cases

Audit a TON wallet contract for message handling and bounce processing vulnerabilities. Review a Jetton token implementation for gas forwarding and balance tracking issues. Scan a TON DeFi protocol for access control and state corruption risks.

Related Topics

TON blockchain, FunC, Tact, smart contract security, message handling, gas management, and blockchain auditing.

Important Notes

Requirements

TON development environment with FunC or Tact compiler for contract compilation and testing. Understanding of the TON actor model including asynchronous message passing between contracts and bounce mechanics. Familiarity with TVM opcodes and cell serialization formats for analyzing low-level contract behavior, storage layout patterns, and message encoding structures.

Usage Recommendations

Do: verify sender address on every internal message handler to prevent unauthorized operations. Reserve minimum storage balance before outgoing messages to prevent contract deletion. Handle bounced messages explicitly to recover funds from failed transfers.

Don't: assume message ordering since TON processes messages asynchronously across shards. Ignore gas forwarding amounts as insufficient gas causes silent transaction failures. Store unbounded data in contract state since TON charges rent for storage and large state increases costs.

Limitations

Scanner patterns are specific to currently known TON vulnerability classes and may not detect novel attack vectors. Cross-contract message flows spanning multiple actors across different shards are inherently difficult to analyze statically due to asynchronous execution ordering. TON protocol updates and TVM version changes may introduce new opcodes or execution behaviors that require updated scanning rules and pattern definitions.