On January 3, 2023, the GDS project on Binance Smart Chain was hacked. Soon after that followed the post-mortem articles from:<ul><li>Harbor (<a href="https://medium.com/@lbsmhmdakr17/analysis-of-the-gds-project-flash-loan-exploit-61a5a57a29fd">https://medium.com/@lbsmhmdakr17/analysis-of-the-gds-project-flash-loan-exploit-61a5a57a29fd</a>)</li><li>Numen Cyber Labs: (<a href="https://medium.com/@numencyberlabs/gds-flash-loan-attack-technical-analysis-ae3ceb7a022c">https://medium.com/@numencyberlabs/gds-flash-loan-attack-technical-analysis-ae3ceb7a022c</a>)</li><li>QuillAudits: (<a href="https://quillaudits.medium.com/gds-project-flash-loan-exploit-analysis-quillaudits-7f6b04eee035">https://quillaudits.medium.com/gds-project-flash-loan-exploit-analysis-quillaudits-7f6b04eee035</a>)</li></ul>While all of them more or less wrote the same thing (someone checks for plagiarism? 😉); I do not believe even a single one of them was successful in explaining how the hacker executed his / her work. Quite a shame!How do I know, you wonder 🤔? Well, I am a security researcher in this field. I have spent some time understanding how these hacks are executed and best of all, I try and re-create them so that I exactly know the what and the how!So if you are a smart contract developer, intending to make sure that you write “safe code”, and you are keeping a tab on the hacks that happen; you need to make sure that you understand this hack very carefullyNow, this hack is not one of the biggest hack (in terms of $$ lost); but it is one fine job done over multiple blocks and hence you should understand that this hack is NOT the job of the FLASHLOAN ALONE!The other auditors f***ed up in not being able to understand and explain the hack that was executed over 1370 blocks [24451036 less 24449667 (including the last block)] and NOT through a SINGLE transaction that has been identified.To prove the above, I have documented the exact manner in which the hack was executed, by (a) explaining the events and (b) re-creating this hack.<h1 style="margin-left:0px;">Before Transaction 1:</h1><ul><li>The hacker already had ~19.1 LP tokens in his wallet (<a href="https://bscscan.com/address/0xcF2362B46669E04B16D0780cf9B6e61c82De36a7">0xcF2362B46669E04B16D0780cf9B6e61c82De36a7</a>) and ~6174 USDC in his “Base Attacker” contract (<a href="https://bscscan.com/address/0x16059B0b6842B33c088B3246e5B7AFdDd9DffB4b">0x16059B0b6842B33c088B3246e5B7AFdDd9DffB4b</a>).</li><li>These USDC are then split up equally and transferred in multiple “Attacker” contracts in transaction 1.(starting with this tx:<a href="https://bscscan.com/tx/0x65dbd204503b76074da727039aa17a5a36b57b4317f079dfae416a5c96f0cc9a">https://bscscan.com/tx/0x65dbd204503b76074da727039aa17a5a36b57b4317f079dfae416a5c96f0cc9a</a>)</li></ul><h1 style="margin-left:0px;">Transaction 1 (Epoch Computation Transaction):</h1>The Base Attacker Contract does the following things in a loop for almost 30 times:<ul><li><code>Creates</code> the first “Attacker” contract (eg:<a href="https://bscscan.com/address/0x0f8D735c0b67f845068Bb31684707851f9D2767D">0x0f8D735c0b67f845068Bb31684707851f9D2767D</a>)</li><li><code>Transfers</code> ~0.19 LP tokens to this attacker contract.</li><li><code>Swaps</code> 120USDC from Base Attacker for GDS token and feed into this Attacker Contract</li><li><code>Transfers</code> the GDS Token to the dead account (<a href="https://bscscan.com/address/0x000000000000000000000000000000000000dEaD">0x000000000000000000000000000000000000dEaD</a>) (from the Attacker Contract<code>):</code></li><li><code>Transfers Back</code> 0.19 LP tokens to his wallet.</li><li>Repeating the above steps for the second “attacker” contract and so on for all others.</li></ul><h2 style="margin-left:0px;">Intention behind transaction 1:</h2><figure class="image image_resized" style="width:679.997px;"><img src="https://miro.medium.com/v2/resize:fit:706/1*yzk7JeeJUgZEFgP00H8UDg.png" alt="" loading="lazy"></figure><ul><li>The intention behind this transaction is to exploit a vulnerability in the GDS contract’s “_settlementLpMining” function. [Yes, this was identified by the other auditor’s blog post also]</li><li>The function has a check that the “lastEpoch” of the “from” address should be greater than zero.</li><li>By transferring GDS tokens to a dead account, the contract sets the <code>lastEpoch</code> of the attacker contract to the current <code>epoch</code>(in this case, from 0 to 29). This allows the attacker to use the updated <code>lastEpoch</code>(now equal to the current <code>epoch</code>, 29) to take advantage of the flaw in the contract when the attacker does the transfer in Transaction2.</li><li>This means that if there are LP tokens in the caller’s account (ie the Attacker Contract) and the currentEpoch is greater than the lastEpoch, the “_lpRewardAmount” is calculated and transferred to the caller.</li><li>The transaction 1 sets the first condition true for all attacker contracts in a loop by transferring GDS token to dead account.</li></ul><h1 style="margin-left:0px;">Transaction 2 (Flash Loan Transaction):</h1>The one that is believed to be the only transaction in which the hack was executed. ROFL 🤦‍♂️<ul><li>Take flash loan of all USDC tokens available in the FlashLoan Contract, in this case 2M USDC was borrowed to the Base contract (<a href="https://bscscan.com/address/0x0B995C08ABddC0442BEE87d3a7C96b227f8e7268">0x0B995C08ABddC0442BEE87d3a7C96b227f8e7268</a>).</li><li>In the callback of the flash loan call: - Take another flash loan of ~315k USDC from another source. - Swap 600K USDC for GDS tokens. - Add liquidity to the USDC/ GDS pool to acquire a large amount of LP tokens. - Perform the following steps in the loop for previously created Attackers contracts: 1. Transfer all acquired LP tokens to the previously deployed Attacker 1 contract. 2. Call a function <code>withdraw</code> created in the attacker 1 contract, which does the following: 2.1 Transfer 10000 <code>wei</code> [please note: <code>wei</code> only] of GDS tokens to dead account 2.2 Gets the reward from the GDS token 2.3 Transfer back all LP tokens to the base contract 3. Continue to transfer LP tokens to the next Attacker contracts and call <code>withdraw</code> functions of same.</li></ul><h2 style="margin-left:0px;">Explanation of Transaction 2:</h2>Due to the Transaction 1, the lastEpoch of the caller (Attacker contracts in this case) was set to the currentEpoch. Now when the GDS Tokens is transferred to the dead account, the second condition <code>currentEpoch &gt; lastEpoch[_from]</code> satisfies. This will NOT be possible if the attack was executed ONLY through the flash loan contract. This is where all the other audit companies focused only.And as the large amount of LP tokens are acquired, the calculated rewards are also high and the caller ends up with the good amount of GDS tokens.<h1 style="margin-left:0px;">Code explanation:</h1><ul><li><code>_refreshDestroyMiningAccount</code> will be called in <code>_afterTokenTransfer</code> which eventually gets called after token transfer of GDS.</li><li>Since the <code>to</code> address of the transfer is equal to the dead account, the first branch gets executed.</li><li><code>isOpenLpMining</code> is true at the time of attack, it will enter the nested branch inside and execute <code>_settlementLpMining</code></li><li>Now the first condition gets satisfied after Transaction 1 and the second &amp; third conditions gets satisfied after Transaction 2, the rewards get calculated and the caller is rewarded with GDS tokens. The more LP tokens the caller have, the more rewards is emitted.</li></ul><h1 style="margin-left:0px;">Attack simulation:</h1>I have re-created parts of the hack in this <a href="https://github.com/toxicsudo/flash-loan-exploit-tutorial">GitHub Repo</a><h2 style="margin-left:0px;">Contracts:</h2><a href="https://github.com/toxicsudo/flash-loan-exploit-tutorial/blob/main/contracts/InitialAttacker.sol">Base Attacker contract</a> : Used in <a href="https://www.notion.so/Transaction-1-Epoch-Computation-Transaction-1668e012da244ef1bcee9f245635dc64">Transaction 1 (Epoch Computation Transaction):</a><a href="https://github.com/toxicsudo/flash-loan-exploit-tutorial/blob/main/contracts/Attacker1.sol">Attacker1 contract</a>: Used in both transactions 1 and 2:<ul><li>In the attack, Transaction 1 uses this “Attacker 1” contract to transfer initial GDS tokens and sets its current epoch as the last epoch. This contract serves as a blueprint for over 50 similar contracts to increase the impact of the attack. Transaction 2 also leverages the Attacker 1 contract, along with a flash loan, to acquire large amounts of LP tokens and receive substantial rewards from the GDS token contract.</li><li><code>transferToken()</code> called in Txn1: burn GDS tokens equivalent to 100USDC.</li></ul><figure class="image image_resized" style="width:679.997px;"><img src="https://miro.medium.com/v2/resize:fit:706/1*QaBLfKTSaK1GBZ3Jzdt6sg.png" alt="" loading="lazy"></figure><ul><li><code>withdraw()</code> called in Txn2: burn 10k wei of GDS tokens.</li></ul><figure class="image image_resized" style="width:679.997px;"><img src="https://miro.medium.com/v2/resize:fit:706/1*oUP1pC97nks_WjMvCeok1Q.png" alt="" loading="lazy"></figure><a href="https://github.com/toxicsudo/flash-loan-exploit-tutorial/blob/main/contracts/FlashLoanExample.sol">FlashLoanExample contract</a>: The FlashLoanExample contract performs the following steps:<ul><li>It takes a flash loan of USDC tokens from a pool to obtain a large amount.</li><li>Half of the obtained USDC tokens are swapped to GDS tokens and used to add liquidity to the USDC-GDS pool to get a large number of LP tokens.</li><li>The LP tokens are then transferred to the Attacker1 contract and the <code>withdraw()</code> function is called. This function burns a small amount of GDS tokens to obtain large rewards.</li><li>Finally, all the tokens are transferred back to the FlashLoanExample contract and swapped back to USDC to repay the flash loan debt along with the fees.</li></ul><figure class="image image_resized" style="width:679.997px;"><img src="https://miro.medium.com/v2/resize:fit:706/1*Ngur790-L9CoHaXYKuzCEg.png" alt="" loading="lazy"></figure><blockquote>It’s important to note that in this demonstration, only one attacker contract was used, resulting in a loss due to the incurred fees for internal transfers. If more than 50 attacker contracts were used, as the attacker in the actual attack did, the rewards would have been higher. But it can be clearly seen in the above log that by burning only 10k wei of GDS token, a large amount of GDS tokens are received as reward, hence an PROFIT!</blockquote><h2 style="margin-left:0px;">Scripts used:</h2><ul><li>deploy.ts : a simple script to deploy all contracts</li><li>flash.ts: creates instances of the contracts and perform Transaction 1 and Transaction 2. Note that some arbitrary values are being used in the script to perform the desired job, such as transfer amount, swapping amount, etc.</li></ul><h2 style="margin-left:0px;">Steps taken to re-create the hack:</h2><ol><li>Creating a forked testnest, forking from BSC at blocknumber: 24449913, allow unlimited contract size</li></ol><figure class="image image_resized" style="width:679.997px;"><img src="https://miro.medium.com/v2/resize:fit:706/1*_VaXHa3YpCPDpqFJBSZEKw.png" alt="" loading="lazy"></figure>2. Fork this Github Repo: <a href="https://github.com/toxicsudo/flash-loan-exploit-tutorial">https://github.com/toxicsudo/flash-loan-exploit-tutorial</a>3. Update your <code>.env</code> file for the RPC from buildbear and your private key:<figure class="image image_resized" style="width:679.997px;"><img src="https://miro.medium.com/v2/resize:fit:706/1*ODkjoaGd65YkmPFzQtbbvw.png" alt="" loading="lazy"></figure>4. Visit the faucet, <code>Add Network to Metmask</code>, and get a good amount of Native tokens (BB ETH) and the ERC20 token <code>0x55d398326f99059fF775485246999027B3197955</code><figure class="image image_resized" style="width:679.997px;"><img src="https://miro.medium.com/v2/resize:fit:706/1*WLlv5_zUs2hdrbjNY6DBaA.png" alt="" loading="lazy"></figure>5. Run <code>npm i</code> in your terminal, and then the command<code>npx hardhat run scripts/deploy.ts --network buildbear</code>You should see something like this:<figure class="image image_resized" style="width:679.997px;"><img src="https://miro.medium.com/v2/resize:fit:706/1*KeILudlX09QgeVcvZYxogA.png" alt="" loading="lazy"></figure>6. Update the addresses in <code>scripts/flash.ts</code> file<figure class="image image_resized" style="width:679.997px;"><img src="https://miro.medium.com/v2/resize:fit:706/1*krMt_Vxg4lZsP7PmviZpCw.png" alt="" loading="lazy"></figure>7. Visit the Faucet again, for getting more Binance-Pegged USD Token <code>0x55d398326f99059fF775485246999027B3197955</code> into the baseAttacker contract and the flash loan example contract. See the example image below: NOTE that I have updated the address in the first box in which I want the USD token. That is the address of the baseAttacker contract. This is where I could not find anything better than BuildBear (shout out 🎉🔈). It is easy to get any ERC20 token that I might need in a matter of seconds.<figure class="image image_resized" style="width:679.997px;"><img src="https://miro.medium.com/v2/resize:fit:706/1*JMStwj5B1Yfj-SH7z40TGA.png" alt="" loading="lazy"></figure>Do the same for the Attacker_contract and also the Flash Loan Example Contract.8. Job done. Just run the script <code>npx hardhat run scripts/flash.ts --network buildbear</code>At the end of the script, you should see something like this:<figure class="image image_resized" style="width:679.997px;"><img src="https://miro.medium.com/v2/resize:fit:706/1*Lg3xD0nSF31DSH7sySxmQA.png" alt="" loading="lazy"></figure>You have successfully hacked the smart contract of GDS for the computation error.<blockquote>NOTE: HAD YOU DONE ONLY THE FLASH LOAN TRANSACTION YOU WOULD HAVE MADE A LOSS AND NOT A HACK!!!</blockquote><h2 style="margin-left:0px;">Summary of the simulation:</h2><ul><li>The simulation demonstrated how the GDS contract can emit more GDS rewards through an attack.</li><li>The demonstration used only one attack contract to show the potential reward that could be earned.</li><li>Using only one attack contract resulted in a high cost in terms of transaction fees. However, if the attacker had used more than 50 attack contracts, they would have been able to earn higher rewards.</li><li>Example: Let’s say the attacker had 50 attack contracts each with 1 million LP tokens. If each attack contract earned 10,000 GDS tokens as rewards, the total reward would be 500,000 GDS tokens. This is assuming that each transfer incurs the same amount of fees, which is likely to be the case since the same attack function is used in all contracts. However, the attacker would have been able to earn more rewards if they had used more than 50 attack contracts.</li></ul>Author : Toxic Sudo( <a href="https://github.com/toxicsudo">Github</a> , <a href="https://medium.com/@toxicsudo">Medium</a> )

Template for Tutorials.png

If you are a smart contract developer, intending to make sure that you write “safe code”, and you are keeping a tab on the hacks that happen; you need to make sure that you understand this hack very carefully.  I have documented the exact manner in which the hack was executed, by (a) explaining the events and (b) re-creating this hack.

Re-constructing the GDS Hack || Things that you should actually know to code safe protocols

BUILDBEAR // TUTORIALS

Re-constructing the GDS Hack || Things that you should actually know to code safe protocols

Let’s get started then, Shall we?

Let’s get started then, Shall we?

Test DApps at Scale.