SMART CONTRACT AUDIT REPORT
For
Safemoon
(Order #FO1BF05AAB45)
Prepared By: Kishan Patel Prepared For: kelvinle469
Prepared on: 14/03/2021
Table of Content
• Disclaimer
• Overview of the audit
• Attacks made to the contract
• Good things in smart contract
• Critical vulnerabilities found in the contract
• Medium vulnerabilities found in the contract
• Low severity vulnerabilities found in the contract
• Summary of the audit
• Disclaimer
The audit makes no statements or warranties about utility of the code, safety of
the code, suitability of the business model, regulatory regime for the business
model, or any other statements about fitness of the contracts to purpose, or their
bug free status. The audit documentation is for discussion purposes only.
• Overview of the audit
The project has 1 file. It contains approx 1166 lines of Solidity code. All the
functions and state variables are well commented using the natspec
documentation, but that does not create any vulnerability.
• Attacks made to the contract
In order to check for the security of the contract, we tested several attacks in
order to make sure that the contract is secure and follows best practices.
• Over and under flows
An overflow happens when the limit of the type variable uint256, 2 ** 256, is
exceeded. What happens is that the value resets to zero instead of incrementing
more. On the other hand, an underflow happens when you try to subtract 0
minus a number bigger than 0. For example, if you subtract 0 - 1 the result will
be = 2 ** 256 instead of -1. This is quite dangerous.
This contract does check for overflows and underflows by using
OpenZeppelin's SafeMath to mitigate this attack, but all the functions have
strong validations, which prevented this attack.
• Short address attack
If the token contract has enough amount of tokens and the buy function doesn’t
check the length of the address of the sender, the Tron’s virtual machine will
just add zeros to the transaction until the address is complete.
Although this contract is not vulnerable to this attack, but there are some point
where users can mess themselves due to this (Please see below). It is highly
recommended to call functions after checking validity of the address.
• Visibility & Delegate call
It is also known as, The Parity Hack, which occurs while misuse of
Delegate call.
No such issues found in this smart contract and visibility also properly
addressed. There are some places where there is no visibility defined. Smart
Contract will assume “Public” visibility if there is no visibility defined. It is
good practice to explicitly define the visibility, but again, the contract is not
prone to any vulnerability due to this in this case.
• Reentrancy / TheDAO hack
Reentrancy occurs in this case: any interaction from a contract (A) with another
contract (B) and any transfer of Tron hands over control to that contract (B).
This makes it possible for B to call back into A before this interaction is
completed.
Use of “require” function in this smart contract mitigated this vulnerability.
• Forcing Tron to a contract
While implementing “selfdestruct” in smart contract, it sends all the tron to the
target address. Now, if the target address is a contract address, then the fallback
function of target contract does not get called. And thus Hacker can bypass the
“Required” conditions. Here, the Smart Contract’s balance has never been used
as guard, which mitigated this vulnerability.
• Good things in smart contract
• Good required condition in functions:-
o Here you are checking that balance of contract is bigger or equal to the amount
and checking that token is successfully transferred to recipient address.
o Here you are checking that contract has more or equal balance as value amount.
o Here you are checking that target address is proper contract address.
o Here you are checking that newOwner address value is proper valid address.
o Here you are checking that msg.sender is same as _previousOwner and unlock
function not called until 7 days of _lockTime.
o Here you are checking that deliver address should not be called by the Excluded
address.
o Here you are checking that tAmount value should be less than or equal to the
_tTotal amount (Total token value).
o Here you are checking that rAmount value should be less than or equal to the
_rTotal amount (Total reflections value).
o Here you are checking that account address not already excluded from reward.
o Here you are checking that account address not already included for reward.
o Here you are checking that owner and spender address values are proper
addresses.
o Here you are checking that addresses values of from and to are proper, amount
should be bigger than 0 and less than –maxTxAmount (Maximum amount to
transfer token), and owner should be not able to get or send token.
• Critical vulnerabilities found
in the contract
=> No Critial vulnerabilities found
• Medium vulnerabilities found in the
contract
=> No Medium vulnerabilities found
• Low severity vulnerabilities found
o 7.1: Short address attack:-
=> This is not big issue in solidity, because now a days is increased
In the new solidity version. But it is good practice to
Check for the short address.
=> After updating the version of solidity it’s not mandatory.
=> In all functions you are not checking the value of Address
parameter here I am showing only some functions.
Function:- isContract (‘account’)
o It's necessary to check the address value of "account". Because
here you are passing whatever variable comes in "account"
address from outside.
Function:- excludeFromReward, includeInReward (‘account’)
o It's necessary to check the address value of "account". Because
here you are passing whatever variable comes in "account"
address from outside.
Function: - _transferBothExcluded (‘sender’, ‘recipient’)
o It's necessary to check the addresses value of "sender",
"recipient". Because here you are passing whatever variable
comes in "sender", "recipient" addresses from outside.
Function: - _tokenTransfer (‘sender’, ‘recipient’)
o It's necessary to check the addresses value of "sender",
"recipient". Because here you are passing whatever variable
comes in "sender", "recipient" addresses from outside.
Function: - _transferStandard, _transferToExcluded,
_transferFromExcluded (‘sender’, ‘recipient’)
o It's necessary to check the addresses value of "sender",
"recipient". Because here you are passing whatever variable
comes in "sender", "recipient" addresses from outside.
o 7.2: Compiler version is not fixed:-
=> In this file you have put “pragma solidity ^0.6.12;” which is not a good
way to define compiler version.
=> Solidity source files indicate the versions of the compiler they can be
compiled with. Pragma solidity >=0.6.12; // bad: compiles 0.6.12 and above
pragma solidity 0.6.12; //good: compiles 0.6.12 only
=> If you put(>=) symbol then you are able to get compiler version 0.6.12
and above. But if you don’t use(^/>=) symbol then you are able to use only
0.6.12 version. And if there are some changes come in the compiler and you
use the old version then some issues may come at deploy time.
=> Use latest version of solidity.
o 7.3: Approve given more allowance:-
=> I have found that in your approve function user can give more
allowance to user beyond their balance..
=> It is necessary to check that user can give allowance less or
equal to their amount.
=> There is no validation about user balance.
Function: - approve
o Here you can check you have more allowance than balance.
• Summary of the Audit
Overall the code is well and performs well.
Please try to check the address and value of token externally before sending to
the solidity code.
Our final recommendation would be to pay more attention to the visibility of
the functions , hardcoded address and mapping since it’s quite important to
define who’s supposed to executed the functions and to follow best practices
regarding the use of assert, require etc. (which you are doing ;) ).
• Good Point: Address validation and value validation is
done properly.
• Suggestions: Please add address validations at some place
and also try to use static address, check amount in approve
function and I found some place you forgot use safeMath
please do it if possible.
