您正在查看: Surou 发布的文章

EOS transfer memo 格式化

由于一些场景比如转账后做某些操作,需要利用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);

合约内计算EOS换算RAM

复制源代码

eosio.contracts 项目中,复制eosio.contracts/eosio.system/src/exchange_state.cppeosio.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;
}

一张图演绎EOS DApp各种攻击方法

你没看错,我今天要回顾的是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

智能合约之 eosio.cdt 我们需要知道的那些事

eosio.cdt 在 1.2.x 和 1.3.x 的改动比较大, 虽然虚拟机是向后兼容的, 但是为了避免意外情况, 我们都会将陆续将合约代码升级。下面来介绍一下大致的改动

# 安装 eosio.cdt, 因为 llvm 库比较大, 所以执行 clone 的时候比较慢
$ git clone https://github.com/EOSIO/eosio.cdt.git
$ git submodule update --init --recursive
$ ./build.sh
$ sudo ./install.sh

1.2.x 和 1.3.x 的区别

eoslib C API

uint64_t 别名 account_name, permission_name, scope_name, table_name, action_name 全部移除, 新增 typedef capi_name uint64_t
symbol_name 别名移除,用 symbol_code 代替
移除 time , weight_type typedefs
移除 transaction_id_type, block_id_type typedefs
checksum160 -> capi_checksum160, checksum256 -> capi_checksum256, checksum512 -> capi_checksum512, public_key -> capi_public_key, signature -> capi_signature
移除掉未实现的 api : require_write_lock 和 require_read_lock

eoslib C++ API

移除 bytes typedefs
移除文件 eosiolib/types.hpp
移除文件 eosiolib/optional.hpp, 用 std::optional 代替
移除 eosiolib/core_symbol.hpp 文件, 以后合约需要自行声明 core_symbol
增加文件 eosiolib/name.hpp

eoslib/types.hpp

将 typedef eosio::extensions_types 移到 eosiolib/transaction.hpp
移除掉对 checksum struct 的 == 和 != 的重载
移除掉 API eosio::char_to_symbol, eosio::string_to_name, eosio::name_suffix, 都整合进了 name struct
移除掉宏命令 N(X), 重载运算符 ""_n ,例如 "foo"_n 或者 name("foo") 来转换成 name struct 类型
将 eosio::name struct 的定义 和 ""_n 运算符 移至 eosiolib/name.hpp
ps: 读者可以使用 #define N(X) name(#X) 来减少代码的改动了哈。

eosiolib/name.hpp

移除name 显式 隐式转换成 uint64_t
添加 enum class eosio::name::raw : uint64_t 用于从 name struct 隐式转换成 raw
添加 bool 类型转换,会返回 name struct 转化成 uint64_t 是否为 0
构造函数都用 constexpr, 确保 name struct 实例化时,都会给 value 赋初值
添加新的 constexpr 方法 eosio::name::length, eosio::name::suffix
添加 name struct 的比较函数

eosiolib/symbol.hpp

移除 eosio::symbol_type strcut , 用 eosio::symbol class 代替
添加 eosio::symbol_code struct
移除掉 eosio::string_to_symbol, eosio::is_valid_symbol, eosio::symbol_name_length 方法,都整合进了 symbol_code struct
移除宏命令#define S(P,X) ::eosio::string_to_symbol(P,#X), 直接实例化 symbol class eg: symbol(symbol_code("SYS"), 4) or symbol("SYS", 4)
重构 eosio::extended_symbol struct

eosiolib/asset.hpp

构造器现需要显式传入 quantity 和 symbol, 不再有默认值

eosiolib/contract.hpp

Rename EOSIO_ABO to EOSIO_DISPATCH, 更加明确的表达该宏指令的作用
根据 contract 的改动重构 EOSIO_DISPATCH

eosiolib/multi_index.hpp

索引不能直接用 name struct 需要使用 eosio::name::raw
multi_index code 不再使用 uint64_t, 使用 eosio::name

eosiolib/singleton.hpp

同 multi_index, 用 eosio::name 替代 uint64_t

eosiolib/action.hpp

添加 inline function: eosio::require_auth, eosio::has_auth, eosio::is_account
重构 eosio::permission_level, 用 eosio::name 替换 uint64_t
移除 宏命令 ACTION,整合到了 eosio.hpp
新增 action_wrapper struct, 它的出现,让我们对inline action 的使用更加便利化,相当于把 inline action 封装成一个 struct,直接实例化便可以发送一个 inline action, 下面会写例子。

eosiolib/permission.hpp

修改 eosio::check_transaction_authorization 参数类型 std::set to std::set , 使得能和 eosio 的 public_key 兼容。
eosio::check_permission_authorization 参数 account, permission 类型从 uint64_t 修改成 eosio::name

eosiolib/ignore.hpp

新增 ignore struct, 会让ABI 生成对应的类型, 但datastream 不会去序列化它
新增 ignore_wrapper, 方便其他合约调用声明的 action。

下面我们挑些改动比较大的地方来说下。

1.移除 uint64_t 的多数别名,只留下了一个 capi_name。

其中最大的地方当属 去掉了 uint64_t 的别名,需要用 name struct 来代替, 不应该用新的别名 capi_name。 不说了,笔者改代码改到想哭了。但为什么要做这个改动呢, 目前对于 account_name 等所使用的都是 implicit, 这意味着可能有一些 bad implicit。
Eg:

//@abi action
void hi(){
  name acc = name{10};
  print(acc==10);
}

我本意是要判断 两个 name struct 是否相等, 但是隐式转换使我直接比较整数 10 也能返回 true。
所以重构了 name struct,消除了这种风险。
这次的改动也变得比较偏面向对象思维, 像 eosio::char_to_symbol, eosio::string_to_name, eosio::name_suffix 都被整合进了 name struct 里面。
symbol 和 symbol_code 也被重构了。宏命令 S 被移除,不能直接用 S(4, SYS) 去声明一个 token symbol, 要用 symbol(symbol_code("SYS"), 4) or symbol("SYS", 4)去实例化一个symbol 对象, 也将一些针对 symbol 的函数整合进了 class。

2.重构了contract.hpp , EOSIO_ABI 修改成 EOSIO_DISPATCH

contract( name receiver, name code, datastream<const char*> ds ):_self(receiver),_code(code),_ds(ds) {}

构造函数增加 code 和 ds 参数。增加 ds 参数是为了方便我们手动解析数据。 这跟后面要说到的 ignore struct 有比较大的关系。
这种改动也意味着我们重写 apply 的方式要改动.
Eg:


extern "C" {
  void apply( uint64_t receiver, uint64_t code, uint64_t action ) {
    auto self = receiver;
    // 拦截 失败的 deferred_trx
    if( code == "eosio"_n.value && action == "onerror"_n.value ) {
      const auto act_data = unpack_action_data<onerror>();
      auto sender = uint64_t( act_data.sender_id >> 64);
      if( sender == self){
        test bos(eosio::name(receiver), eosio::name(code),datastream<const char*>(nullptr, 0));
        bos.resend( act_data.unpack_sent_trx(), uint64_t( act_data.sender_id) );
      }
    // 拦截 eosio.token 的 EOS 转账操作
    } else if ( code == "eosio.token"_n.value ){
      test bos(eosio::name(receiver), eosio::name(code),datastream<const char*>(nullptr, 0));
      const auto t = unpack_action_data<transfer_args>();
      if(t.from.value != self && t.to.value == self){
        bos._transfer(t.from, t.to, t.quantity, t.memo);   
      }
    }else if ( code == self || action == "onerror"_n.value ) {
      switch( action ) {
        EOSIO_DISPATCH_HELPER( test, (hi))
      }
    }
  }
}

3. ignore struct , ignore_wrapper 和 action_wrapper 的使用

在 action 的参数加上 ignore struct, 会告诉虚拟机,不要解析此数据, 让自己手动解析。
使用 action_wrapper 把 hello:hi action 包装起来。
使用inline action 时,用 ignore_wrapper 表明该参数是一个 ignore 类型。
Eg:

#include <eosiolib/eosio.hpp>
#include<eosiolib/ignore.hpp>
using namespace eosio;

CONTRACT hello : public eosio::contract {
 public:
   using contract::contract;

   ACTION hi( name user, ignore<uint64_t>, ignore<std::string>) {
     print_f( "Hello % from hello", user );

     // 读取 ignore 数据。
     uint64_t test;
     _ds >> test;
     printui(test);
     std::string str;
     _ds >> str;
     prints_l(str.c_str(),str.size());
   }

   // 用 action_wrapper , 把 hello::hi action 包装起来
   using hi_action = action_wrapper<"hi"_n, &hello::hi>;

   ACTION inlineaction( name user, name inlinecode ){
     print_f( "Hello % from send_inline", user );
     // constructor takes two arguments (the code the contract is deployed on and the set of permissions)
     // 实例化 hi_action, 并进行调用。
     // inlinecode 参数及对应的 hi action 的合约账号。
     hello::hi_action hi(inlinecode, {_self, "active"_n});
     hi.send(user,ignore_wrapper(22),ignore_wrapper("asdfa"));
   }

};
EOSIO_DISPATCH( hello, (hi)(inlineaction) )

结论:两个版本的主要改动是消除隐式转换的风险。 也重构了一些模块的代码, 变得更加直观。 新增了 action_wrapper struct, 使得 inline action 的使用更加方便快捷。

转载自 https://segmentfault.com/a/1190000017092129#articleHeader15

如何为EOS DAPP开发设置VS CODE和CLION

每个开发人员都需要一个良好的IDE,它是为他的项目的开发过程而设置的。这就是为什么我们创建了一个关于如何为EOS dApp开发设置VS Code和/或CLion的快速教程 。
我们还为VS Code创建了一些脚本,它们将自动执行您在终端中使用的一些命令。

Visual Studio代码设置

首先,如果您还没有安装一些VS代码扩展,请安装它们。通过dApp开发,它们将非常有用:

  • C / C ++ - VS Code的IntelliSense,调试和代码浏览
  • CMake - 对Visual Studio Code的CMake语言支持
  • CMake工具 - Visual Studio Code中的扩展CMake支持
  • WebAssembly - WebAssembly文本表示的语法高亮显示

当我们开发EOSIO dApp时,我们在.hpp和.cpp文件中编写代码。但是,这只是整个过程的一小部分。大多数情况下,我们需要生成一些其他文件,我们将使用这些文件在区块链上部署合同,对其进行单元测试等。这就是 CMake派上用场的地方。

CMake是一个用于控制软件编译过程的命令行工具。一旦在IDE中正确设置,它就会变得非常容易。
现在我们将使用CMake工具,我们应该对项目结构进行一些更改。我们将重用EOSIO项目的骨架,因为它拥有我们需要的一切。当然,我们做了一些小改动。

我们有一张图片显示了新的项目结构。让我们来看看。

首先,我们有build文件夹。这是放置所有构建内容的地方。您将使用的每个生成的文件都在那里。接下来是CMakeModules,其中包含一些有用的cmake模块,其中包含用于编译过程的自定义函数。

该合同是我们的核心文件夹中。这是我们准备智能合约的地方。目前,eosiolib,libc ++和musl默认存在,因为它们用于编译。行中的下一行是外部和库。这两个文件夹都包含用于使整个编译过程更容易的库。

项目结构中最后一个重要的事情是配置文件 - CMakeLists.txt。每个目录都有自己的带有命令的CMakeLists.txt文件。

你可以找到我们的回购里面的所有文件夹和脚本的新项目结构在这里

CMakeLists

让我们看看一些配置文件,因为您需要知道如何使用它们。

1.CMakeLists.txt(4)

这是设置编译过程的主要配置文件。您应该知道,在开发dApp时,需要设置项目名称。版本和语言是可选的。

2. CMakeLists.txt(3)

第二个配置文件位于contracts文件夹中。应将每个新的智能合约添加为此配置中的子目录。因为合同不会编译,所以不要忘记这一步很重要。CMake不会知道。

3. CMakeLists.txt(2)

每个智能合约都有自己的配置文件。在这里你需要注意每个合约有不同的目标,基本上,它是文件夹的名称。

现在,当我们拥有新的项目结构时,我们必须制作自定义命令,这些命令将编译和构建我们所做的一切。但是怎么样?幸运的是,VS Code有一些很酷的东西叫做 Tasks。它帮助我们只需点击几下即可自动执行每个命令。

VS代码中的任务

首先,我们必须生成将包含我们的自定义命令的tasks.json文件。按⇧+⌘+ P在VS Code中打开命令选项板,然后键入“ 任务 ”并选择“ 配置任务 ”。

下一步选择“从模板创建tasks.json文件”,然后选择“其他”

VS Code将创建一个名为“ .vscode ” 的文件夹,在其中,您可以找到tasks.json。现在我们需要添加命令。将以下代码复制并粘贴到tasks.json中:

我们创建了三个名为CMake, Build和Generate ABI的自定义命令。它们执行三个shell脚本 - compile.sh,build.sh和generate.sh。前两个脚本基本上做同样的事情,除了build.sh同时编译和构建。可能大多数时候你会使用第二个。

另一方面,第三个脚本 - generate.sh(Generate ABI)用于生成智能合约的abi。在构建期间需要生成一些文件。您必须在合同所在的文件夹中执行该命令。选择例如.cpp文件并运行它。

真棒!我们几乎准备好了VS代码设置。为了使整个过程变得更加容易,我们将为命令创建快捷方式。当你还在VS Code中时,请转到首选项 - 键盘快捷键。将打开一个快捷方式窗口 - 找到并打开keybindings.json(它位于顶部):

一旦打开keybindings.json,我们将创建我们的快捷方式。对于我们的命令,我们选择了“ cmd + e ”,“ cmd + r ”和“ cmd + i ”,但您可以选择其他命令。这是你必须添加的json:

完成所有操作后,您就可以开始在VS Code上开发EOS dApp

CLION设置

与VS Code相比,设置CLion非常简单。在CLion中加载框架时,IDE会自动在cmake-build-debug文件夹中创建所有构建文件。准备就绪后,您可以使用⌘+ F9快捷键执行实际构建。这就是你应该做的一切,太容易了吗?

但是,如果要为CMake设置其他设置,可以从首选项 - 构建,执行,部署中执行此操作:

有关在CLion中配置CMake的更多信息,请参阅IDE 的官方文档。真的很棒!

准备开始开发EOS dApps了吗?检查我们的教程
1.第一步在EOS Blockchain发展
2.最终的端到端EOS dApp开发教程 - 第1部分

英文原文:https://infinitexlabs.com/setup-ide-for-eos-development/