King Finance security record

In the contract `King` 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 `King` the role `kingPassContract` has authority over the functions shown in the diagram below. Any compromise to the `kingPassContract` account may allow the hacker to take advantage of this authority and lock tokens to activate the KingPass contract. 

`100_000_000 * 10 ** 9` tokens were sent to the `owner()` when deploying the contract. This could be a centralization risk as the deployer can distribute tokens without obtaining the consensus of the community.

Contracts that authorize users using the `tx.origin` variable are typically vulnerable to phishing attacks which can trick users into performing authenticated actions on the vulnerable contract. There are multiple reasons why using `tx.origin` is not safe from the security perspective. Refer to : * [Solidity Documentation on `tx.origin`](https://docs.soliditylang.org/en/latest/security-considerations.html#tx-origin) * <https://github.com/ethereum/solidity/issues/683> ```solidity=453 require(userLastTradeData[tx.origin].lastBuyTime + 3 <= block.timestamp,"You cannot do multi-buy orders."); ```

Performing integer division before multiplication truncates the low bits, losing the precision of calculation. ```solidity=514 txFees = amount * (totalBuyFee * kingPassFeeDiscount / 1000) / 1000; ``` --- ```solidity=524 txFees = amount * (totalSellFee * kingPassFeeDiscount / 1000) / 1000; ```

There are many hardcode addresses in this codebase.

The variables `minimumWeiForTokenomics` do not have reasonable boundaries, so the owner can be given arbitrary values after deploying.

Addresses should be checked before assignment or external call to make sure they are not zero addresses. ```solidity=209 pancakeV2Pair = _pair; ``` - `_pair` is not zero-checked before being used. --- ```solidity=287 marketingAddress = marketing; ``` - `marketing` is not zero-checked before being used. --- ```solidity=288 devAddress = dev; ``` - `dev` is not zero-checked before being used. --- ```solidity=289 buybackAddress = buyback; ``` - `buyback` is not zero-checked before being used.

A sandwich attack may 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 front running (before the transaction being attacked) a transaction to purchase one of the assets and make profits by back running (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: - `swapExactTokensForETHSupportingFeeOnTransferTokens()`

In `constructor()`, the `marketingAddress`, `devAddress`, and `buybackAddress` are excluded from fees, but in the function `setFeesAddress()`, the new `marketingAddress`, `devAddress`, and `buybackAddress` are not excluded from fees and the old ones are not included in fees.

In `constructor()`, the `pancakeV2Pair` is added to `automatedMarketMakerPairs`, but in the function `updatePancakeV2Router()`, the new `pancakeV2Pair` is not added to the `automatedMarketMakerPairs` and the old one is not removed from the `automatedMarketMakerPairs`.