What really happened during the EOSPlay hack

It’s been almost two weeks already since EOSPlay (and other EOSIO casinos) were hacked, and there are already many attempts at explanations circulating around. However, I’d still like to give my thoughts on the hack as I found the existing explanations to all be inaccurate, and then that’s what you do on the internet.

Let’s have a look at the existing explanations:

What’s right is that the hacker rented lots of bandwidth from REX to congest the network and created many deferred transactions, but if one understands how EOSPlay works (or worked at the time of the hack) it quickly becomes clear that there’s no way to cherry-pick winning transactions or calculate if you’re winning from within the block where the outcome is being decided.

How EOSPlay works

The attacker played EOSPlay’s DICE game which works as follows:

How is the outcome produced? Unlike other dice games, EOS Dice does not generate the numbers internally, by allowing players to bet on the last 2 digits of the 10th Block ID after the bet is confirmed, players can be assured that the results are always fair. For example, if your bet of 5 EOS has its transaction recorded in block 19125344, then the outcome will be retrieved from the 10th block ID after this (19125344 + 10) = 19125354. For the purposes of this game, block 19125344 is considered the betting block, whereas block 19125354 is considered the outcome block. When the last two digits are not numbers, we will find the nearest digits in turn. The ID of the EOS block is a 32-byte number, which is randomly generated according to a series of complicated encryption algorithms. The usual display mode is hexadecimal, and our lottery number is using such a truly random number. The result is used as the outcome number.

So if you send 600 EOS to EOS Dice at betting block 79205964, EOS Dice will look at the block hash of result block 79205974 (= betting block + 10) and take the first two characters from the right in range 0-9 as the dice roll:

=> will roll `42` as `b` and `f` is not a valid base 10 number.

This block hash is fetched by an off-chain script of EOSPlay and pushed to the blockchain in a dicereveal action.

Delaying or blocking this action by congesting the network does not help in any way when you try to win the game as the script will still always fetch the block hash of the result block. In fact, delaying/blocking this action only hurts you — the EOS bet amount was already transferred to EOSPlay’s contract 10 blocks ago and this dicereveal action is the one that resolves the bet and schedules the winning payouts.

You can also not get the current block hash (or previous ones) from within a smart contract, because the current block is not final yet and it depends on what transactions are part of it.

How the EOSIO block ID is computed

To understand the attack one first needs to understand how the EOSIO Block ID or Block hash is computed. Looking at its EOSIO source code we see it’s the SHA256 hash of the block header with the block number encoded:

digest_type block_header::digest()const
return digest_type::hash(*this);

block_id_type block_header::id()const
// Do not include signed_block_header attributes in id, specifically exclude producer_signature.
block_id_type result = digest(); //fc::sha256::hash(*static_cast<const block_header*>(this));
result._hash[0] &= 0xffffffff00000000;
result._hash[0] += fc::endian_reverse_u32(block_num()); // store the block num in the ID, 160 bits is plenty for the hash
return result;

The block header, that the hash is computed over, consists of the following values:

struct block_header
block_timestamp_type timestamp;
account_name producer;

uint16_t confirmed = 1;

block_id_type previous;

checksum256_type transaction_mroot; /// mroot of cycles_summary
checksum256_type action_mroot; /// mroot of all delivered action receipts

uint32_t schedule_version = 0;
optional<producer_schedule_type> new_producers;
extensions_type header_extensions;

Note how the signature of the producer (in signed block headers structure) is not used in the block ID computation in EOSIO.

These values can also be seen on block explorers, for example in the Raw view of bloks.io:

Block Header

The big revelation is that most of the block header values are easy to know in advance, especially if there are no transactions, which sets the merkle root hash transaction_mroot to 0.

An interesting value is the action_mroot which has a new non-zero value even if there are no transactions. Unfortunately, I could not find the code for its computation anywhere. (Here's some old code which should result in 0 for empty transactions as well.) All I found is a post by Dan:

The action_mroot creates a mroot over all dispatched actions that were evaluated while applying transactions in the block.

My current speculation is that it includes the eosio::onblock action. This can then also be precomputed as its input is the already known/predicted previous block header (current head block at the time of creating a new block).

(This onblock action can be seen on eosq.)

If you know how exactly action_mroot is computed or what action traces it considers for the computations, please let me know and I will update this section.

The Attack

It’s clear now how the attack on EOSPlay’s dice game works: One predicts the block hash of the result block. The only unknowns in the prediction are the transactions included in the blocks. But what if one could just spam and congest the network so nobody else can send transactions. 🤔 That’s the real reason for renting so much CPU from REX — having control over the network which makes it easy to predict the block hashes.

After analyzing the hack, the attacker seems to do the following:

  1. Rent CPU from REX. Stake to your account and EOSPlay’s account (to be able to get paid out)
  2. SPAM the network
  3. Play one (actually multiple) dice games betting on a 50/50 outcome. (roll < 50)
  4. Stop the SPAM some blocks before the result block. (I assume the attacker did this to make the prediction easier again. Otherwise, you never know how much SPAM transactions will be included in what block.)
  5. Calculate the block hash of the result block assuming no further transactions will be included in the upcoming blocks.
  6. If it would be a win, do nothing. (happens with 50%)
  7. If not, send a random transaction. This is like having another coin flip for the game outcome in the losing case. (happens with 50%)

In total, you would have a win percentage of 75% (0.5 + 0.5 * 0.5) instead of 50% which is already enough to beat the house edge over a short period.

Having a closer look at the attack

We could stop here, but let’s have a closer look at the attack and the smart contract that was used.

The attacker was in control of several accounts, the main one was mumachayinmm. This one was used to attack EOSPlay’s dice game contract eosplaybrand. Other accounts like mumachayinm1, mumachayinm2, etc., were used to attack Dapp Spinach’s games.

The mumachayinmm account is the only one with a smart contract and responsible for the SPAM.


There were 8 relevant rentcpu actions:

  • 7 actions renting a total of 300 EOS in CPU for mumachayinmm. (5 times 20 EOS + 2 times 100 EOS)
  • 1 action renting a total of 10 EOS in CPU for eosplayadmin. This is the account that authorizes the dicereveal action (among others) determining the wins.

Attack trace

To better understand the attacker’s smart contract, we can have a look at an attack trace first. This one includes all actions the attacker did from a single EOSPlay attack. The indented actions are SPAM actions (run/start).

The full attack transaction trace is available in this gist.

The attack starts at block 79205964 with a send action which transfers 5 * 600 EOS and plays the dice game with win condition "dice under 50". Then the spam continues, the result block time is set by settime. Some blocks before the result block the spam is stopped. As the game is calculated to be a win, no additional action had to be sent to change the block hash for block 79205974. Now the spam continues, probably already preparing for the next game. The dicereveal and the payout actions are delayed, but it doesn't matter.

The smart contract

The smart contract deployed on mumachayinmm is closed-source but we can infer what it does based on observing the side effects and RAM / DB operations on block explorers like eosq. I decompiled the contract so you can look at a C representation of the source code (, although, I find the WAST representation easier to reverse-engineer).

The analysis is for the contract used for attacking EOSPlay. There were several other contracts deployed attacking different casinos but they seem to use mostly the same code.

Here are the most interesting actions:


Schedules itself another start transaction and 10 delayed run transactions with a delay of 0 seconds.

  • Takes id=X which schedules the next start action with id'=X+1. All 10 run ids are (id+1) * 1000 + index.
  • Takes num, and just passes this parameter on to the run actions.


Writes to the kkks table and is used to turn the spam on/off, depending on whether it is invoked with ok=1 or ok=0.


Updates the targettime field in the configs table. An example config table looks like this:

"x2": 400000,
"x1": 450000,
"targettime": "1568403713000",
"betnum": 5,
"flag": 1,
"amount": 6000000,
"id": 0

There are many similar setX actions that set a field in the config.


Reads config and sends configs.betnum many inline transfers of bets with an EOS amount of configs.amount to a hard-coded account. (In our case always eosplaybrand.)

This is used to start the bets and probably to circumvent a max bet amount imposed by the casinos by sending several transfer actions.


This is the spam action. It either runs really long, returns immediately, or runs for an infinite amount of time before it times out.

To better understand the different behaviors I reverse-engineered this action and it turns out that this action is the most interesting one. Here’s its simplified pseudo code:

void run(uint64_t num) {
// if running in target block or one before target block, go into infinite loop
if(configs.targettime == current_time() || configs.targettime - 500 == current_time()) {
// infinite loop
while(true) {};

// return if any of these flags are not set
if(kkks.flag == 0) return;
if(infos.currentvc == 0) return;

// otherwise do some dummy computation to waste time
a = 1.0;
for(i=0; i < num; i++) {
a *= 2.8;
print('a=', a);

If the run action is running in the target result block (where the block hash is taken from to resolve the bet) or one block before, it goes into an infinite loop. As stated in the attack, this is done to avoid any transactions in the result block. The transaction times out which then is not part of the block, but as it is a deferred transaction it is directly executed at the producing node (?) wasting its time and making it not pick up any other transactions.

Otherwise, it checks some tables if it should run the spam transactions. To waste CPU bandwidth it then does useless floating-point arithmetic in a loop with the iterations determined by the num action parameter.


I’m not sure what this action is used for, maybe just to change the block hash in case the attacker would lose the game.

Other stats

Let’s look at some stats. I used dfuse.io and their great GraphQL search features that can be used directly from the playground.

Dice Win Stats

Here are the stats for how many bets were played and how much EOS was won playing EOSPlay’s Dice.

Attacker Stats playing EOSPlay’s Dice game.

Not as impressive as everyone made it out to be. The win percentage of the attacker was only 57%. The actual profits are also “only” 27,786 EOS even though there was 100k EOS in EOSPlay’s bankroll. Not the 100k EOS loss that is claimed in every other article about the hack.

An interesting fact is that the attacker lost a lot of games in the last transactions before stopping the hack. EOSPlay probably updated their smart contract at this point and made bets from the attacker’s account lose, or at least changed their dice resolve strategy to not use the block hash anymore. Good job on EOSPlay’s part for reacting so fast here. Had the attacker stopped on new setcode deployments on EOSPlays' side, the profit would have been 52,246 EOS.

Code updates

There are a total of 28 setcode actions on the mumachayinmm account. During the actual attacks, the contract was updated 11 times. Some of the contracts were used to attack different casinos. Here's a full list of the (attempted) attacks:

These are all casinos that just used the block hash to determine wins. (BetHash seems to use the SHA256(Sign(BlockHash)), not sure if it was vulnerable at that time.)

First actions

The incident on September 14th might not have been the first attack. The attacker started spamming already on August 18th. Maybe it was just to test the code.


This was definitely one of the more interesting hacks from a technical perspective compared to previous hacks of other casinos. If you’re a smart contract developer, you need to be really careful about how you implement randomness. After the hack EOSPlay moved to a more standard SHA256(ECDSA_SIGN(EOSPLAY_SECRET_KEY, BLOCK_ID of result block)) that EOSBet and others have been using successfully for years for now. This prevents the hack as the signature of EOSPlay on the block hash cannot be predicted, while still having provably-fair randomness.

The hack has also shown how important it is to have enough CPU to respond to attacks in the case of digested networks. There are many things a casino could do to prevent such attacks in the future, for example, pausing the contract if a statistical off-chain analysis is triggered or if X% of the bankroll was lost due to a single account.

If you’re a developer and you’d like to avoid doing the same mistakes as these developers, check out my book about EOSIO development.

Learn EOS Development Signup

Originally published at cmichel.io




Full Stack Software Engineer #javascript #EOS. Into Recreational Math / CS 🤯 Just message me about anything, my mind is open.

Love podcasts or audiobooks? Learn on the go with our new app.

Recommended from Medium

The First PoW-mineable Synthetic Assets on Harmony ($dkONE, $dkBTC)

Crypto Is Finally Decoupling From The Stock Market

5 Reasons Investing in Crypto is Accessible to More and More People

Crypto Myths, Busted

The World’s First Crypto Airport — A Test Case For Crypto Adoption


Get the Medium app

A button that says 'Download on the App Store', and if clicked it will lead you to the iOS App store
A button that says 'Get it on, Google Play', and if clicked it will lead you to the Google Play store
Christoph Michel

Christoph Michel

Full Stack Software Engineer #javascript #EOS. Into Recreational Math / CS 🤯 Just message me about anything, my mind is open.

More from Medium

Knownsec Blockchain Lab | Interesting Smart Contract Honeypot Analysis (PART 2)

Beosin Has Completed Security Audit Service of Crypto LEGO ALG: No critical, high or medium risk…

The Main Attack Methods Against Blockchain Cryptography Security