BurnedFi security record

If the `msg.value` does not strictly equal to 0.002 or the `burnedfi` has already launched, BNBs sent to the airdrop contract will be locked forever. ```solidity=918 function _drop() internal { address _msgSender = msg.sender; if(msg.value == _value && !_burnedFi.launch() && _msgSender != address(this)){ require(_msgSender == tx.origin, "Only EOA"); if(_countBlock <10){ ++_countBlock; ++totalDroped; ++threshold; if (totalDroped == 1 || totalDroped % 300 == 0) { _deployLiquidity(); } IERC20 token = IERC20(address(_burnedFi)); require(token.balanceOf(address(this)) >= _singleAmount, "Droped out"); token.transfer( _msgSender, _singleAmount); }else if(_block != block.number){ _block = block.number; _countBlock=0; } if(totalDroped>= 150000 ){ _burnedFi.setLaunch(true); uint256 amount = payable(address(this)).balance; payable(address(_burnedFi)).transfer(amount); } } } ``` Here is an example transaction that leads to locked BNBs: https://bscscan.com/tx/0x42894dc3129aa4bc3754d3159656dc976024b8ce893207caefebaf65885bb5b6

The contract's reliance on a single Dex pair for price feeds in the `burnToHolder` function exposes it to flashloan attack risks. An attacker can use a flashloan as the initial funds for an exploit to enlarge the profit or manipulate the `burnfi` token price in decentralized exchanges. ```solidity=1341 deserved = uniswapRouter.getAmountsOut(amount, path)[path.length - 1]; ``` The `burnToHolder()` function relies on price calculations that are based on-chain, meaning they are susceptible to flash-loan attacks by manipulating the price of given pairs to the attacker's benefit. In this case, the attacker could pump the `burnfi` token price to get more `burnbuild` tokens as returns in this function call.

The native token is transferred to the `receiver` (interaction) in line 1313 before the state variables are updated in lines 1315-1316 (effects), which deviates from the checks-effects-interaction pattern. This could lead to potential re-entrancy risks. Sending native tokens will trigger the `receive()` functions in the receiver contract. An attacker can make a recursive call back to the original function. During such a reentrant call, the state variables are not yet updated (the caller still holds `burnfi` token), enabling the attacker to re-enter the original contract and claim rewards multiple times. However, the `to.transfer()` call has a strict gas limit of 2300, which is typically insufficient for any significant computations or state changes in the called contract. This restriction constrains the actions an attacker can perform in the receiver's contract, thereby reducing the potential impact of the reentrancy attack, but the risk still exists. ```solidity=1306 function receiveRewards(address payable to) external { address addr = msg.sender; uint256 balance = balanceOf(addr); uint256 amount = balance.sub(burnAmount[addr]); //.sub(Rewards[addr]); require(amount > 0 ); Rewards[addr] = Rewards[addr].add(amount); historyRewards[addr] = historyRewards[addr].add(amount); to.transfer(amount.mul(10**9)); _transfer(addr, address(this), balance); burnAmount[addr]=0; totalReceive = totalReceive.add(amount); emit ReceiveReward(addr, amount, totalReceive); } ```

If the `msg.value` does not strictly equal to 0.002 or the `burnedfi` has already launched, BNBs sent to the airdrop contract will be locked forever. ```solidity=918 function _drop() internal { address _msgSender = msg.sender; if(msg.value == _value && !_burnedFi.launch() && _msgSender != address(this)){ require(_msgSender == tx.origin, "Only EOA"); if(_countBlock <10){ ++_countBlock; ++totalDroped; ++threshold; if (totalDroped == 1 || totalDroped % 300 == 0) { _deployLiquidity(); } IERC20 token = IERC20(address(_burnedFi)); require(token.balanceOf(address(this)) >= _singleAmount, "Droped out"); token.transfer( _msgSender, _singleAmount); }else if(_block != block.number){ _block = block.number; _countBlock=0; } if(totalDroped>= 150000 ){ _burnedFi.setLaunch(true); uint256 amount = payable(address(this)).balance; payable(address(_burnedFi)).transfer(amount); } } } ``` Here is an example transaction that leads to locked BNBs: https://bscscan.com/tx/0x42894dc3129aa4bc3754d3159656dc976024b8ce893207caefebaf65885bb5b6

The contract's reliance on a single Dex pair for price feeds in the `burnToHolder` function exposes it to flashloan attack risks. An attacker can use a flashloan as the initial funds for an exploit to enlarge the profit or manipulate the `burnfi` token price in decentralized exchanges. ```solidity=1341 deserved = uniswapRouter.getAmountsOut(amount, path)[path.length - 1]; ``` The `burnToHolder()` function relies on price calculations that are based on-chain, meaning they are susceptible to flash-loan attacks by manipulating the price of given pairs to the attacker's benefit. In this case, the attacker could pump the `burnfi` token price to get more `burnbuild` tokens as returns in this function call.

The native token is transferred to the `receiver` (interaction) in line 1313 before the state variables are updated in lines 1315-1316 (effects), which deviates from the checks-effects-interaction pattern. This could lead to potential re-entrancy risks. Sending native tokens will trigger the `receive()` functions in the receiver contract. An attacker can make a recursive call back to the original function. During such a reentrant call, the state variables are not yet updated (the caller still holds `burnfi` token), enabling the attacker to re-enter the original contract and claim rewards multiple times. However, the `to.transfer()` call has a strict gas limit of 2300, which is typically insufficient for any significant computations or state changes in the called contract. This restriction constrains the actions an attacker can perform in the receiver's contract, thereby reducing the potential impact of the reentrancy attack, but the risk still exists. ```solidity=1306 function receiveRewards(address payable to) external { address addr = msg.sender; uint256 balance = balanceOf(addr); uint256 amount = balance.sub(burnAmount[addr]); //.sub(Rewards[addr]); require(amount > 0 ); Rewards[addr] = Rewards[addr].add(amount); historyRewards[addr] = historyRewards[addr].add(amount); to.transfer(amount.mul(10**9)); _transfer(addr, address(this), balance); burnAmount[addr]=0; totalReceive = totalReceive.add(amount); emit ReceiveReward(addr, amount, totalReceive); } ```

The event `OwnershipTransferred` has two parameters that demonstrate the ownership transfer between the `previousOwner` address and `newOwner` address. In the function `Lock()`, the `_owner` is changed to `address(0)` at Line 259, so the emitted `_owner` is the same as `address(0)` in the event which may contradict the purpose of this event.

A sandwich attack might happen when an attacker observes a transaction swapping tokens or adding liquidity without setting restrictions on slippage or minimum output amount. The attacker can manipulate the exchange rate by frontrunning (before the transaction being attacked) a transaction to purchase one of the assets and make profits by backrunning (after the transaction being attacked) a transaction to sell the asset. The following functions are called without setting restrictions on slippage or minimum output amount, so transactions triggering these functions are vulnerable to sandwich attacks, especially when the input amount is large: ```solidity=1101 function swapTokensForEth(uint256 tokenAmount) private { // generate the uniswap pair path of token -> weth address[] memory path = new address[](2); path[0] = address(this); path[1] = uniswapRouter.WETH(); _approve(address(this), address(uniswapRouter), tokenAmount); // make the swap uniswapRouter.swapExactTokensForETHSupportingFeeOnTransferTokens( tokenAmount, 0, // accept any amount of ETH path, address(this), block.timestamp ); } ```

```solidity=925 if (totalDroped == 1 || totalDroped % 300 == 0) { _deployLiquidity(); } ``` Users have to pay for the gas of adding liquidity if the condition `totalDroped % 300 == 0` is met. If the user fails to set enough gas limit for this transaction, calls to the `_drop()` will revert and therefore block the airdrop process. Here is an example of a blocked transaction: https://bscscan.com/tx/0x06343bc779f0ce427f7005ae0d8305d0cbe712eb85db4ba35a4310b810ee4a17

State variables that never change should be declared as `constant` to save gas. ```solidity=981 uint256 public burnFee = 1; ``` - `burnFee` should be declared `constant`.