WealthSecrets security record

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.  In the contract `Ownable` the role `_previousOwner` has authority over the functions shown in the diagram below. Any compromise to the `_previousOwner` account may allow the hacker to take advantage of this authority.  In the contract `Token` 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 variable `_maxTxAmount` and `_maxWalletAmount` could be set arbitrarily when deploying the contract `Token`, also, the variable `buyBackLimit` does not have reasonable boundaries when setting it. More seriously, setting `buyBackLimit` to a very small value may lead to the failure of buying back tokens.

According to the following codes: ```solidity uint256 balance = address(this).balance; if (buyBackEnabled && balance > uint256(1 * 10**18)) { if (balance > buyBackUpperLimit) balance = buyBackUpperLimit; buyBackTokens(balance.div(100)); } ``` Nothing will be used to buy back tokens if `balance` is smaller than 1 BNB. If `balance` is greater than `buyBackUpperLimit`, 1% of `buyBackUpperLimit` amount will be used to buy back tokens each time this function is called. Since the BuyBackToken contract will continuously accumulate liquidity fees, only a small portion of the liquidity fees will be used to buy back tokens. Additionally, the `buyBackUpperLimit` can be modified by the admin and has no limitations. So they can be set to a relatively small number. Hence the percentage of buying back may be very small. More seriously, the percentage of `buybackFee` could be zero, so almost all converted BNBs in the current contract could be kept in the contract, however, the contract doesn't appear to provide a way to withdraw those BNBs.

According to the following code: ```solidity function _transfer( address from, address to, uint256 amount ) private { ... uint256 balance = address(this).balance; if (balance > uint256(1 * 10**18)) { if (balance > buyBackUpperLimit) balance = buyBackUpperLimit; buyBackTokens(balance.div(100)); } ... } ``` ,in the function `_transfer()`, the 1%`buyBackUpperLimit` amount of BNBs were bought back when requirements are met, while some BNBs are still left in the contract, however, the contract doesn't appear to provide a way to withdraw those BNBs, and they will be locked in the contract forever.

The contract is serving as the underlying entity to interact with third party PancakeSwap protocols. The scope of the audit would treat those 3rd party entities as black boxes and assume its functional correctness. However in the real world, 3rd parties may be compromised that led to assets lost or stolen.

Performing integer division before multiplication truncates the low bits, losing the precision of calculation.

`public` functions that are never called by the contract could be declared as `external`. `external` functions are more efficient than `public` functions.

The error message in `require(_isExcluded[account], "Already excluded")` does not describe the error correctly.

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

An owner is possible to gain ownership of the contract even if he calls function `renounceOwnership` to renounce the ownership. This can be achieved by performing the following operations: 1. Call `lock` to lock the contract. The variable `_previousOwner` is set to the current owner. 2. Call `unlock` to unlock the contract. 3. Call `renounceOwnership` to leave the contract without an owner. 4. Call `unlock` to regain ownership.