General info

Connection
Attacker address
Attacker pkey

Utils

Generate random transactions	Number of transactions:
Regular transaction	From (pkey): To: Value (Wei):
Remix IDE	https://remix.ethereum.org To deploy the contract on your Hardhat network: "Deploy and run transactions" (fourth item from the top left) > "Environment" > "Hardhat provider". Maybe an exception to allow mixed content (on Firefox, click on the TLS padlock and allow insecure content) is needed
Deploy smart contract	JSON interface (ABI): Bytecode: Constructor arguments (comma separated - leave blank if void): Output:

Vuln 1: Bad Randomness

Pseudorandom number generation on the blockchain is generally unsafe. There are a number of reasons for this, including:

The blockchain does not provide any cryptographically secure source of randomness. Block hashes in isolation are cryptographically random, however, a malicious miner can modify block headers, introduce additional transactions, and choose not to publish blocks in order to influence the resulting hashes. Therefore, miner-influenced values like block hashes and timestamps should never be used as a source of randomness.
Everything in a contract is publicly visible. Random numbers cannot be generated or stored in the contract until after all lottery entries have been stored.
Computers will always be faster than the blockchain. Any number that the contract could generate can potentially be precalculated off-chain before the end of the block.

A common workaround for the lack of on-chain randomness is using a commit and reveal scheme. Here, each user submits the hash of their secret number. When the time comes for the random number to be generated, each user sends their secret number to the contract which then verifies it matches the hash submitted earlier and xors them together. Therefore no participant can observe how their contribution will affect the end result until after everyone has already committed to a value. However, this is also vulnerable to DoS attacks, since the last person to reveal can choose to never submit their secret. Even if the contract is allowed to move forward without everyone's secrets, this gives them influence over the end result. In general, we do not recommend commit and reveal schemes.

Contract address
Contract methods
Call contract (no state alter)	Method name (w/o parentheses): Args (comma-separated):
Send to contract (alters state)	Method name (w/o parentheses): Args (comma-separated): Value (Wei):
Contract output

(ATTACKER!) Contract address
(ATTACKER!) Contract methods
(ATTACKER!) Send to contract (alters state)	Method name (w/o parentheses): Args (comma-separated): Value (Wei):
(ATTACKER!) Contract output

Vuln 3: Contracts can be forced to receive ether

In certain circunstances, contracts can be forced to receive ether without triggering any code. This should be considered by the contract developers in order to avoid breaking important invariants in their code.

Contract address
Contract methods
Call contract (no state alter)	Method name (w/o parentheses): Args (comma-separated):
Send to contract (alters state)	Method name (w/o parentheses): Args (comma-separated): Value (Wei):
Contract output

(ATTACKER!) Contract address
(ATTACKER!) Contract methods
(ATTACKER!) Send to contract (alters state)	Method name (w/o parentheses): Args (comma-separated): Value (Wei):
(ATTACKER!) Contract output

Vuln 4: Incorrect interface

A contract interface defines functions with a different type signature than the implementation, causing two different method id's to be created. As a result, when the interfact is called, the fallback method will be executed.

Contract address
Contract methods
Send to contract (alters state)	Method name (w/o parentheses): Args (comma-separated): Value (Wei):
Contract output

Vuln 5: Integer overflow

It is possible to cause add and sub to overflow (or underflow) on any type of integer in Solidity.

Contract address
Contract methods
Send to contract (alters state)	Method name (w/o parentheses): Args (comma-separated): Value (Wei):
Contract output

Vuln 7: Re-entrancy

A state variable is changed after a contract uses call.value. The attacker uses a fallback function—which is automatically executed after Ether is transferred from the targeted contract—to execute the vulnerable function again, before the state variable is changed.

Contract address
Contract methods
Call contract (no state alter)	Method name (w/o parentheses): Args (comma-separated):
Send to contract (alters state)	Method name (w/o parentheses): Args (comma-separated): Value (Wei):
Contract output

(ATTACKER!) Contract address
(ATTACKER!) Contract methods
(ATTACKER!) Send to contract (alters state)	Method name (w/o parentheses): Args (comma-separated): Value (Wei):
(ATTACKER!) Contract output

Vuln 8: Unchecked external call

Certain Solidity operations known as "external calls", require the developer to manually ensure that the operation succeeded. This is in contrast to operations which throw an exception on failure. If an external call fails, but is not checked, the contract will continue execution as if the call succeeded. This will likely result in buggy and potentially exploitable behavior from the contract.

Contract address
Contract methods
Call contract (no state alter)	Method name (w/o parentheses): Args (comma-separated):
Send to contract (alters state)	Method name (w/o parentheses): Args (comma-separated): Value (Wei):
Contract output

(ATTACKER!) Contract address
(ATTACKER!) Contract methods
(ATTACKER!) Send to contract (alters state)	Method name (w/o parentheses): Args (comma-separated): Value (Wei):
(ATTACKER!) Contract output

Vuln 9: Unprotected function

Missing (or incorrectly used) modifier on a function allows an attacker to use sensitive functionality in the contract.

Contract address
Contract methods
Call contract (no state alter)	Method name (w/o parentheses): Args (comma-separated):
Send to contract (alters state)	Method name (w/o parentheses): Args (comma-separated): Value (Wei):
Contract output

Vuln 10: Variable Shadowing

Variable shadowing occurs when a variable declared within a certain scope (decision block, method, or inner class) has the same name as a variable declared in an outer scope.

Contract address
Contract methods
Call contract (no state alter)	Method name (w/o parentheses): Args (comma-separated):
Send to contract (alters state)	Method name (w/o parentheses): Args (comma-separated): Value (Wei):
Contract output

Vuln 11: Wrong constructor name

A function intended to be a constructor is named incorrectly, which causes it to end up in the runtime bytecode instead of being a constructor.

Contract address
Contract methods
Call contract (no state alter)	Method name (w/o parentheses): Args (comma-separated):
Send to contract (alters state)	Method name (w/o parentheses): Args (comma-separated): Value (Wei):
Contract output