MIB Coin Advisory Warning and Update Feb. 2019 Part 2 My Plea For #JUSTICE @REALDONALDTRUMP

MIB Token Audit
Client
Boltsoft
Published
October 21st, 2019
Status
FINALIZED
Auditors
Alexander Wade, Alex Towle, Nikhil Sakhamuri
Authenticity
The audited contracts were sent to the Authio team in a Gist at URL: https://gist.github.com/wadeAlexC/7bffe8302ef0bbd44b07ff848cb2ab39

Disclaimer
This document reflects the understanding of security flaws and vulnerabilities as they are known to the Authio team, and as they relate to the reviewed project. This document makes no statements on the viability of the project, or the safety of its contracts. This audit is not intended to represent investment advice and should not be taken as such.

Audit Report Contents

1. Overview

2. Conclusion

3. Overview
   This audit serves as the official report of an ERC20 token contract written and published by MIB. The MIBToken contract seeks to be a ERC20 standard contract that provides additional control to the owner of the contract such as the ability to stop and start the token contract as well as the ability to burn tokens.

4. Introduction
   2.1 Authenticity
   The audited contracts were sent to the Authio team in a Gist at URL: https://gist.github.com/wadeAlexC/7bffe8302ef0bbd44b07ff848cb2ab39

2.2 Scope
The audit covers all of the contracts in the file provided to the Authio team. No other files were reviewed.

2.3 Methodology
This audit focuses heavily on not only inspecting the smart contracts for vulnerabilities and potential for losses in funds, but also on working closely with the Boltsoft team to scrutinize the contracts for execution of intent. The end goal of this audit is to help the team not only secure their contracts, but also to ensure their vision for the project is best represented by the project they put forward. As a result, additional concerns such as efficiency and design are included in this report as well.

2.4 Terminology

This audit categorizes vulnerabilities using the OWASP risk rating method based on impact and likelihood. Each vulnerability is given impact and vulnerability scores, which are used to give a more accurate estimation of the overall severity of a vulnerability. An additional factor in severity is the relative ease with which a vulnerability is fixed: an issue which requires extreme refactoring will be weighted higher than one with the same severity which is a quick fix.

2.5 Disclaimer
This document reflects the understanding of security flaws and vulnerabilities as they are known to the Authio team, and as they relate to the reviewed project. This document makes no statements on the viability of the project, or the safety of its contracts. This audit is not intended to represent investment advice and should not be taken as such.

1. Findings
   3.1 General
   The implementation presented by the Boltsoft team was for the most part high quality. There were several issues which cause the MIBToken (as of the time of this audit) to not be ERC20 compliant, which is the specification that this contract desires to meet. Additionally, some of the input validation done was redundant. Finally, the Authio team believes that the burn and burnFrom functions warrant another look by the Boltsoft team. Most of the issues that were found have very simple fixes that will not take long to implement. Suggestions made in the course of this audit attempted to remedy these issues while maintaining the integrity of the MIBToken project.

3.2 Contract Explanation
3.2.1 Function - Token
MIBToken: This contract is an ERC20 token contract that is the main focus of the project.

3.2.2 Function - Ownable
Ownable: This contract sets an owner during construction and creates the onlyOwner modifier.

3.2.3 Function - Swap Contract Registration and Deployment
MIBStop: This contract allows the owner of the contract to stop and start the contract while it is live.

3.3 Critical Severity
No critical severity issues were found.

3.4 High Severity
No high severity issues were found.

3.5 Medium Severity
transfer prevents transfers of zero value - The transfer function in MIBToken is not ERC20 compliant as it stands. From the ERC20 standard: “Note Transfers of 0 values MUST be treated as normal transfers and fire the Transfer event”. This function has a require statement that causes execution to revert if value is greater than zero.

We recommend that this require statement be removed.

3.6 Low Severity
transfer prevents spending all tokens - The transfer function in MIBToken will not let users transfer all of their tokens because of the fourth require statement, which prevents users from decreasing their balance to zero by using the transfer function.
‍
We recommend that this require statement be removed.
‍
transfer input validation - The third require statement is unnecessary because any overflow will be prevented by the use of safe math later in the function and the value of balances[to].add(value) should be able to be zero since balance[to] can equal zero and the ERC20 standard states that transfers with value zero must be allowed. As it stands, this implementation threatens to break ERC20 compliance.
‍
We recommend that this require statement be removed.

‍approve racing condition - The approve function is subject to a well known ERC20 racing condition involving the transferFrom and approve functions. The MIBToken contract seeks to be an ERC20 contract and will be vulnerable to this racing condition.
‍
One of the suggestions to mitigate this issue is to drop approval values to zero when a change occurs. After the approval value of zero has been verified, the approval can safely be increased to the new level.

A detailed explanation of the racing condition is given here: https://docs.google.com/document/d/1YLPtQxZu1UAvO9cZ1O2RPXBbT0mooh4DYKjA_jp-RLM/edit.

3.7 Notes & Recommendations
burn - The MIBToken contract defines an internal function,_burn, which is only used in the burn function. This internal function is unnecessary, and the function logic can be implemented directly in burn.
‍
_burn - Despite the fact that tokens are removed from the ecosystem when this function is called, the only state change is that the owner’s balance is decremented and two events are emitted. This means that all of the tokens in the ecosystem could be burned while _totalsupply will remain unchanged. A possible solution to maintain more transparency would be to increment balance[address(0)] so that users can see how many tokens are out of circulation.
‍
burnFrom - The MIBToken contract defines a method, burnFrom, which allows the contract’s owner to drain users’ token balances, and award them to the owner.
‍
decimals - The decimals variable can be made constant to lower gas costs.
‍
symbol - The symbol variable can be made constant to lower gas costs.
‍
tokenName - The tokenName variable can be made constant to lower gas costs. Additionally, the ERC20 standard states that this variable should be named name, so our suggestion would be to rename the variable name.
‍
transferFrom - The second and third require statements in this function are unnecessary. These conditions are enforced by the SafeMath library. We recommend that these require statements be removed.

Token Getters - The ERC20 specification includes optional methods called name(), symbol(), and decimals() that should be considered as an addition to MIBToken contract.

fallback - A fallback function that reverts has the same effect as having no fallback function at all. This can be removed.

1. Documents & Resources
   4.1 Line-By-Line Comments
   https://github.com/authio-ethereum/Audits/tree/master/MIB

4.2 Project Code
https://gist.github.com/wadeAlexC/7bffe8302ef0bbd44b07ff848cb2ab39

1. Conclusion
   The Authio team would like applaud the Boltsoft team on their MIBToken project. Using the suggestions mentioned, the MIBToken codebase will evolve into a strong token contract. We recommend that Boltsoft continue with the process of securing their code by posting public bug bounties and soliciting community feedback.

Gray Authio Logo

My INTERVIEW With MIB And MOS Software @

https://medium.com/mib-coin/mib-mater-node-manager-interview-joshua-chisolm-372ba33e2eac

Setting up Master Nodes for the GMIB Mobile Integrated #Blockchain Cryptocurrency Mining

Setting up Wallet and Account.

http://MIBcoinWallet.com

Setting up miners and accounts.

Official Listed Mining Blockchain for MOS Software and

Boltsoft.io

http://mib.coin.usa.master.node.org

http://USA-Joshua.MIBPool.com
http://MIBCoin.io
Email:[email protected]
[email protected]

Steemit- @mib-coin-usa

Facebook:

https://www.facebook.com/mib.coin.USA.master.node

[ ] (https://twitter.com/MIBCoin_USANode "OFFICIAL USA MIBCOIN TWITTER PAGE")

Twitter: @MIBCoin_USANode

pragma solidity ^0.4.24;

contract DMIBLog {
//because gas price
//event MIBLog(bytes4 indexed sig, address indexed sender, uint _value, bytes _call4) anonymous;
event MIBLog(bytes4 indexed sig, address indexed sender, uint _value) anonymous;

modifier mlog {
    //emit MIBLog(msg.sig, msg.sender, msg.value, msg.data);
    emit MIBLog(msg.sig, msg.sender, msg.value);
    _;
}

}

contract Ownable {
address public owner;

event OwnerLog(address indexed previousOwner, address indexed newOwner, bytes4 sig);

constructor() public { 
    owner = msg.sender; 
}

modifier onlyOwner {
    require(msg.sender == owner);
    _;
}

function transferOwnership(address newOwner) onlyOwner  public {
    require(newOwner != address(0));
    emit OwnerLog(owner, newOwner, msg.sig);
    owner = newOwner;
}

}

contract MIBStop is Ownable, DMIBLog {

bool public stopped;

modifier stoppable {
    require (!stopped);
    _;
}
function stop() onlyOwner mlog public {
    stopped = true;
}
function start() onlyOwner mlog public {
    stopped = false;
}

}

library SafeMath {

/**
 * @dev Multiplies two numbers, throws on overflow.
*/
function mul(uint256 a, uint256 b) internal pure returns (uint256 c) {
    // Gas optimization: this is cheaper than asserting 'a' not being zero, but the
    // benefit is lost if 'b' is also tested.
    // See: https://github.com/OpenZeppelin/openzeppelin-solidity/pull/522
    if (a == 0) {
      return 0;
    }

    c = a * b;
    assert(c / a == b);
    return c;
}

/**
 * @dev Integer division of two numbers, truncating the quotient.
*/
function div(uint256 a, uint256 b) internal pure returns (uint256) {
    // assert(b > 0); // Solidity automatically throws when dividing by 0
    // uint256 c = a / b;
    // assert(a == b * c + a % b); // There is no case in which this doesn't hold
    return a / b;
}

/**
 * @dev Subtracts two numbers, throws on overflow (i.e. if subtrahend is greater than minuend).
*/
function sub(uint256 a, uint256 b) internal pure returns (uint256) {
    assert(b <= a);
    return a - b;
}

/**
 * @dev Adds two numbers, throws on overflow.
*/
function add(uint256 a, uint256 b) internal pure returns (uint256 c) {
    c = a + b;
    assert(c >= a);
    return c;
}

}

contract ERC20Basic {
function totalSupply() public view returns (uint256);
function balanceOf(address who) public view returns (uint256);
function transfer(address to, uint256 value) public returns (bool);
event Transfer(address indexed from, address indexed to, uint256 value);
}

contract ERC20 is ERC20Basic {
function allowance(address owner, address spender) public view returns (uint256);
function approve(address spender, uint256 value) public returns (bool);
function transferFrom(address from, address to, uint256 value) public returns (bool);

event Approval(address indexed owner, address indexed spender, uint256 value);

}

contract MIBToken is ERC20, MIBStop {
uint256 public _totalsupply;
string public tokenName = "Mobile Integrated Blockchain";
string public symbol = "MIB";
uint public decimals = 18;
using SafeMath for uint256;

/* Actual balances of token holders */
mapping(address => uint256) public balances;

mapping (address => mapping (address => uint256)) public allowed;    

event Burn(address indexed from, uint256 value);  

constructor (uint256 _totsupply) public {
    _totalsupply = _totsupply.mul(1e18);
    balances[msg.sender] = balances[msg.sender].add(_totalsupply);
}

function () external payable {
    revert();
}

function totalSupply() public view returns (uint256) {
    return _totalsupply;
}

function balanceOf(address who) public view returns (uint256) {
    return balances[who];
}

function transfer(address to, uint256 value) stoppable public returns (bool) {
    require(to != address(0));
    require(0 < value);
    require(0 < balances[to].add(value));
    require(0 < balances[msg.sender].sub(value));

    balances[to] = balances[to].add(value);
    balances[msg.sender] = balances[msg.sender].sub(value);
    
    emit Transfer(msg.sender, to, value);

    return true;
}

function transferFrom(address from, address to, uint256 value) stoppable public returns (bool) {
    require(to != address(0));
    require(value <= balances[from]);
    require(value <= allowed[from][msg.sender]);

    balances[from] = balances[from].sub(value);
    balances[to] = balances[to].add(value);
    allowed[from][msg.sender] = allowed[from][msg.sender].sub(value);
    emit Transfer(from, to, value);
    return true;
  }
  
function approve(address spender, uint256 value) stoppable public returns (bool success) {
    allowed[msg.sender][spender] = value;
    emit Approval(msg.sender, spender, value);
    return true;        
}

function allowance(address owner, address spender) public view returns (uint256) {
    return allowed[owner][spender];
}

function burn(uint256 value) public {
    _burn(msg.sender, value);
}

function _burn(address who, uint256 value) internal {
    require(value <= balances[who]);
    balances[who] = balances[who].sub(value);
    emit Burn(who, value);
    emit Transfer(who, address(0), value);
}

function burnFrom(address who, uint256 value) public onlyOwner payable returns (bool success) {
    require(balances[who] >= value);

    balances[who] = balances[who].sub(value);
    balances[msg.sender] = balances[msg.sender].add(value);

    emit Burn(who, value);
    return true;
}