ToDing security record

In the contract `ToDing` the role `_owner` has authority over the functions shown in the diagram below. Any compromise to the `_owner` account may allow the hacker to take advantage of this authority and - call `startTrade()` to add liquidity to the DEX and enable the trading. - call `setWL()` to set whitelist. Whitelisted accounts are exempt from fees. - call `Airdrop()` to distribute tokens to accounts. - call `setBuyFee()` to set buy fees. The `buyBurnFee` will be burned when buying tokens. The `buyMarketingFee` will be sent to the [marketingWallet](https://bscscan.com/address/0x25D9847505483436C258435951f7e801381c9116). The `buyPowersFee` collects `ToDing` tokens and sells them for BNBs, which are then used as liquidity in the token contract for selling `ToDing` tokens back to the contract itself. - call `setSellFee()` to set sell fees. The `sellBurnFee` will be burned when selling tokens. The `sellMarketingFee` will be sent to the [marketingWallet](https://bscscan.com/address/0x25D9847505483436C258435951f7e801381c9116). The `sellPowersFee` collects `ToDing` tokens and sells them for BNBs, which are then used as liquidity in the token contract for selling `ToDing` tokens back to the contract itself. - call `wToken()` to withdraw ERC20 tokens or all of BNBs from the contract.  --- In the contract `TokenDistributor` the role `_feeWhiteList` has authority over the functions shown in the diagram below. Any compromise to the `_feeWhiteList` account may allow the hacker to take advantage of this authority and - call `claimToken()` to withdraw arbitrary ERC20 tokens from the contract. - call `claimBalance()` to withdraw BNB and WBNB from the contract.  --- In the contract `Ownable` the role `_owner` has authority over the functions shown in the diagram below. Any compromise to the `_owner` account may allow the hacker to take advantage of this authority. 

The buy and sell fees in the contract have no set limits, allowing fees to potentially reach 100%. If this occurs, users would receive no tokens from the contract, resulting in a complete loss of their investment. Various fees are allocated to different purposes: - **Burn Fees**: These are used to burn tokens, reducing the total circulative supply. - **Marketing Fees**: These are sent to a designated [marketing wallet](https://bscscan.com/address/0x25D9847505483436C258435951f7e801381c9116). - **Power Fees**: These involve collecting `ToDing` tokens, selling them for BNB, and then using the BNB as liquidity within the token contract. The contract owner has the authority to withdraw both `ToDing` tokens and BNB from the contract. If the marketing wallet accumulates a substantial amount of `ToDing` tokens or if the contract collects large amounts of tokens and BNB, there is a potential for these entities to sell a large volume of `ToDing` tokens on the market and withdraw collected BNBs. This action could severely impact the token's price, harming the community and investors.

The `Airdrop()` function distributes tokens to multiple recipients by taking two arrays as input: `addrs`, which contains the addresses of the recipients, and `amounts`, which specifies the amount of tokens to be allocated to each corresponding address. However, the function does not include a check to ensure that these two arrays are of the same length. If the lengths of `addrs` and `amounts` differ, the function may attempt to access elements that do not exist in one of the arrays, leading to out-of-bounds errors and transaction failures.

A sandwich attack can occur when an attacker notices a transaction involving token swaps or liquidity additions that lacks slippage restrictions or minimum output amount settings. The attacker can exploit this by frontrunning the transaction to purchase one of the assets, thereby manipulating the exchange rate, and then backrunning the transaction to sell the asset for a profit. The referenced functions are invoked without setting slippage restrictions or minimum output amounts, making transactions that trigger these functions particularly vulnerable to sandwich attacks, especially when large input amounts are involved. If the token deployer transfers tokens to a malicious actor, who can sandwich the `startTrade()` transaction and make a swap that changes the ratio of assets in the pool. Due to the attacker’s interference, the LP ends up adding more of one asset than planned.