Hugo Inu security record

In function `transferFrom()`, the `_transfer()` function is executed before checks and updates to the allowance are processed. ```solidity=219 function transferFrom( address sender, address recipient, uint256 amount ) public override returns (bool) { _transfer(sender, recipient, amount); uint256 currentAllowance = _allowances[sender][_msgSender()]; require(currentAllowance >= amount, "BEP20: transfer amount exceeds allowance"); _approve(sender, _msgSender(), currentAllowance - amount); return true; } ``` This violates the check-effect-interaction pattern and should follow the checks and updates of the allowances. An added benefit is that having the allowance check `require(currentAllowance >= amount, "BEP20: transfer amount exceeds allowance")` before the execution of the `_transfer()` function (or any checks in general before such external function calls) will save gas since all remaining gas will be returned after the function reverts immediately due to insufficient gas.

In the `HUGO` contract, the `owner()` and `marketingWallet` are excluded from fees during deployment but there is no mechanism in place to handle these privileges when ownership is renounced. ```solidity constructor(address routerAddress) { ... _isExcludedFromFee[owner()] = true; _isExcludedFromFee[marketingWallet] = true; ... } ``` There is no way to remove the privilege of exclusion from fees for the previous owner or `marketingWallet` if the owner does not remove the exclusion prior to renouncing of ownership.

There should always be events emitted in the sensitive functions that are controlled by centralization roles.

Addresses are not validated before assignment or external calls, potentially allowing the use of zero addresses and leading to unexpected behavior or vulnerabilities. For example, transferring tokens to a zero address can result in a permanent loss of those tokens. ```solidity=521 marketingWallet = _marketWallet; ``` - `_marketWallet` is not zero-checked before being used.

The `HUGO` contract relies on `HUGO-WBNB` trading pair for swapping. In the function `swapAndLiquify()`, the `HUGO` balance of this contract is swapped for `BNB` which then will be transferred to `marketingWallet` address. ```solidity=479 function swapAndLiquify() private lockTheSwap { uint256 contractBalance = balanceOf(address(this)); swapTokensForBNB(contractBalance); uint256 deltaBalance = address(this).balance; if (deltaBalance > 0) { payable(marketingWallet).sendValue(deltaBalance); } } ``` The `swapAndLiquidify()` function only makes a call to `swapTokensForBNB()` to exchange tokens for native tokens through the router. ```solidity=491 function swapTokensForBNB(uint256 tokenAmount) private { // generate the pair path of token -> weth address[] memory path = new address[](2); path[0] = address(this); path[1] = router.WETH(); _approve(address(this), address(router), tokenAmount); // make the swap router.swapExactTokensForETHSupportingFeeOnTransferTokens( tokenAmount, 0, // accept any amount of ETH path, address(this), block.timestamp ); } ``` However, there is no logic to liquify tokens in this function `swapAndLiquify()`. This can lead to risks related to price instability and price manipulation when there is insufficient liquidity in the pair liquidity pool. The only way of adding liquidity is to manually inject liquidity into the DEX liquidity pool. Once the liquidity is removed, the trading of `POP` will be blocked.

There is a potential `out-of-gas` issue in function `includeInReward()` since it uses a loop to iterate over `_excluded`, which could potentially result in a high amount of gas consumption. If `_excluded` contains a large number of elements, the loop may consume more gas than is available in a single block. This would cause the transaction to fail with the "out-of-gas" error. ```solidity=292 for (uint256 i = 0; i < _excluded.length; i++) { if (_excluded[i] == account) { _excluded[i] = _excluded[_excluded.length - 1]; _tOwned[account] = 0; _isExcluded[account] = false; _excluded.pop(); break; } } ```

In a reflection mechanism, users are charged a fee every time they make a trade. This fee is used to reward users who hold tokens, but it does not trigger a transfer of tokens. Instead, it only modifies a coefficient. In this mechanism, the user possesses two types of token amounts: `tAmount` and `rAmount`. `tAmount` represents the actual amount of tokens, while `rAmount` denotes the number of tokens after reflection. The rate between the two is calculated as $$$\frac{rTotal}{tTotal}$$$. The `balanceOf()` function returns the `tAmount` or `rAmount` depending on whether the address is participating in the reflection. ```solidity=205 function balanceOf(address account) public view override returns (uint256) { if (_isExcluded[account]) return _tOwned[account]; return tokenFromReflection(_rOwned[account]); } ``` The function `tokenFromReflection()` returns the token amount after the rate of reflection is taken into account. ```solidity=274 function tokenFromReflection(uint256 rAmount) public view returns (uint256) { require(rAmount <= _rTotal, "Amount must be less than total reflections"); uint256 currentRate = _getRate(); return rAmount / currentRate; } ``` In the `HUGO` contract, the `rfi` fee is used for the reflection mechanism, which is utilized to decrease the `_rTotal` and subsequently reduce the `rate`. This results in the inflation of the holders' balances through the distribution of rewards. ```solidity=315 function _reflectRfi(uint256 rRfi, uint256 tRfi) private { _rTotal -= rRfi; totFeesPaid.rfi += tRfi; } ``` However, the `rfi` fee can be updated by the owner and set to any value less than 15%. If it is set to zero, then `_rTotal` will not be decreased anymore, and in this case, there will be no reflection mechanism. ```solidity=515 function changeFee(Taxes memory _taxes) public onlyOwner { require((_taxes.rfi + _taxes.marketing) <= 15, "Tax must lower than 15%"); taxes = _taxes; } ```

A sandwich attack might happen when an attacker observes a transaction swapping tokens or adding liquidity without set restrictions on the slippage or minimum output amount. The attacker can manipulate the exchange rate by frontrunning (executing a transaction before the transaction being attacked) a transaction to purchase one of the assets and make profits by backrunning (executing a transaction 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: * `router.swapExactTokensForETHSupportingFeeOnTransferTokens()` ```solidity=500 router.swapExactTokensForETHSupportingFeeOnTransferTokens( tokenAmount, 0, // accept any amount of ETH path, address(this), block.timestamp ); ```

State variables that never change should be declared as `constant` to save gas. ```solidity=128 uint256 private _tTotal = 420000000000000000 * 10**_decimals; ``` - `_tTotal` should be declared `constant`. --- ```solidity=133 address public deadWallet = 0x000000000000000000000000000000000000dEaD; ``` - `deadWallet` should be declared `constant`.

The contracts cited have an unlocked compiler version. An unlocked compiler version in the source code of the contract permits the user to compile it at or above a particular version. This, in turn, leads to differences in the generated bytecode between compilations due to differing compiler version numbers. This can lead to ambiguity when debugging, as compiler specific bugs may occur in the codebase that would be hard to identify over a span of multiple compiler versions rather than a specific one.