I think the OP may not realize that most of the people outside of Shuffle don't have any idea what he is referring to. I will try to clarify. Shuffle told us for the first half of the year that affiliate wager would be the biggest factor along side personal wager when it came to airdrop 2. I know this because I was told over and over again that my AD2 would be massive. (I did not get an AD2 but that is another story). As it got closer to the allocation announcement, Shuffle began to promote their lottery and started telling us that staking and wagering in SHFL was now the number one factor in AD2 allocations. Meaning the people who spent time and money collecting affiliates and encouraging them to wager, all with the idea that this would be boosting their airdrop significantly are left with nothing more than what they would have received just wagering on their own.
The entire shuffle contract is ripe for exploiting they have every hook baited.
https://github.com/4eckd/Shuffle.com-Airdrop-Scam/blob/master/porter_analysis.md# Analysis of Porter Folder and Related Contracts
## Overview
The Porter folder contains several decompiled contract files and bytecode that appear to be part of a sophisticated scam operation. These files represent different components of a system designed to facilitate token theft through various deceptive mechanisms.
## Key Components
### 1. PorterRobinson File
This file contains multiple transaction hashes and contract addresses, along with decompiled code for a contract that acts as a "proxy" or "router" for token transfers. The key functionality is:
```solidity
def transfer(address _to, uint256 _value) payable:
require calldata.size - 4 >=′ 32
mem[64] = ceil32(calldata.size) + 128
mem[128 len calldata.size] = call.data[0 len calldata.size]
mem[calldata.size + 128] = 0
idx = 0
while idx < calldata.size - 36 / 128:
_12 = mem[64]
mem[4] = mem[(32 * idx + (calldata.size - 36 / 128)) + 164]
mem[36] = mem[(32 * idx + (Mask(249, 7, calldata.size - 36) >> 6)) + 164]
call mem[(32 * idx) + 164].transferFrom(address from, address to, uint256 tokens) with:
gas gas_remaining wei
args mem[(32 * idx + (calldata.size - 36 / 128)) + 164], mem[(32 * idx + (Mask(249, 7, calldata.size - 36) >> 6)) + 164], mem[(32 * idx + (3 * calldata.size - 36 / 128)) + 164]
```
This code takes input data and uses it to make external calls to other contracts' `transferFrom` functions, potentially allowing the contract to act as a proxy for token transfers.
### 2. Contract Addresses
The file references several contract addresses:
- `0x6B3C00E22C7413aC6903B044Ac44E9b96F982152` (PorterRobinson)
- `0xDB9541E87656E9D2F36f81A0579161BD2ddD118A` (AlpacaMain3)
- `0x0E4a76c1ED2eA52804c4F13f344C18C4fBA8c3b2` (CA - Contract Address)
- `0xDE998fFe15F487C7F792e4c16f8cf3601b5acaef` (From address)
- `0x557c7ddd0867ed6ceae3a4aeb830966c5c81061e` (Signature)
- `0x23d16c13642f9aadd388f51841cb0ff0a360ef93` (Signature)
- `0x02a16b9bfe721c68d52116f62794080c1f542f13` (Signature)
- `0xdac17f958d2ee523a2206206994597c13d831ec7` (USDT token address)
- `0x23d9e6267ed958f16dc1a53c207ab2f687c42ff0` (Contract address)
### 3. Transaction Hashes
Several transaction hashes are listed:
- `0xd37a6037a92216b50b955fa98369f8086dea8bbed18f80e0d70790bb94db9287`
- `0x433cbe253e5dd138555ffd8e02299d04eefe41a52acf7e0326fe13be7f7db2e4`
- `0x0c94bbc9c18c007894ca6e33541c50f74c3097c67f1d24b2102132ec279f4cce`
- `0xc947b777280fad88a3a70efbf73f8a683e452c6e607922ef784baa00744ed6c0`
- `0x3d9f6583e81e2ada97913c05efd5e28f51be3035d558d324d6dfc14473ff7cb1`
- `0xa9a2b2df545937da89ebf7f297a9109e6b5f32376ec11252475fcf95636eb7b5`
### 4. Other Files in the Porter Folder
1. **0x02a** - A minimal contract with just a fallback function that reverts
2. **0x0e4a** - Contains the same transfer function as in PorterRobinson
3. **0x231** - Another minimal contract with just a fallback function
4. **0x557** - A fake ERC-20 token implementation with incorrect event parameter ordering
5. **0xdac** - A more complex ERC-20 token implementation (appears to be a USDT clone)
6. **CA 0x23d9** - Bytecode for a contract that implements ERC-20 functions
## Relationship Between Components
### The Scam Architecture
Based on the files and code examined, this appears to be a sophisticated token theft operation with the following components:
1. **Fake Token Contracts** (0x557, CA 0x23d9)
- Implement the ERC-20 interface but with incorrect event parameter ordering
- Don't actually transfer tokens when transfer functions are called
- Emit misleading events that make it appear as if transfers are happening
2. **Router/Proxy Contract** (PorterRobinson, 0x0e4a)
- Acts as an intermediary that can call transferFrom on other contracts
- Can be used to execute batch transfers or complex operations
- Potentially used to obfuscate the flow of tokens
3. **USDT Clone** (0xdac)
- A more sophisticated contract that mimics USDT functionality
- Includes features like blacklisting, pausing, and fee mechanisms
- Could be used to create a convincing fake token
### Transaction Flow
The transaction hashes and addresses suggest a flow where:
1. A user interacts with what they believe is a legitimate token contract
2. The router contract (PorterRobinson) intercepts these calls
3. Instead of performing the expected operation, it calls transferFrom on the user's legitimate tokens
4. The fake token contracts emit events that make it appear as if the expected operation occurred
5. In reality, the user's actual tokens have been transferred to the attacker
### Analysis of Transaction 0x3d9f6583e81e2ada97913c05efd5e28f51be3035d558d324d6dfc14473ff7cb1
Examining this specific transaction reveals the scam in action:
1. **Mass Token Transfers**: In a single transaction, the scam contract triggered 44 separate token transfers from different victim addresses to different recipient addresses.
2. **Multiple Token Types**: The attack involved transfers of at least 4 different token types:
- USDT (Tether)
- Three different custom ERC-20 tokens at addresses 0x02a16b9b..., 0x23d16c13..., and 0x23d9e626...
3. **Signature Mechanism**: The transaction used the addresses labeled as "Signatures" (0x557c7ddd..., 0x23d16c13..., 0x02a16b9b...) to authorize the transfers, suggesting a sophisticated approval/signature mechanism.
4. **Proxy Contract Execution**: The transaction was executed through the proxy contract at 0x0E4a76c1..., which called transferFrom on multiple victim addresses.
5. **Deceptive Event Emissions**: Each transfer generated a Transfer event with the correct event signature (0xddf252ad1be2c89b69c2b068fc378daa952ba7f163c4a11628f55a4df523b3ef) but with parameters in an order that would confuse blockchain explorers.
This transaction demonstrates how the scam was able to drain tokens from multiple victims in a single transaction, making it highly efficient and difficult to detect in real-time.
## Connection to Previously Analyzed Contracts
The contracts in the Porter folder share several similarities with the previously analyzed contracts:
1. **Incorrect Event Parameter Ordering**
- Both the Porter contracts and previously analyzed contracts emit events with incorrect parameter ordering
- This makes blockchain explorers display misleading information
2. **Non-functional Token Transfers**
- Both sets of contracts have transfer functions that don't actually transfer tokens
- They emit events to make it appear as if transfers occurred
3. **CREATE2 Pattern**
- While not explicitly visible in all Porter files, the bytecode in CA 0x23d9 contains patterns consistent with the CREATE2 deployment seen in previous contracts
4. **Deceptive ERC-20 Implementation**
- Both implement the ERC-20 interface in a way that appears legitimate but functions maliciously
5. **Mass Transfer Capability**
- The ability to execute multiple transfers in a single transaction is a common feature
- This allows for efficient draining of victim accounts once approvals are obtained
## Conclusion
The Porter folder contains components of a sophisticated token theft operation that uses fake ERC-20 implementations, proxy contracts, and deceptive event emissions to steal users' tokens while making it appear as if legitimate transactions are occurring.
This system is likely part of the same family of scam contracts previously analyzed, representing different components or variations of the same underlying scam architecture. The presence of transaction hashes and multiple contract addresses suggests this was an active operation, not just proof-of-concept code.
The examination of transaction 0x3d9f6583e8... confirms that this was an active scam that successfully drained tokens from multiple victims simultaneously. The sophistication of the attack - using proxy contracts, fake tokens, deceptive event emissions, and batch processing - makes this a particularly dangerous scam that would be difficult for average users to detect or prevent once they've granted approvals to the malicious contracts.
