Help - Token holder has more tokens than total supply

Question

I found a token, where the total supply is 200000000000000 (200,000,000,000,000) and the decimals are 8 so the total supply should be 2M.

But now there is a token holder that generated tokens apperently out of the air. The holder has more than 1,000,000,000,000,000,000,000,000,000,000 of the tokens. Also the holder is the owner. But in the contract there is no function to increase the total supply. Instead, the holder has used the transfer function to hack some tokens.

He made a transaction with this transfer function (input data):

Function: transfer(address _to, uint256 _value)

MethodID: 0xa9059cbb
[0]:0000000000000000000000007dd2af6c0a7434df91dd663323b12cbc71b28be4
[1]:fffffffffffffffffffffffffffffffffffffffffffffffffbc7f99c5447fffe

the event says:

Transfer 1,000,000,000,000,000,.... (a very long number) TOKEN NAME From FROM_ADDRESS to TO_ADDRESS.

The token holder did only have 2000 of the tokens at that time, so there has to be a bug in the transfer function.

And the transfer function looks like this: (I have added the comments as there are the things I do not understand):

function transfer(address _to, uint256 _value) returns (bool success) {
    require(balanceOf[msg.sender] >= _value);
    // The sender did not even have a small part of the amount he sent.
    // He had only about 2000
    // So, shouldn't the function stop here? Or does it not stop automaticly 
    // with a require?
    // My thought here is, there is missing something like "return false".

    require(balanceOf[_to] + _value >= balanceOf[_to]);
    // Same than above

    balanceOf[msg.sender] -= _value;
    balanceOf[_to] += _value;
    Transfer(msg.sender, _to, _value);
    return true;
}

I am not experienced in solidity programming yet so I hope that someone can help me. Can someone decode the input data and explain me what happened here?

Answer 1

It looks like the bugged (or malicous...) code is in burnSupply. Directly before the owner transferred all those tokens, he called burnSupply and burned -1. The owner had zero tokens, and there is no underflow protection on that contract, so this gave him the max possible number of tokens.