SMART CONTRACT SECURITY AUDIT: MEMBRANA

MEMBRANA
Membrana is a decentralized platform which redefines trust, it aspires to bring investors and traders in a secure network where both the parties can mutually benefit from blockchain-protected contracts. The transparency and security offered by Membrana platform instigate trust which eventually benefits both parties. The main objective of Membrana.io is to bring much-needed transparency in high-risk investments by making trust management more profitable and secure.  

Complications in Existing Trust Management System
At present, there is no convenient and safe tool available in the market that can be effectively used for the conclusion of contracts between investors and traders. When trading cryptocurrencies, there is often lack of trust between the parties as these contracts are usually active in words, forums, and chats. As a result, this leads to fraudulent acts and lack of transparency with increased risks for investors and traders.

Membrana’s Solution
Membrana platform makes room for the investors to give traders an opportunity to manage funds, however not to possess these funds, thereby making it secure and transparent. Here, traders do not own these funds as the smart contracts are executed when certain criteria are met in the blockchain network. Membrana.io guarantees ethical trading of assets along with the fulfillment of contract terms by diminishing the lack of trust among the parties as well as the risk that comes along in the form of violation of contractual terms.

Teachracers’ team was approached to perform a step-by-step Security Audit for Membrana.io’s  Smart Contract. Below is the report and highlighted vulnerabilities which were identified and further addressed:

Manual Audit

Style Guide Violations
Not necessary to resolve but increase readability and enforces style guide standards accepted by the global community. An example image from the contract has been added for each violation but similar violations may repeat themselves within the contract.

  1. Usage of obsolete pragma versions of solidity cited within the contract, instead the latest stable version 0.4.20, commit 3155dd80, should be used.SMART CONTRACT SECURITY AUDIT: MEMBRANA
  2. It is a standard practice to use the same pragma version throughout the contracts. Instead different pragma versions were cited in different contracts.SMART CONTRACT SECURITY AUDIT: MEMBRANA
    SMART CONTRACT SECURITY AUDIT: MEMBRANA
    SMART CONTRACT SECURITY AUDIT: MEMBRANA
  3. Pragma should be locked before deployment in every contract. (ref) (For example, 0.4.18 is locked whereas ^0.4.18 is not).
  4. Top level declarations in solidity should have two blank lines before them. (ref)
    SMART CONTRACT SECURITY AUDIT: MEMBRANA
  5. Solidity recommends to surround function declarations with a single blank line within a contract. But, within the contract MercatusDeals.sol no such recommendation is followed. (ref)
    SMART CONTRACT SECURITY AUDIT: MEMBRANA
  6. No indentation strategy is followed within the code, this makes it very difficult to read. Please refer to Solidity Official Style Guideindentation recommendation, which proposes 4 spaces without mixing it with tabs for indentation
    SMART CONTRACT SECURITY AUDIT: MEMBRANA
  7. Function order is incorrect at multiple instances within the contracts, the correct
    order is as follows: (ref)
    Constructor
    -Fallback function (if exists)
    – External
    – Public
    – Internal
    – Private
    SMART CONTRACT SECURITY AUDIT: MEMBRANA
  8. Length of a line must not exceed 120 characters, but line length for declaration of makeDeal function equals 220 characters. Similarly getSplit function is 121 characters long.
    SMART CONTRACT SECURITY AUDIT: MEMBRANA
  9. Definitions within contracts/libraries must be separated by 1 line. (ref)
    SMART CONTRACT SECURITY AUDIT: MEMBRANA
  10. Enum names must be in CamelCase, therefore enum state should be changed to State, and enum currencyType should be changed to CurrencyType.
    SMART CONTRACT SECURITY AUDIT: MEMBRANA
  11. Event names must be in CamelCase, therefore event name spawnInstance should be changed to SpawnInstance.
    SMART CONTRACT SECURITY AUDIT: MEMBRANA
  12. Expression indentation is incorrect, we should use same number of spaces on both side of an operator.
    SMART CONTRACT SECURITY AUDIT: MEMBRANA
  13. Comma must be separated by next element, with a space
    SMART CONTRACT SECURITY AUDIT: MEMBRANA
  14. Expression indentation is incorrect, required no spaces after ( and before ), in the following expression:
    SMART CONTRACT SECURITY AUDIT: MEMBRANA
    Similar violation also present here:
    SMART CONTRACT SECURITY AUDIT: MEMBRANA
  15. While declaring a function there should be a space between “)” and “{”. Similar mistake can be cited at multiple instances.
    SMART CONTRACT SECURITY AUDIT: MEMBRANA
  16. Visibility of all functions should be specified, failing which it is defaulted to public. (ref)
    Other than this, open bracket, i.e. “{” must be indented by other constructions by space.SMART CONTRACT SECURITY AUDIT: MEMBRANA
  17. Wrong spacing cited during the following function declarations:
    SMART CONTRACT SECURITY AUDIT: MEMBRANA
    There should be a single space between “)” and “{“.
  18. There should be a space between if and “()”. (ref)
    SMART CONTRACT SECURITY AUDIT: MEMBRANA
  19. Visibility modifiers should be first among the list of modifiers in a function declaration. Therefore in function makeDeal, public should appear before payable

    SMART CONTRACT SECURITY AUDIT: MEMBRANA
  20. Visibility of all state variables should be explicitly specified, failing which it is defaulted to ’internal’.
    SMART CONTRACT SECURITY AUDIT: MEMBRANA

Minor Considerations

  1. be” is an ambiguous address parameter name, similarly onlyBe becomes an ambiguous modifier name, it should be renamed to something more relevant and easy to understand.
    SMART CONTRACT SECURITY AUDIT: MEMBRANA
  2. In struct Deal, variable start and deadline represent time intervals, so it would be more appropriate to rename them to startTime and endTime.
    SMART CONTRACT SECURITY AUDIT: MEMBRANA
    Similarly, it would be better to rename parameters investor and trader to investorName and traderName.
    SMART CONTRACT SECURITY AUDIT: MEMBRANA
  3. Modifier can be updated from constant to view in getState and getStart function.
    SMART CONTRACT SECURITY AUDIT: MEMBRANA
  4. Re-entrancy is on of the major considerations of Solidity, you need to follow a specific code structure in-order to avoid it, and such standard practises should be respected, one of them is to make all the state changes before you use call.value, send or transfer functions, a violation against this rule can be cited within the contracts in functions setHalted and setFinished, we can solve it by changing the currentState of a deal before transfer function is used, in case transfer fails, it is designed to automatically revert back the state changes already happened in the function.
    SMART CONTRACT SECURITY AUDIT: MEMBRANA
  5. Parameter amount represents the amount in terms of wei, a sub unit of ether. So, it should be renamed to weiAmount for clarity.
    SMART CONTRACT SECURITY AUDIT: MEMBRANA
  6. The initial state of enums is defaulted to their first state, therefore default state of every instance of state enum will be paid, and currencyType enum will be USDT. a default state for both enums, representing not-initialized should be used.
    SMART CONTRACT SECURITY AUDIT: MEMBRANA
  7. It is a good practice to add events in important functions that change state. It makes it easier for the front end application to be built around the smart contract. Only one event is fired from the current contract, it is a suggestion to add more.

Major Considerations

  1. Variable dealsCount is declared, but it is not used within the MercatusDeals contract.
    SMART CONTRACT SECURITY AUDIT: MEMBRANA
  2. be” parameter’s address is hardcoded into the contracts and then onlyBe modifier is used in many functions, hardcoding owner addresses is not a good practise and instead Ownable contract should be inherited within MercatusDeals contract, this will also enable provisions to transfer ownership and other maintenance functions.
    SMART CONTRACT SECURITY AUDIT: MEMBRANA
  3. In the MercatusDeals contract, constructor and fallback functions are payable. This means they can accept Ethers while being called, we don’t see any benefit in making the constructor to the said contract payable, i.e. sending money to the contract while deploying it. Also making these two functions payable, exposes a critical issue. These functions allow the contract to accept ethers which cannot be handled by any function present in the contract, therefore Ethers sent to the contract using these two functions will be stuck in the contract forever. There is a different function in the contract namely makeDeal, it is handling the Ethers sent to it using functions setHalted and setFinished, but same cannot be said for Ethers from constructor and fallback.
    SMART CONTRACT SECURITY AUDIT: MEMBRANA
  4. Possible Integer Underflow/Overflow can happen in the contract, many +, -, *, / operators are used carelessly, which can trigger such a situation. We advise to use safeMath library from zeppelin, already present within the client repository to remove this vulnerability.
    SMART CONTRACT SECURITY AUDIT: MEMBRANA
  5. Array deals is used within contract, instead a mapping should be used, this is because arrays consume more gas while creation/updation as compared to a mapping.
    SMART CONTRACT SECURITY AUDIT: MEMBRANA
  6. No address(0) checks present within makeDeal function to check _traderAddress and _investorAddress.
  7. Parameter _amount is not needed within makeDeal function, already available msg.value parameter is enough to suffice it’s use.
    SMART CONTRACT SECURITY AUDIT: MEMBRANA
  8. _duration in the makeDeal() function must be passed in seconds unit rather than in days. Because it will not be possible to create a deal with duration which is not a multiple of days. A deal with duration of 5.5 days will not be possible. Using seconds will be more flexible.
  9. In makeDeal() function the use of offer variable  is not clear. It is not being saved anywhere and is being used only in SpawnInstance event. Same is the case with msg.sender.
  10. In makeDeal() function it must be checked that msg.value is not equal to zero. It does not make sense to make a deal with zero value.
  11. A kill() function must be added to this smart contract with modifier onlyBe. As this contract stores Ethers at its address it is very important that the owner could call the selfdestruct() function and save his Ethers in case of an emergency. If no kill function all the ethers will be stuck at contract address with no use.

Automated Audit

Mythril

  1. Warning
    SMART CONTRACT SECURITY AUDIT: MEMBRANA
  2. Warning 2:
    SMART CONTRACT SECURITY AUDIT: MEMBRANA
  3. Warning 3:
    SMART CONTRACT SECURITY AUDIT: MEMBRANA
  4. Warning
    SMART CONTRACT SECURITY AUDIT: MEMBRANA

Oyente:
SMART CONTRACT SECURITY AUDIT: MEMBRANA

Securify
Unable to compile the contract and results in an error.

Remix
Successfully deployed contract on Ropsten network and in JavaScript VM. You can see the transaction here. Gas used by transaction was: 10,30,790. Successfully ran makeBet function on Ropsten, cannot test functions with onlyBe modifier because be is hardcoded.

Summary
The code quality needs to be improved and there are many minor/major issues that are important to be addresses before contracts are deployed on Ethereum mainnet, many contracts which can solve some of the above mentioned problems are already present within client’s repository, but not used within the contracts.

Conclusion
We performed our audit as perto the procedure described above. Our team also carefully checked Smart Contracts logic and compared it with the one described in the Membrana white paper. As a result, few medium,minor and major vulnerabilities were found and notified.

 

 

SMART CONTRACT SECURITY AUDIT: TriForce

TriForce Tokens is a decentralized platform which makes use of blockchain technology to provide users within the iGaming community with decentralized P2P trading, anti-piracy protection, and the world’s first honorary rewards system. TriForce tokens follow three foundations of the technology i.e. Revenue Generation, Players and Developers Protection and Community Collaboration.

The network will strive to build community collaboration amongst players, whilst encouraging them to work together and reward one another.

Existing loopholes in iGaming ecosystem:

Problems for the Player
The gamers hoard reward points in terms of tokens which cannot be used in any other gaming platform, making it complicated. Moreover, sharing critical banking details put the players at a risk of being hacked, which cause financial loss and brand disloyalty. It is possible for hackers to insert themselves into the middle of the process where they can inject malicious commands and also make the use of updater to hijack the gaming machines. The multiple players in a gaming matrix do not have room to interact and play apace one game, therefore, cross-platform play is not facilitated making it a major concern among the gamers.  

Problems for the Developer
At present, solutions to support the digital monetization and online growth strategies is scarce. Since more than the quarter revenue is shared with the developers, this adds up to become the biggest concern. Revenue management in the existing gaming system works like a Sloth, making it difficult to maintain close relationships with end consumers. The likelihood of piracy in iGaming industry equates to a reduction in game sales thereby impacting the overall revenue.

The TriForce Solution
With the use of TriForce Tokens, developers will once again increase their revenues and margins further allowing innovation and implementation of new thoughts. TriForce also intends to minimize the price to a manageable level and therefore improving the player’s gaming experience and by providing lucrative solutions to all the parties involved in the network. The blockchain technology bridges the gap and fills the loopholes in the existing iGaming landscape. This will likewise grow consumer relationships across properties and platforms and facilitates a direct developer-to-player channel by addressing the major concerns of both the parties.

Procedures
Techracers Team was approached to access the TriToken Smart Contract and pinpoint the vulnerabilities along with the potential threats. The major task was to discover and outline security issues in the Smart Contracts of the TriForce platform. We used several publicly available automated Solidity analysis tools and manually checked for vulnerabilities further.

Below is our assessment and recommendations:

 

Style Guide Violations

Not necessary to resolve but increase readability and enforces style guide standards accepted by the global community. An example image from the contracts has been added for each violation but similar violations can be cited in many contracts.

 

  1. Usage of obsolete pragma versions of solidity instead of the latest stable one (0.4.18).
    SMART CONTRACT SECURITY AUDIT: TriForce

  2. It is a standard practice to use the same pragma version throughout the contracts.SMART CONTRACT SECURITY AUDIT: TriForce  SMART CONTRACT SECURITY AUDIT: TriForce
  3. Pragma should be locked before deployment in every contract. (ref) (For example, 0.4.18 is locked whereas ^0.4.18 is not).
  4. While declaring a function there should be a space between “)” and “{”.
    SMART CONTRACT SECURITY AUDIT: TriForce
  5. Visibility of all functions should be specified, failing which it is defaulted to ‘public’. (ref)
    SMART CONTRACT SECURITY AUDIT: TriForce          
  6. Top level declarations in solidity should have two blank lines before them. (ref)
    SMART CONTRACT SECURITY AUDIT: TriForce

  7. The default value for a bool variable is false so there is no need to initialize it. (ref)
    SMART CONTRACT SECURITY AUDIT: TriForce

  8. There should be a space between if and (). (ref)
    SMART CONTRACT SECURITY AUDIT: TriForce

  9. Two spaces have been used for indentation in almost all contracts, instead four spaces are recommended per indentation level. (ref)
    SMART CONTRACT SECURITY AUDIT: TriForce
  10. Line length should be restricted to 120 characters.
    SMART CONTRACT SECURITY AUDIT: TriForce
  11. Throw is deprecated in favour of revert(), require and assert(). It will be removed in future.
    SMART CONTRACT SECURITY AUDIT: TriForce

  12. String Literals must be quoted with “double quotes” only. Including imports. (ref)
    SMART CONTRACT SECURITY AUDIT: TriForce

  13. Function order is incorrect at multiple instances within the contracts, the correct order is as follows: (ref)
    Constructor

– Fallback function (if exists)

– External

– Public

– Internal

– Private
SMART CONTRACT SECURITY AUDIT: TriForce

14.There should be a single space before a function. (ref)              SMART CONTRACT SECURITY AUDIT: TriForce15.  Function with wrong modifiers present within contracts, currently solidity does not enforce modifier types, but it is a     wrong practise. For instance the following function is marked constant, though it is updating a state variable                                   totalSupply.
SMART CONTRACT SECURITY AUDIT: TriForce
16.Confusing parameter and function names are present within contracts, same names can shadow a previous declaration,   as in the example shown below, isAdmin is both a return type and a function name:

SMART CONTRACT SECURITY AUDIT: TriForce17.  Unused parameters are present inside various functions like in the following example _cap parameter was never used.

SMART CONTRACT SECURITY AUDIT: TriForce

Automated Testing:

Mythril:
Mythril displays the following two concerns for the audited contracts:

  1. A possible Integer underflow exists in function transferFrom.
    SMART CONTRACT SECURITY AUDIT: TriForce
  2. A possible Integer underflow exists in function transfer.
    SMART CONTRACT SECURITY AUDIT: TriForce

Securify:

  1. Force.sol:
    SMART CONTRACT SECURITY AUDIT: TriForce

  2. TriController.sol:
    SMART CONTRACT SECURITY AUDIT: TriForce

  3. TriForceNetworkCrowdsale.sol:
    SMART CONTRACT SECURITY AUDIT: TriForce

Oyente:

  1. WhiteList.sol:
    SMART CONTRACT SECURITY AUDIT: TriForce
  2. TriForceNetworkCrowdsale.sol:
    SMART CONTRACT SECURITY AUDIT: TriForce
  3. RefundVault.sol:
    SMART CONTRACT SECURITY AUDIT: TriForce
  4. Force.sol:
    SMART CONTRACT SECURITY AUDIT: TriForce
  5. Token.sol:
    SMART CONTRACT SECURITY AUDIT: TriForce
  6. SimpleControl.sol:
    SMART CONTRACT SECURITY AUDIT: TriForce
  7. DataManager.sol:
    SMART CONTRACT SECURITY AUDIT: TriForce
  8. DataCentre.sol:
    SMART CONTRACT SECURITY AUDIT: TriForce
  9. CrowdsaleControl.sol:
    SMART CONTRACT SECURITY AUDIT: TriForce
  10. Controller.sol:
    SMART CONTRACT SECURITY AUDIT: TriForce
  11. TriController.sol:
    SMART CONTRACT SECURITY AUDIT: TriForce

Manual Testing

  1. TriForceNetworkCrowdsale.sol
    1. There is no need for WhitelistedCrowdsale contract to inherit Crowdsale contract. Everything will work fine even without it.
    2. In whitelist contract which is being used in this crowdsale 2 more functions can be added which will add or remove the whitelisted addresses in bulk. It should also fire events when any whitelisted address is added or removed so that, later if we want to find the list of all addresses who have been whitelisted then we cannot get this list from a mapping.
    3. An interface of whitelist contract can be included which only has one function isWhitelisted(), this will slilghtly reduce gas at the time of deployment of TriForceNetworkCrowdsale.sol.
    4. In refundvault contract being used in this crowdsale we can fire an event when deposit function is called.
    5. Selfdestruct functionality can be added in the refund vault contract so that all the ethers in the vault can be transferred to a safe address in case of any bug.
  2. TriController.sol
    1. Token contract is being used in this TriController contract. We need to call mint() and mintToggle() functions of Token contract deployed separately. To achieve this we need not to import all the contracts we can create a interface of functions that we are going to use. This will slightly reduce the gas consumed at time of deployment.
  3. Force.sol   Everything looks good. All ERC20 and ERC223 functions working fine.

Summary
All above points are suggestions to optimize the code. Overall the code looks impeccable and it is designed in a way which makes it easily upgradable. If any bugs are encountered all the functions can be paused for everyone (except for admins) and then the controller contract will be killed and a new controller can be set.

CONCLUSION
The problems that we have found in TriForce Tokens are described above. We successfully scanned TriForce’s Smart Contracts for commonly known and more specific vulnerabilities. We used publicly available automated Solidity analysis tools which manually analyzed the contracts. Further, the Smart Contracts logic was checked and the analysis displayed high code quality and security of the project. Techracer’s smart contract security audit services successfully addressed commonly known vulnerabilities and the issues were fixed to make the Smart Contracts completely secure.

The importance of security of the code cannot be overstated, especially when we consider auditing your smart contracts. It is perhaps the only way to ensure that your smart contract will do as it has been programmed to do. Preparing a smart contract is not just about writing impeccable codes that no hackers can get, but it should also consider prevention against bugs.

Smart Contract Security Audit: Peculium

What are Smart Contracts?
Self-executing contracts that contain and validate certain terms and conditions of agreement between sellers and buyers in the form of code are termed as Smart contracts. These line of codes containing the agreement once finalized, are stored on a decentralized blockchain network.

The need of smart contracts arises to build trust between unknown parties who are willing to sign an agreement without the involvement of a central authority of any external system. Transaction rendered in smart contracts are transparent as well as irreversible.

Smart contracts facilitate the exchange of money, property or anything valuable without the need of any middleman. They guarantee automation and transparency in online processes.With this, it becomes highly important to secure these contracts too.

What’s the need of Security Audit for Smart Contracts?
Since the agreements stored in smart contracts are of crucial importance for multiple parties involved, it’s necessary to secure these agreements from hackers via security audit. Every smart contract needs an audit in order to prevent issues like data loss, breaches and thefts.

There are certain advantages of Auditing Smart Contracts such as:

  1. Code optimization for running the code efficiently
  2. Authorization reinforcement
  3. Call methods on Smart Contract

How Techracers performs Smart Contract Security Audit?
The need of application security has increased with the introduction of Smart contracts. We help companies in creating compelling and secure Smart Contract codes.

We perform code audits for organizations by reviewing their smart contracts code and writing each and every issue detected in an actionable report. This includes potential code problems, security recommendations as well as general analysis.

After the complete analysis, our developers review claims and fix the application code using industry-standard security patterns and best practices.

Peculium Smart Contract Security Audit

Introduction
Techracers Blockhchain team was given the task of performing the Peculium Smart Contract Security Audit. Peculium is a savings management platform that utilizes blockchain technology for savings management by deploying immutable smart contracts on Ethereum blockchain. It provides effective savings management solutions for individuals, brokers, and enterprises as per the underlying value of crypto-assets.

The code of Peculium smart contract is here- https://etherscan.io/address/0x53148bb4551707edf51a1e8d7a93698d18931225#code

Code references marked in PURPLE

Major Issues

  1. No ERC223 compatibility present inside contracts. Tokens get stuck in contracts UNKNOWINGLY when using ERC20. (ref)
  2. A lot of failed transactions on etherscan because of the require break in transfer function, as shown in the following snippet:
     transactions on etherscan
    Why Users should be made aware of the require break, ‘Can only transfer after 24th January’, if they have a dapp or a newsletter. Unnecessary gas wastage for users.
  3. Similarly, for approve + transferFrom, users will have lots of failed transactions due to the require break similar to the one in point 2.
     transactions on etherscan
  4. SafeERC20 library imported but not used anywhere. This leads to unnecessary deployment gas costs. Following is the SafeERC20 library:
     transactions on etherscan

    None of it’s functions are used but it is still inherited:
     Smart Contract Security Audit Services
  5. In function approveAndCall, untrusted external calls to contracts are present, this should be explicitly labelled as untrusted i.e _spender should be marked as _untrustedRecipient instead of _spender.
     Smart Contract Security Audit Services

Minor Issues

  1. The code’s indentation is so bad it would be difficult to list all the violations made, this leads to very poor code readability. Please go through the Solidity’s official style guide and improve it.
     Smart Contract Security Audit Services

  2. Function name freezeAccount(address target,bool canSell) is a misleading name, it should be updated to toggleAccountFreeze(address target,bool canSell),this is because owner can also unfreeze accounts using this function.
     Smart Contract Security Audit Services
  3. Similarly, event FrozenFunds(address target, bool frozen) is also a misleading name, it should be updated because, bool frozen can also be false.
     Smart Contract Security Audit Services
  4. now is used for time approximation within contracts, but block numbers are more accurate. You can ignore this recommendation if your functionality is not that time dependent.
     Smart Contract Security Audit Services

  5. Should burn token be a public function? This will let anybody burn his own tokens.
     Smart Contract Security Audit Services
  6. No need for the function getBlockTimestamp. The functionality to check it is already available and there are a lot of ways to do it.
     Smart Contract Security Audit Services
  7. Misleading naming convention balancesCanSell.
  8. Improper commenting techniques used throughout the code.
  9. Pragma should be locked before deployment in every contract. (ref) (For example, 0.4.13 is locked whereas ^0.4.13 is not).
  10. sha3 has been deprecated in favour of keccak256.
     Smart Contract Security Audit Services
  11. No address(0) check for input parameter- target, in function freezeAccount.
  12. No address(0) check for input parameter- _spender, in function approveAndCall.
  13. No check for _spender attribute to be a contract in function approveAndCall. Insted following function should be used:
     Smart Contract Security Audit Services

  14. Following code can be used to introduce re-entrancy, though it will not be a problem right now because value is assigned directly, but that itself is wrong. Also did not find any receiveApproval function in the provided code, therefore cannot check it.
     Smart Contract Security Audit Services
  15. _value has been directly assigned in allowed mapping, instead add function of safeMath library should be used. Why should we assign value directly, suppose a case where a user has allowed 1000 tokens, now he wants to add 500 more tokens to the value, upon calling approveAndCall function with 500, now the allowed mapping will be set to 500, instead of 1500 tokens.
  16. No check for msg.sender token balance before increasing allowed mapping in the following two functions.
     Smart Contract Security Audit Services
     Smart Contract Security Audit Services
  17. Too many failed transactions on etherscan.io due to the condition
     Smart Contract Security Audit Services
    I guess people are not aware about the condition.

Automated Analysis

Oyente:

  1. BasicToken:
     Smart Contract Security Audit Services
  2. BurnableToken:
     Smart Contract Security Audit Services
  3. Peculium:
     Smart Contract Security Audit Services
  4. StandardToken:
     Smart Contract Security Audit Services

Mythril:

 

  1. Integer underflow:
     Smart Contract Security Audit Services
  2. Call with gas to dynamic address:

 Smart Contract Security Audit Services
Securify
Securify