In 2017, a customer called at 5 pm. They had a possible six figure hardware sale, but their hardware was too slow. They had one more chance 24 hours from now, if I could make it go... 1/18 The total of my embedded software experience was fooling around with an Arduino. I'd never written assembly before and never seen this processor family.

The code to be sped up ran on three cores in handwritten assembly, and been optimized by several people over years.

2/18

Things I tell people about AMMs:

(running list) 1. You can get all the volume you want out of an AMM if your prices are wrong.

I have had enough.

It is possible - barely - to securely do onchain multisig stuff. Most have no idea how much work.

The problem is the tools. The only way to be secure is to wire together many different tools, use them painfully, and never make a mistake.

Rethink time🧵 Our current tools worship flexibility, extendability, composability, and minimal gas use.

It's time to focus on action visibility at all layers, making mistakes and attacks recoverable, and out of the box easy security.

A sneaky scam coin has been yoinking its tokens right out of people's wallets, while simultaneously avoiding detection by scam coin detection services.

Let's break down how it cloaks its shenanigans. 1/8 Thanks to yourfriend for noticing this! 2/8

https://x.com/yourfriend_btc/status/1851707644764991927

Yesterday's sophisticated 50 million Radiant Capital hack happened after attacker's trojaned the computers of multiple team members.

Team members saw and verified good multisig data on screens, but their hardware wallets signed evil data. 1/7 The hardware wallets actually signed `transferOwnership()`, giving control of the lending pool to the attackers.

The attackers then integrated these signatures into their attack, so that the transfer of ownership, contract upgrades, and initial theft all occurred atomically. 2/7

Here's how CertiK's 3 million dollar hack on Kracken worked.

The core trick is that the overall blockchain transaction must succeed in order for the reverted deposit to count. So the attacker raw external called their own contract and ignored their own later revert. 1/n At this point we had a transaction trace with a transaction to the deposit contract, that was inside a successful transaction. And that's what Kracken was looking for.

2/n

Yesterday's uwulend 19 million dollar hack involved such a complex attack, combined with such a pile of contract stupidity, that I've not seen a writeup yet that completely explains the attack.

🧵 1/n The price oracle used took 11 different prices, and used the median price as the price oracle. However, 5 of these prices were spot prices and directly under the control of the attacker.

This meant that only one EMA price needed to be manipulated. 2/n

Live tweeting designing a better exchange rate function for vaults.

I want one that changes per block, stops inflation attacks, is gas cheap, spreads out bursts of yield, can be updated in the middle, is self contained, and never overshoots. 🧵 This same design should work for both exchange rate tokens with fixed amounts and for rebasing tokens with changing total supply.

Rebasing tokens really just hide fixed credits and a changing exchange rates inside them, so the same base code should work for both. 2/n

Yesterday's complete hack of Wise Lending was far more complex than reported. Very worth examining.

The protocol had added explicit defenses against this style of attack, which the attack then either bypassed or used against the protocol. 🧵 1/21 A rounding donation attack requires the things:

1) A way to get one key value to empty / almost empty
2) A way to massively inflate another key number
3) A way to exploit the resulting rounding errors

2/21

Over the past two weeks I have been deep diving into Curve's price oracles and have found extremely strange behavior.

The oracles don't act like you think they do. They are far more manipulatable than expected. And can be wrong in normal life.

Mega 👉🧵 TLDR: An attacker only needs a single extra block in most pools to manipulate the Curve price_oracle 10x-500x higher. This manipulation can be hidden such that there is no possible way to look at the pool and know that it is being manipulated. 2/22

Heads up! Some Curve ETH pools have a major bug that allows an attacker to manipulate the virtual_price.

This includes the largest pool on Curve.

1/5 The bugged remove liquidity methods give the attacker execution, while the balances and total supply are in a partially updated state.

If an attacker then calls your protocol, and your protocol calls get_virtual_price, the price will be computed with bad data. 2/5

There were two root causes of the Hundred Finance attack.

First, the project setup two wBTC cTokens, one of which was used by the UI, one of which was empty.

1/4

https://twitter.com/danielvf/status/1647291784848867330

Secondly, after the attacker donated to the pool, the exchange rate was massively inflated. redeemUnderlying wrongly rounded down on the tokens to remove from the mini attack contract.

It only removed 50% of the "shares" , while sending the whole requested balance.

2/5

The single greatest thing that has ever happened for EVM security is the OpenZeppelin contract library.

Its two current current maintainers @frangio_ and @Amxx are unsung heroes of the the security space.

But there's something you may not realize. 1/6 @frangio_ @Amxx Time and time again, I've been blow away at how fast the maintainers react to new safety problems, and how deep they dive to get things perfect

For example, after this tweet, they had a better API PR within hours that was merged the next day. 2/6

https://twitter.com/danielvf/status/1572963306725318657

The recent hacks on several rebasing, fee-on-transfers tokens happened because the tokens were "cheating" by rebasing out far more dollars than the transfer fees they charged.

1/5 The attacks were designed to exploit this behavior by alternately acquiring and burning the token. These huge fees caused massive over-rebasing. In the end the attacker used the extra coins to run away with all the ETH in the coin's uniswap pool. 2/5

In a dazzling reverse hack, a substantial chunk of the Playtpus hack stolen funds have been recovered.

Here's how it worked: (1/4) The attacker forgot to code any way collect the funds after stealing them, so the funds were locked in the attack contract.

They also neglected Flash Loan 101 and allowed anyone to call the flash loan callback code. No check that they had started the flash loan. 2/4

Last night's hack of Arbitrum USDS (9.8 billion created) was caused by a bug in auto-changing users between internal accounting systems.

The code half changed the account to the new style, then used that half data to calculate the remaining half of the switch over.

1/5 USDS has at least three different accounting systems, two separate auto-migration systems, and all share the same variables, just interpret their meaning differently. Thus, all account variables have to be updated together in order to accurately calculate a user's balance.

2/5

The 750 ETH hack from EFLeverVault a few hours ago happened because the contract did not verify that flashloan callbacks where actually initiated by the protocol, allowing the attacker to tell the protocol to withdraw large amounts of funds. 1/4 The EFLeverVault handles withdraws by making a flash loan to itself for that amount, when it receives the flash loan, it withdraws that amount of funds, and leaves it in eth on the contract. After the flash loan is over, the contracts sends all ETH on the contract to user. 2/4

Here's the story on how reporting yesterday's deployer timelock takeover issue to projects went. 1/18 The weekend after I found the config issue, I fired up google's bigtable ethereum database and searched the last 400 days for contracts that had granted the timelock admin power, never revoked it, and had at least one timelock execution. Same query on Dune for Poly, BSC. 2/18

Found a config bug in multiple projects, totaling billions of dollars in assets, allowing a single key to take over all powers from governance and multi-sigs! 1/7 Best practice for securing admin powers is to have contracts owned by a timelock, controlled by a multisig or governance voting.

Multiple key holders required for an action drastically mitigates keyholder hacks, evil keyholder, and keyholder coercion. 2/7

Here’s how signature malleability attacks work.

Two attacks.

If a user signs the same message multiple times, they get a different signature each time. If your code uses a signature as an identifier for blocking actions, users can repeat that action. 1/3 In the above case, the user can keep calling `giveMoney` with a new signature each time and drain the contract.

2/5

Had a fantastic weekend doing the @paradigm_ctf challenge.

Here's how I solved "Vanity", in which you needed a valid signature from an address with 16 leading zeros:

1/n @paradigm_ctf The signature "checker" allows calls to other contracts, and sends the signature to it, then checks the response.

Since it is impossible to deploy a contract with the required number of zeros, I realized we could talk to a precompile instead. 2/n