UIIC security record

According to the design of `UIC` token, there is a burn fee will be deducted during selling process. All the burn fee will be sent to the address `0x000000000000000000000000000000000000dEaD`. ```solidity function _takeBurn(address sender, uint256 tBurn) private { uint256 currentRate = _getRate(); uint256 rBurn = tBurn.mul(currentRate); _rOwned[burnAddress] = _rOwned[burnAddress].add(rBurn); emit Transfer(sender, burnAddress, tBurn); } ``` Besides, the owner of `UIC` contract has ability to burn these tokens from the dead address. ```solidity function _burn(address account, uint256 tBurn) internal { uint256 currentRate = _getRate(); uint256 rBurn = tBurn.mul(currentRate); require(account != address(0), "BEP20: burn from the zero address"); _rOwned[account] = _rOwned[account].sub( rBurn, "BEP20: burn amount exceeds balance" ); _tTotal = _tTotal.sub(tBurn, "tburn err"); emit Transfer(account, address(0), tBurn); } ``` However, while the value of `_tTotal` is updated, the value of `_rTotal` is not. Since both of these two values impact the current rate deeply, this could result in a loss for the token holders.

In the contract `Ownable` the role `_owner` has authority over the functions shown below. - renounceOwnership(): transfer ownership to zero address. - transferOwnership(): transfer ownership to a specific address. - lock(): lock ownership, store `_previousOwner` and set current owner address to zero address. --- In the contract `Ownable` the role `_previousOwner` has authority over the functions shown below. - unlock(): get ownership of `UIC` contract. --- In the contract `UIC` the role `_owner` has authority over the functions shown below. - setUniswapV2Router(): set new uniswapV2Router. - setPresaleEndTime(): set presale time. - burn(): burn `UIC` from `0x000000000000000000000000000000000000dEaD` address. This results in a change in the user's balance. - setExcludedFee(): exclude account to receive dividend. - setExcludedFees(): exclude multiple accounts to receive dividend. - removeExcludedFee(): include account to receive dividend. - setFoundation(): set foundation account who can buy `UIC` during the presale period. - removeFoundation(): remove account from foundation. - setPancakePair(): set pair. - removePancakePair(): remove pair. Any compromise to the `_owner` account may allow the hacker to take advantage of these authority and disrupt the tokenomics.

All of the **UIC** tokens are sent to the contract deployer or one or several externally-owned account (EOA) addresses. This is a centralization risk because the deployer or the owner(s) of the EOAs can distribute tokens without obtaining the consensus of the community. Any compromise to these addresses may allow a hacker to steal and sell tokens on the market, resulting in severe damage to the project.

The previous owner is possible to regain ownership of the contract even if he has already called function `renounceOwnership()` or `transferOwnership()`. This can be achieved by performing the following operations: 1. Owner `A` calls `lock()` to lock the contract. The variable `_previousOwner` is set to the current owner `A`. 2. Owner `A` calls `unlock()` to unlock the contract. 3. Owner `A` calls `renounceOwnership()` or `transferOwnership()`. Noted that the owner is not `A` now. 4. Owner `A` calls `unlock()` to regain ownership. This is mainly because the `_previousOwner` has not been cleared in function `unlock()`.

Generally, deflationary tokens are incompatible with DEX and special rules need to be coded for DEX addresses e.g. excluding them from reward. Otherwise, a hacker may exploit the protocol using the reflection mechanism. The balance of accounts that include rewards is calculated by `rAmount/rate`, where the rate is determined base on the total supply. If the `burn()` function is executed with significant input, it can significantly decrease `_tTotal`, thereby allowing for manipulation of the rate.

```solidity function removeExcludedFee(address account) external onlyOwner { require(_isExcludedFee[account], "Account is already included"); for (uint256 i = 0; i < _excluded.length; i++) { if (_excluded[i] == account) { _excluded[i] = _excluded[_excluded.length - 1]; _tOwned[account] = 0; _isExcludedFee[account] = false; _excluded.pop(); break; } } } ``` Variable `_rOwned[account]` is not updated in the function `removeExcludedFee()`, which will make the accounts included siphon off the tokens out of the balances of all token holders. The rate was higher at the moment of the `setExcludedFee(account)` call, so the `_rOwned[account] / _tOwned[account]` ratio is bigger than expected for accounts included in the reward.

The second `require` check of the function `unlock()` requires current timestamp greater than the `_lockTime` which was specified when the owner executed the `lock` operation. The `_lockTime` can be any value in theory.

Performing division by zero would raise an error and revert the transaction. ```solidity=882 return rAmount.div(currentRate); ``` The expression `rAmount.div(currentRate)` may divide by zero. Its divisor has has estimated interval [0, 115792089237316195423570985008687907853269984665640564039457584007913129639935]. --- ```solidity=955 return rSupply.div(tSupply); ``` The expression `rSupply.div(tSupply)` may divide by zero. Its divisor has has estimated interval [ninf, pinf]. --- ```solidity=969 if (rSupply < _rTotal.div(_tTotal)) return (_rTotal, _tTotal); ``` The expression `_rTotal.div(_tTotal)` may divide by zero. Its divisor has has estimated interval [-115792089237316195423570985008687907853269984665640564039457584007913129639935, 115792089237316195423570985008687907853269984665640564039457584007913129639935].

The condition `!_isExcludedFee[sender] && !_isExcludedFee[recipient]` can be covered in the `else` branch.

The linked statements do not affect the functionality of the codebase and appear to be either remnants of test code or older functionality.