由于一些场景比如转账后做某些操作，需要利用memo 传递多个参数信息
一般会以各种分隔符，如‘-’，‘|’，‘#’，空格等,所以需要个简单的方法格式化下

#ifndef __UTILS_HPP__
#define __UTILS_HPP__

#include <string>
#include <vector>

using namespace std;

void split(const string& s, char c,
           vector<string>& v) {
   string::size_type i = 0;
   string::size_type j = s.find(c);

   while (j != string::npos) {
      v.push_back(s.substr(i, j-i));
      i = ++j;
      j = s.find(c, j);

      if (j == string::npos)
         v.push_back(s.substr(i, s.length()));
   }
} 
#endif

比如memo 格式为“id:value”
测试代码如下

//去掉memo前面的空格
memo.erase(memo.begin(), find_if(memo.begin(), memo.end(), [](int ch) {
        return !isspace(ch);
}));
    //去掉memo后面的空格
memo.erase(find_if(memo.rbegin(), memo.rend(), [](int ch) {
        return !isspace(ch);
}).base(), memo.end());

vector<string> v;
split(memo, ':', v);
eosio_assert(v.size() == 2, "size need 2");
uint32_t id = std::strtoul(v[0].c_str(), NULL, 10);
uint64_t value = std::strtoull(v[1].c_str(), NULL, 10);

复制源代码

从eosio.contracts 项目中，复制eosio.contracts/eosio.system/src/exchange_state.cpp，eosio.contracts/eosio.system/include/eosio.system/exchange_state.hpp两个文件到你合约项目中。
并在你的合约中include

#include "common/exchange_state.hpp"
#include "common/exchange_state.cpp"

计算代码

uint64_t bcskill_contract::exchange_ram(eosio::asset quantity){
    rammarket market(k_eosio, k_eosio.value);
    auto it = market.find(k_ramcore_sym.raw());
    eosio_assert(it != market.end(), "125");
    auto tmp = *it;

    /* Convert EOS amount to ram bytes */
    auto out_ram_bytes = tmp.convert(quantity, k_ram_sym);
    return out_ram_bytes.amount;
}

你没看错，我今天要回顾的是DApp的各种攻击方式，其实这个主题已经有好多人写了，且都还不错，只是最近正好有大佬要深入了解，因而作者尝试从技术角度来解读这些攻击方法。

菠菜游戏运行机制

菠菜游戏都是钱袋子，所以目前的DApp攻击基本都是针对菠菜游戏，有钱的美女人人都爱很正常。
要理解攻击方法，就必须先了解DApp的工作方法。我们知道，菠菜游戏都离不开筹码(EOS)，因而将筹码转账给DApp是核心一环。不像以太坊调用智能合约函数的同时通过value字段直接给智能合约转账ETH，EOS下给智能合约转账EOS就相对复杂一点。可以通过如下两种方式实现：

1. 用户授权eosio.code权限给DApp, DApp执行eosio.token合约的transfer函数实现用户给智能合约转账EOS。

该方法用户敞开的风险太大，因为一旦将eosio.code权限授予给DApp, DApp就完全控制了用户账号的，其中就包括用户的EOS资产，DApp可以任意转出EOS。

2. 用户直接调用eosio.token的transfer函数给DApp账号转账EOS

由于eosio.token合约的transfer合约有require_receipt逻辑，require_receipt(to)会调用to(DApp合约地址)的transfer函数然后DApp就可以执行自己的代码。

由于第一种方法缺陷明显，目前菠菜DApp都采用第二种方法，具体流程如下：

函数调用流程：

 eosio.token::transfer(from, dapp, memo)
            ->dapp::apply(receiver, code, action, ...)
                   ->dapp::transfer(from, dapp, memo)
                              ->…

可见用户的一个transfer动作，其实大概经历了5个阶段，这5个阶段都可能出bug进而导致被攻击。接下来就从这个几个流程来分析下各种攻击方法。

eosio.token::transfer阶段

该阶段处于系统智能合约eosio.token的逻辑，肯定是没有bug的， 就算有bug，也是DApp没有用好，所以该阶段无漏洞。

apply阶段攻击(假EOS攻击)

“假EOS”攻击出现于EOSBet平台上 ,后又扩散到NewDex交易所。
该攻击的核心是恶意合约完全模拟eosio.token合约，并发行假“EOS”代币。然后给DApp转假的"EOS“代币，和eosio.token逻辑一样，恶意合约会通过require_receipt(dapp)进入dapp的apply, 再调用transfer函数，由于transfer函数里已没有receipt调用者信息，只能识别代币的名字是否“EOS”，而这个检测很明显可以通过，进而实现了用“假EOS”玩DApp目的。具体如下流程如下：

evilcontract::transfer(from, dapp, memo)
            ->dapp::apply(receiver, code, action, ...)
                   ->dapp::transfer(from, dapp, memo)
                              ->...

解决方案是Apply函数里增加来源检测，具体如下：

transfer阶段攻击(假EOS转账通知攻击)

假EOS应该算是开启了DApp攻击热潮，很快EosBet遭受了第二波攻击，即"假EOS转账通知攻击", 那这个又是怎么回事呢？
有了“假EOS“攻击的经验，DApp们都加强了防备，都在Apply添加了检测，这道锁是严实了。于是黑客们盯上了下一步transfer函数，于是”假EOS转账通知攻击"产生了。
“假EOS转账通知攻击”攻击是指攻击者通过eosio.token给自己的智能合约账号(evilcontract)转真EOS， eosio.token合约会通过require_receipt代码调用恶意智能合约transfer函数。但是恶意合约会通过require_receipt主动调用dapp, 导致dapp的transfer函数被调用。由于最开始调用的确实是eosio.token合约，导致code是eosio.token, 从而合法通过了上述Apply中的"eosio.token"检测逻辑进而顺利进入dapp的transfer函数。

eosio.token::transfer(from, evil, memo)
            ->evilcontract::apply(receiver, code, action, ...)
                   ->evilcontract::transfer(from, evil, memo)
                              ->dapp::apply
                                        ->dapp::transfer(from, evil, memo)

从上面可以看出，该攻击是完美避过Apply检测逻辑，但是还是会留下蛛丝马迹，这个就是transfer的参数to是‘evil'而不是dapp,因而在transfer函数里添加to是否为本合约检测逻辑即可防御攻击，具体如下：

详情请查考【Eosbet再遭攻击，亟待官方的权威开发指南】

receipt和reveal阶段攻击(随机数攻击)

receipt和reveal才算进入DApp的核心逻辑，这部分核心逻辑就是负责收集处理随机数和开奖。因而这两个阶段的攻击其实就是攻击随机数，即预测结果或者产生有利结果的随机数。
目前传统App使用的随机数也是伪随机数，存在被攻击的可能，但是概率极低。而目前区块链里的随机数攻击是指那些能稳定预测结果或者影响结果的攻击，其实不属于伪随机数的问题，而是编程逻辑的问题。
目前主流菠菜DApp基本都采用了 tapos_block_prefix, tapos_block_num 做为随机数种子。这两个参数都跟ref_block_num有关。

tapos_block_num = ref_block_num & 0xffff
tapos_block_prefix = getBlock(ref_block_num).ref_block_prefix

那ref_block_num这个值如何得到的呢？
它是我们调用cleos或者eosjs发起交易时指定的，如果不指定，则为last_irreversible_block_id

到这里，你知道这个变量的用处了吧，该参数可以减少分叉影响。因为大部分交易都是将ref_block_num指定为last_irreversible_block_id，那些不包含last_irreversible_block_id的分叉自然交易量少，所以哪怕系统出现分叉，但是由于交易量少，影响也不会很大。
好了，回到随机数，既然这个ref_block_num客户端即用户可以指定，那就存在可控性，攻击者就可以选择ref_block_num，进而提前计算出随机数。所以这种使用历史数据的随机数不能算做随机数，自然不可能成为主流DApp的随机数。
事实上，从一开始大部分DApp就是通过defer action的方式延迟开奖，defer action里的ref_block_num是下注区块(block1)的信息，该区块信息在下注时是未知信息，即实现了使用未来数据作为随机数。具体逻辑如下：

到此，DApp其实已经算相对安全了，已经能够称得上伪随机数了，接下来的攻击理论上基本都是属于概率攻击，即猜测或者影响下注区块信息，这个属于概率学上的攻击，不在此篇攻击分析范围。但事与愿违，DApp开发者们为了出奇制胜创新完美，自己想了不少额外的方法，进而就被攻击，比如如下几个攻击。

Eosbet第一次随机数攻击(使用已知数据作为随机数)

尽管延迟兑奖，但是还是使用老的ref_block_num，即不使用block1而是将block0作为ref_block,进而导致随机数被预知。

Eosbet第二次随机数攻击(碰撞账号余额)

有了第一次攻击经验，Eosbet学好了，采用下注block作为ref_block，但是鬼使神差的将玩家的余额作为随机数。这个想法的出发点估计是随机数输入越多越好越随机，殊不知却掉坑了。开发者没想到余额不像其他随机数数种子，他的值是可以变化的。攻击者完全模拟dapp的代码，
也使用延迟action，只不过会不停修改balance然后尝试开奖逻辑，直到碰撞到中奖结果。

同时受该攻击的还有EosDice。

同步开奖攻击(回滚攻击)

所有同步开奖的DApp都会遭遇回滚攻击。比如Dice3D和LucyGo
回滚攻击的思路是恶意合约在dapp的action之后插入一个盈利检测action, 该action在reveal action之后执行，自然可以通过检测合约的余额来判断是否盈利。如果不盈利则触发assert从而导致整个交易回滚，最开始的转账action也作废即筹码回滚，攻击者不损失任何EOS，从而达到稳赢的结果。具体流程如下：

该攻击方法的核心代码是合约中获取账号余额，最简单的方法就是直接访问eosio.token的accounts数据库，但是要获取里面的balance余额，就必须保持一模一样的数据结构，因而拷贝eosio.token.hpp文件到该合约目录是最简单的方法。
详情请查考【EOS游戏合约遭受回滚攻击】

总结

留意receipt来源，必须延迟开奖，不要引入其他可控的随机数因子

转载自：https://mp.weixin.qq.com/s/FSJzAQt6W5KQX1UZRBqUYA