Great write up. I wonder if Coinbase has flagged the USDC that was stolen. Are those currently less-fungible USDCs?
Don't know about USDC, but USDT almost instantly locked the funds, making them unspendable.
Technical Analysis of the Poly Network Hack
11–20 of 35 posts
Re: Technical Analysis of the Poly Network Hack
#12Great write up. I wonder if Coinbase has flagged the USDC that was stolen. Are those currently less-fungible USDCs?
Don't know about USDC, but USDT almost instantly locked the funds, making them unspendable.
Interesting. Do you know the mechanics of how funds get locked? Are they prevented from being transferred on-chain or only from being removed at the USD-USDT edges?
Re: Technical Analysis of the Poly Network Hack
#13What was missing for me in the article is the fact that they don't call a function by name AND by validation of hash. Instead, only by hash( + "(bytes,bytes,uint64)").slice(0,10) which is brute-force-able. Still, this sounds just like one of my worst nightmares. A code in production having bugs that will lose all my money to an untraceable environment (the tornado chain).
Funny tangent about the function hash... I can't tell you the number of man-hours I spent brute-forcing random function names to find the lowest value hash.
Quick background. Back in the pre Flashbot days, the competitive barrier to front running was winning priority gas auctions. Basically whoever was able to bid at the highest gas price would get their transaction mined with first, and would extract the MEV. (Kind of analogous to traditional HFTs fighting to shave off nanoseconds to win a latency-based priority race.)
So you had to make sure that your on-chain smart contract for the front-running bot is an insanely gas optimized as possible. You'd literally pay a thousand times per unit of gas as the average person. Every single byte matters. And one thing about the EVM is that zero bytes in the transaction data cost slightly less than non-zero bytes.
So anyway, in the hot-path of that front-running bot, you'd want to get as many zeros in the method hash as you could. So I'd literally run a GPU to brute force method names.
Re: Technical Analysis of the Poly Network Hack
#14Earlier quoted context omitted.
Don't know about USDC, but USDT almost instantly locked the funds, making them unspendable.
Interesting. Do you know the mechanics of how funds get locked? Are they prevented from being transferred on-chain or only from being removed at the USD-USDT edges?
the smart contract has a blacklist flag that can be activated by the Tether, this prevents on-chain transfers.
https://etherscan.io/token/0xdac17f958d2ee523a2206206994597c...
The USDT will be burned and the USD released to the rightful owner after law/legal approval -- https://twitter.com/paoloardoino/status/1425188386034311168
Re: Technical Analysis of the Poly Network Hack
#15It will never cease to amaze me that someone with the technical chops to pull off an attack worth this much hasn't done the minimum pre-work necessary to get away with the cash or at least some non-trivial amount of it.
They're claiming to be white hat and have given back 250m.
They only started making that claim after foolishly transferring the coins to an address tied to a Binance account.
Re: Technical Analysis of the Poly Network Hack
#16What was missing for me in the article is the fact that they don't call a function by name AND by validation of hash. Instead, only by hash( + "(bytes,bytes,uint64)").slice(0,10) which is brute-force-able. Still, this sounds just like one of my worst nightmares. A code in production having bugs that will lose all my money to an untraceable environment (the tornado chain).
Funny tangent about the function hash... I can't tell you the number of man-hours I spent brute-forcing random function names to find the lowest value hash. Quick background. Back in the pre Flashbot days, the competitive barrier to front running was winning priority gas auctions. Basically whoever was able to bid at the highest gas price would get their transaction mined with first, and would extract the MEV. (Kind…
I am simultaneously stunned at the brilliance of the scheme and the monumental loss of human productivity.
Re: Technical Analysis of the Poly Network Hack
#17What was missing for me in the article is the fact that they don't call a function by name AND by validation of hash. Instead, only by hash( + "(bytes,bytes,uint64)").slice(0,10) which is brute-force-able. Still, this sounds just like one of my worst nightmares. A code in production having bugs that will lose all my money to an untraceable environment (the tornado chain).
Funny tangent about the function hash... I can't tell you the number of man-hours I spent brute-forcing random function names to find the lowest value hash. Quick background. Back in the pre Flashbot days, the competitive barrier to front running was winning priority gas auctions. Basically whoever was able to bid at the highest gas price would get their transaction mined with first, and would extract the MEV. (Kind…
Wouldn't it be cheaper to replace the method id with byte id? No need to follow solidity abi if nobody but you is going to call the contract.
Re: Technical Analysis of the Poly Network Hack
#18Great write up. I wonder if Coinbase has flagged the USDC that was stolen. Are those currently less-fungible USDCs?
Don't know about USDC, but USDT almost instantly locked the funds, making them unspendable.
Does this mean they are lost forever? like burning real bills? Or is there a mechanism to repay the original owners?
Re: Technical Analysis of the Poly Network Hack
#19Earlier quoted context omitted.
Interesting. Do you know the mechanics of how funds get locked? Are they prevented from being transferred on-chain or only from being removed at the USD-USDT edges?
the smart contract has a blacklist flag that can be activated by the Tether, this prevents on-chain transfers. https://etherscan.io/token/0xdac17f958d2ee523a2206206994597c... The USDT will be burned and the USD released to the rightful owner after law/legal approval -- https://twitter.com/paoloardoino/status/1425188386034311168
Wait, so they have the ability to arbitrarily blacklist people from transferring tethers? At this point, is Tether anything other than a weird bank?
Re: Technical Analysis of the Poly Network Hack
#20Earlier quoted context omitted.
Funny tangent about the function hash... I can't tell you the number of man-hours I spent brute-forcing random function names to find the lowest value hash. Quick background. Back in the pre Flashbot days, the competitive barrier to front running was winning priority gas auctions. Basically whoever was able to bid at the highest gas price would get their transaction mined with first, and would extract the MEV. (Kind…
Wouldn't it be cheaper to replace the method id with byte id? No need to follow solidity abi if nobody but you is going to call the contract.
For sure. The biggest challenge is once you leave Solidity entirely, it's hard to do anything but very simple operations. And actually, I did essentially do what you mentioning for our "gas refund" contracts. Basically another trick to cut gas spend is to use the refund the EVM gives for calling contract self-destruct.
You create a bunch of dummy contracts when gas is cheap. Then on your transaction where you're paying a 100x gas price to win the contract, you self-destruct as many contracts as you can to max the refund. However the self-destruct call itself costs gas, so you want to make the call as simple as possible. This is a pretty simple: 1) check caller address, invoke self-destruct. So you'd just write the entire contract directly in EVM byte code instead of using Solidity.