Nat Chin

When Bitwise NOT breaks Differential Tests

Calvin Tran — Tue, 28 Apr 2026 15:49:43 -0400

When you build your test suite to work for you, it really works.

In a recent engagement, I used differential testing to verify if two implementations of the same logic—one in Golang, one in Solidity—were actually identical. This was a perfect use-case for differential fuzzing - logic that looks the same, under manual review. But looks aren’t everything.

To find them, I built a “fuzzing harness.” Imagine a monkey smashing a keyboard, taking that random input, and feeding it to the equivalent program in Solidity and Golang. If the Go version succeed on the input but the Solidity version hates it (or vice-versa), the fuzzer errors.

Diggin’ into the code

The goal was for these two implementations to be identical.

Golang Original:

// ensure MAP_ANONYMOUS is set and fd == -1
if (flags.val()&0x20) == 0 || fd != u64Mask() {
 addr = u64Mask()
 errCode = toU64(0x4d) // no error
}

Solidity Original:

switch or(iszero(and(flags, 0x20)), not(eq(fd, u64Mask())))
 case 1 {
 addr := u64Mask()
 errCode := toU64(0x4d)
}

Eureka….or kind of

At a high level, both codebases were intended to return 1 on their first lines, to enter the if/switch statement. Instead, the program produced two separate numeric outputs, which was miscalculated. The fuzzer had found a deviation in which one of the calculations uses a padded variable, causing a discrepancy.

Step	Golang Logic	Solidity Logic	Match?
1. Check Flags	`31&0x20 ==0 -> 1`	`isZero(and(31, 0x20)) -> 1`	✅
2. Equality Check **	`fd == u64Mask() = 1`	`eq(18446744073709551551, u64Mask()) = 0000000000000000000000000000000000000000000000000000000000000000`	❓
3. The NOT	Result is already `1`	`1111111111111111111111111111111111111111111111111111111111111111 -> 0xff.ff`	❌

*Note: Step 2 in Golang logic combines step 2 and 3 in one. This is why the result is already 1.

What happened?

In Golang, the result of the check is a literal 1. The logic is only a single bit - this is expected behaviour.

In Yul, the not() operator is applied bitwise. When the equality check eq(fd, u64Mask()) returned a 0, it was interpreted as 00...00. Applying the not() operator on the 32 byte word of zeroes, flipped every single bit.

The result in Solidity wasn’t a 1 - it was a 1111111111111111111111111111111111111111111111111111111111111111.

Because the Solidity code used a switch statement, which expected a result of 1, the control flow did not enter the branch. In Golang, the same path resulted in a 1, which ran the associated code. This resulted in the final result of both implementations to be mismatched.

Evolution of the Fuzzer

The fuzzer went through four distinct iterations:

V0 (Sanity Check): - Simple success/failure check - if one version reverts with input, both must revert and vice versa.
V0.5 (Error Matching): - Tightened constraints. If both versions fail, the error codes must match.
V1 (Input Targeting): - Defined specific numeric ranges for inputs to ensure that the fuzzer could explore additional flows.
V2 (Coverage Bumper): - Analyzed branch coverage of unit tests, and realized that this if statement had no coverage. I manually seeded the fuzzer with inputs that should trigger this statement. The fuzzer found the deviation in seconds

Smart Dumb Monkey-Smashing-Keyboard

I mentioned that fuzzing is like a monkey smashing a keyboard, but a “dumb” monkey uses input space inefficiently. If you’re testing liquidity pools or low-level masks, a random uint256 will almost always just trigger either the same happy paths already discovered, or generic “Balance too low” or more likely, a series of reverts that causes the fuzzer to get nowhere.

A “Smart” Fuzzer (V2) uses directed input generation. By constraining the “monkey” to smash keys within specific numeric ranges (like values just above or below u64Mask), we maximize coveraged reached by the fuzzer.

This is the intersection of security research and development: knowing where the code is likely to have issues and guiding the tools to look there. It is highly improbable the fuzzer would have found this specific bit-flip on its own without those manual adjustments to the harness. It is also highly improbable that this bug would be found via manual review.

Lessons for the Road

Logical vs. Bitwise: In Yul, always use iszero(x) for negation. Avoid not() unless you are actually manipulating bits.
Stop and think: Focus on the areas your unit tests don’t reach. Use coverage reports as a gauge for where to target your fuzzer.
Always Deterministic: Never ignore a failed test, especially if it’s only sometimes fails. If any test fails once, you’re likely sitting on a bug. Understand it. Investigate it.

Curvance Invariants Unleashed

Calvin Tran — Tue, 30 Apr 2024 15:46:49 -0400

Initially posted on Trail of Bits Blog: Curvance: Invariants Unleashed

The Ultimate Secure Wallet

Calvin Tran — Tue, 31 Jul 2018 15:40:47 -0400

Initially posted on State Channels Smart Contract: The Ultimate Secure Wallet

Safety has always been a major concern in the cryptocurrency industry. Once in a while, we’ll see cryptocurrency exchanges get hacked for millions of dollars. The concern of security is among one of the top reasons why people are reluctant to get into the cryptocurrency space. At STK, the security and the safety of your assets is always our top priority. Instead of a traditional wallet, we made a choice to use the smart contract and payment channels for our app. Due to the security nature of these contracts, we have not pushed our contracts up to mainnet yet. They will be pushed on mainnet soon after auditing.

Storing Crypto in a Wallet vs a Smart Contract

A crypto wallet is always generated using a private/public key pair. In other words, when you sign up for a new address with something like MyEtherWallet, you will get a “safety package” — containing your private key that you should be keeping safe. With MetaMask, you would have the mnemonic with the 12 seed words. If you forget these, you lose access entirely to your account. If you accidentally make your private key accessible to someone else, this person has full control over your funds.

A smart contract, on the other hand, is different. There is no explicit private/public key differentiation — the address of the contract is the contract’s public key, but the private key is never made available. Unlike a crypto wallet, a smart contract does what its assigned to do, through code. For instance, our STK-smart-contracts is set to interact with only STK tokens. If other ERC20 tokens are sent to the smart contract, they are lost. This contract does not accept ETH transfers — so, if a customer accidentally transfers Ether to the smart contract, our contract will explicitly refuse it and refund it back. The only thing a user would lose is the gas fees for execution of said operation. Our smart contract also specifies that only STACK and User’s address can settle a channel. The settle function controls the movement of STK Tokens through a payment channel. Due to the restriction of changing the state of the channel, once an IOU has been submitted to change the state of a channel, no one can control the refund or transfers of tokens except yourself. The cryptocurrency you own is completely within your control.

Transactions are safer with state channels

In the initialization of a state channel, there are a few addresses that we make use of:

user address: the address of the wallet in which your funds are stored. When a channel is settled and the funds are returned back to the user, the tokens/ETH will be returned to this address. signer address: the private and public key pair generated on your device for signing purposes* recipient address: the address of the STACK’s wallet. When a channel is settled, the IOU amount will be transferred to STACK. channel address: the address of your personal state channel. When you deposit funds, this is where your funds are stored.

For you to sign transactions, the app automatically generates private and public key pairs. All transactions (IOU’s) are signed with this private key. These are only ever used to sign transactions that are sent to the smart contract. STACK never interacts with your signer’s private key. Notice your signer’s key never holds funds. Its only purpose is to sign off-chain transactions.

With the following setup, transactions are safer with state channels, because there is no single point of failure. No matter what tokens there are in our payment channel, the funds inside it are always safe. Even if STK’s backend or database fails or goes down, the user is in complete control of the funds within the state channel.

Network Congestion

Back in December of last year, when Cryptokitties was released officially, the sheer number of transactions on the Ethereum Network skyrocketed and caused complete congestion. A few people in the Reddit AMA asked about the effects of network congestion on our state channels.

We sign the IOU’s off chain with the signer’s public and private key pair. These do not need to interact with the network. When you decide to settle a channel, these transactions will be pushed on-chain. During the settle period, you have the option to transfer any unused tokens back to your address. Your transaction amount will also be transferred to STACK. In other words, the end user is not affected by congestion on the network. This is ultimately safer for customers, because they are not affected by the volatility and the ever-changing block times on the network. To read more about how the IOU and signing off-chain transactions work, check this out.

If you’re intrigued, feel free to check out our crypto beta demo located here: https://www.youtube.com/watch?v=Yhmjks3eFIA, where we go through a live purchase at a local coffee shop.

DeltaHacks Interview

Calvin Tran — Thu, 11 Jan 2018 15:23:03 -0400

Initially posted on Software Hamilton