Reentrant attack number on 17 June 2016

Question

This post What was the second vulnerability used in The DAO attack on 17 June 2016? say :

And from the Q&A [...], each of the transactions (the first and second at least from my manual counting) called splitDAO(...) 29 times. But the 29 x splitDAO(...) calls were repeatedly called, creating > 27996 internal transactions, 13996 were non-zero internal transfers. Calculation: 13996 transactions x 258.05656476 ETH = 3,611,759.68038 ethers, which is approximately the 3,641,694.241898506 Ether ($59,578,117.80) was moved to the account 0x304a554a310c7e546dfe434669c62820b7d83490.

But isn't the call depth size max size of Ethereum's call stack capped at 1024 ? Most blog posts says this recursive can only be done ~ 30 times...

Answer 1

This is answered in What was the second vulnerability used in The DAO attack on 17 June 2016? .

What the attacker did was to transfer their tokens from account to account so they could repeatedly call the SplitDAO recursively 29 x something like:

for (i = 1 to 482) {
    call wallet default function () // which performed the following:
        // transfer tokens to another account
        // call splitDAO(...) with recursion to the depth of 29x.
}

From the link above:

It's not so much a vulnerability, but the attack cleverly transferred its DAO tokens between 2 accounts, by using function transfer(address _to, uint256 _amount).

So the fallback function of the attacking contract looks like:

function() {
  transfer DAO tokens to other attacking contract
  invoke splitDAO
}

There were 2 attacking contracts that transferred DAO tokens to each other. When one attacking contract's transaction finished, balances[msg.sender] = 0 would be correctly set, but the tokens had been transferred to the other contract. Now the other contract performs the attack until it's transaction finishes. The attacking contracts alternate.

Source

@Roland's answer mentions how TheDAO could have prevented this.