Kochi Ken security record

In the `KochiInvest.sol` contract, a certain party can create a launchpad to sell their tokens. Users can buy this token via the `buy` function and claim the bought tokens via the `claim()` function. However, when it is a fair launch, in the `claim()` function, the value of tokens that can be claimed is miscalculated due to the misuse of "softcap". Thus, users will always get the incorrect amount of tokens. In the `claim()` function, the `require` statement in L217 checks if the soft cap has been reached. The soft cap is the minimum amount of tokens the launch pad owner expects to raise. ```solidity=217 require(presaleMetadata[id][EPresaleMetadata.total_invested] >= presales[id].soft_cap, "ERROR: the softcap has not been reached"); ``` However, the formula in L221 which calculate the amount of tokens that a user can claim ```solidity=221 if (presales[id].presale_type == EPresaleType.fairlaunch) tokens = SafeMath.div(SafeMath.mul(presales[id].soft_cap, invested), presaleMetadata[id][EPresaleMetadata.total_invested]); // softcap * (invested / total invested) ``` This calculation is incorrect since it uses `softcap` as the multiplier. The `softcap` value is the amount of tokens **users paid** for a launch pad instead of the amount of tokens that **should be distributed to users**(`i.e., `presales[id].total_tokens`). **Example:**\ Suppose there is a launch pad for 100 `A_Token` where users can buy `A_Token` tokens with ETH and the softcap is 1000 ETH 1. Alice calls the `buy()` function to invest 100 ETH to buy `A_Token`. 2. Bob calls the `buy()` function to invest 900 ETH to buy `A_token`. 3. The soft cap is reached (i.e., in total raised 1000 ETH) and 100 `A_Token` was sold. 4. Alice called `claim()` to claim his `A_Token` token. Since the calculation in L221 uses the `softcap` amount, Alice tries to get 1000 * (1000 / 1900) = 526.3 `A_Token` tokens but failed since there are only 100 `A_Token` tokens.

If a token has referral tokens to distribute, users can designate an address as a referrer. The referrer will earn referral tokens based on the following calculation: ```solidity=230 if (userMetadata[id][_msgSender()][EUserMetadata.referrals] > 0) tokens += SafeMath.div(SafeMath.mul(presales[id].referral_tokens, userMetadata[id][_msgSender()][EUserMetadata.referrals]), presaleMetadata[id][EPresaleMetadata.total_referrals]); ``` This formula is written in simpler terms in the comment on line 228: ```solidity=228 // referral forumla = (total_referrals_tokens * user_number_of_referrals / total_number_of_referrals) ``` To designate an address as a referrer, users can call the `setReferrer()` function. Each address can only designate one address as a referrer but an address can have multiple referrals. The referral counts are managed according to the following code: ```solidity=360 bool replace = userReferrer[id][_msgSender()] == address(0); if (replace) { // increment the presale total and the referrer's total presaleMetadata[id][EPresaleMetadata.total_referrals]++; userMetadata[id][referrer][EUserMetadata.referrals]++; } // referrer is already set else { // decrement the old referrer, and increment the new one userMetadata[id][userReferrer[id][_msgSender()]][EUserMetadata.referrals]--; userMetadata[id][referrer][EUserMetadata.referrals]++; } ``` If the referrer can be set after claiming begins, the following scenario can occur: 1. total_referrals_tokens is 200 and Alice is a referrer; 2. Alice claims referral tokens equal to 200 * 1 / 1 = 200 tokens; 3. Bob is set as a referrer and total referrals increase to 2; 4. Bob claims referral tokens equal to 200 * 1 / 2 = 100 tokens; 5. Total of 300 referral tokens are claimed despite only 200 should have been claimed. Scenario 2: 1. total_referrals_tokens is 200 and Alice and Bob are referrers; 2. Alice claims referral tokens equal to 200 * 1 / 2 = 100 tokens; 3. Alice's referee changes referrer from Alice to Bob; 4. Bob's referral increases to 2 but total referral does not increase; 5. Bob claims referral tokens equal to 200 * 2 / 2 = 200 tokens; 6. Total of 300 referral tokens are claimed despite only 200 should have been claimed. The above scenario 1 exists for the calculation in Line 221 if users can buy tokens after claiming begins. **[CertiK, 12/08/2022]** *The below description is based on the new version contracts on 12/08/2022.* As it is mentioned above scenario 1 still exists for the calculation of `tokens` in the `claim()` function when the `presale_type` is `fairlaunch`. Recommend adding a check to restrict buying after claiming begins for the `presale_type` is `fairlaunch` in the private codebase.

In `KochiBulkSender.sol`, the `sendETH()` function distributes/airdrops all the received ETH to the recipient addresses. In L63, the `require` statement ensures all the ETH in the contract is sent to the recipient. ```solidity=46 function sendEth(address[] memory _recipients, uint256[] memory _amounts) external payable override whenNotPaused nonReentrant { require(_recipients.length == _amounts.length, "KochiAirdropper: Invalid input"); uint256 sum = 0; for (uint256 i = 0; i < _amounts.length; i++) { sum += _amounts[i]; } require(msg.value == sum, "KochiAirdropper: Insufficient value sent"); for (uint256 i = 0; i < _recipients.length; i++) { bool ok; (ok, ) = _recipients[i].call{value: _amounts[i]}(""); require(ok, "KochiAirdropper: Failed to send value to recipient"); } // contract has no receive function, so it will not receive any ETH. require(address(this).balance == 0, "KochiAirdropper: Invalid final balance, something went wrong."); } ``` However, ETH can be forcibly sent to an address using the `selfdestruct` method. Since the function requires the balance of the contract to equal zero, if Ether is forcibly sent to this contract, the function will always revert. In this case, the contract will suffer a Denial-of-service situation where the contract can never use `sendEth()` to airdrop ETHs. Exploit scenario: 1. The attacker deploys the following contract ```solidity= import "./CBulksender.sol"; contract Attack { KochiBulkSender airdrop_contract; constructor(KochiBulkSender _airdrop_contract) { airdrop_contract = KochiBulkSender(_airdrop_contract); } function attack() public payable { address payable addr = payable(address(airdrop_contract)); selfdestruct(addr); } } ``` 2. The attacker call the `attack()` function with 1 WEI. 3. The `selfdestruct()` function will force to send 1 WEI to the victim airdrop contract, which is `KochiBulkSender` contract. 4. Since the balance of the `KochiBulkSender` contract will never be zero, the `sendEth()` will always revert.

In the contract`CKochiLock.sol`, `lpAmountLocked[]` is used to store the total amount of tokens locked in the corresponding Pair. `lpUnlock()` is used to retrieve locked LP tokens, so the amount of locked tokens in this LP token should be decreased by corresponding data stored in `lpUserLocks[_msgSender()][i]`, which are `metadata.amount0` and `metadata.amount1`. However, in the following code snippets, the `lpAmountLocked` mapping is incorrectly updated: ```solidity=239 if (metadata.deadline < block.timestamp && metadata.liquidity > 0 && metadata.lp_pair == pair) { lpAmountLocked[metadata.token0] -= lpAmountLocked[metadata.token0] - metadata.amount0; lpAmountLocked[metadata.token1] -= lpAmountLocked[metadata.token1] - metadata.amount1; liquidity += metadata.liquidity; ``` Therefore, it could lead to a display error when acquiring the value of `lpAmountLocked`.

If a pair exists, it's possible that not all `token0` or `token1` are added into pair as liquidity. The actual amounts of `token0` and `token1` can be computed by `IUniswapV2Router02(DEXs[dex].router).quote()`. Therefore, there could be some `token0` or `token1` remaining in `CKochiLock`. Plus, there is no extra operation or function to handle these remaining tokens. Only the remaining LP tokens will be sent to the beneficiary at the end of `lpLock()` and `lpLockETH()`.

The `CKochi.sol` contract tries to implement a feature to detect the bots, who transfer tokens in 10 blocks from the `startingBlock`. However, the implementation of it assigns the wrong value, `false`, to the potential bot, `bots[from]`, as shown below: ```solidity=83 if (block.number < botLimit + startingBlock) { bots[from] = false; } ``` It is known that the default value of `bots[from]` is false, thus, its value should be `true` if it is detected as a bot, to apply a different tax for the bots.

`KOCHI` tokens could be left in the contract after the `_addLiquidity()` function, thus, consider adding a recover function to withdraw the potentially locked `Kochi` token.

The check used in the function `createLaunchpad()` checks whether the user has approved all his allowance to the contract. The function `createLaunchpad()` is used to create a presale for the given parameters. The amount of the `user_token` transferred from the user is calculated by the given parameters. In general, it may be less than the `totalsupply` and only need to approve the allowance for the `required_amount`.

The `CKochi.sol` contract uses the `pair` and `router` to decide whether the transaction is a buying transaction, the condition will work well for only one DEX, what if the `Kochi` is listed in another DEX, if so, the condition fails to detect the buying transaction on another DEX since the `pair` and `router` of another DEX is different.

When transferring standard ERC20 deflationary tokens, the input amount may not be equal to the received amount due to the charged transaction fee. For example, if a user stakes 100 deflationary tokens (with a 10% transaction fee) to create a launchpad, only 90 tokens actually arrive in the contract. However, the total amount of tokens to be presaled is still 100 tokens, which may cause misbehaviors of the contract and lead to unexpected revert if there are no enough tokens to transfer. **[CertiK, 12/08/2022]** *The below description is based on the new version contracts on 12/08/2022.* The below `require` will revert if Bob tries to create a launch pad after the Alice'creation of the launch pad: ```solidity=145 require( IERC20(parameters.user_token).balanceOf(address(this)) == required_amount, "ERROR: Looks like your token may be deflationary, taxed, or otherwise not compatible with this contract. Please whitelist your token with us and try again." // CKI-03 ); ``` Example: - Alice creates a launch pad by calling the `createLaunchpad` with `required_amount` 100, then the contract's balance is 100, and the `require` check will pass for a normal ERC-20 token. - Bob tries to create a launch pad by calling the `createLaunchpad` with `required_amount` 200, then the contract's balance is 300(100 + 200) instead of 200, and the `require` check will revert.