相信各位朋友对代币领域的“增发”这个概念已经不会陌生，比如泰达近期便在以太坊上频繁增发ERC20标准的USDT，由于这是一种增加代币流通量的行为，所以一直充满争议。当然，通常情况下，代币的增发行为是公开的，有据可查，所以我们还可以及时反应，甚至与相关项目方干涉沟通，但是如果这种“增发”是毫无记录的，甚至连项目方都不知道的呢？你可能会感到奇怪，竟然会有这样的咄咄怪事？是的，近期北京链安就发现了在合约中设置后门，暗地增发Token并窃取的恶劣行为。近日，北京链安接到部分项目方反映，他们发布ERC20代币后，还没进一步向其它地址分发，就发现一些来源不明的代币在链上转账，即这些代币原始来源并非其合约创建时分配给官方地址的Token。同时，项目方也发现这些Token并非同名创建的其它合约产生的同名币或“假币”，更像是一种并非由其发起的“增发”。例如，一项目方便反映，他们观察到以太坊链上其代币HJL交易出现异常增发的情况，一些Token似乎在以太坊网络上凭空产生，没有生成记录，说好的区块链“不可篡改可追溯”呢？
但是，据举报问题的项目方反映，它们并未向0xfa6dd2b9976d67852cc4b3180f1ef8692c4ad87c转账，这个地址似乎有Token“从天而降”。
可以看到，上图记录中，合约创建后产生了4300万枚HJL，转账到0xfee0c开头地址，接着该地址转入0x2ebecf开头地址，接着我们看到了0xfa6dd2开头地址的转账，显然这个地址此前并未获得官方创建的相关Token。于是，我们进一步查看了该Token的合约：https://cn.etherscan.com/address/
终于，我们发现了玄机所在，智能合约在部署到链上时，在正常发布参数_totalSupply设置供应量的Token的同时，还向地址0xfA6DD2B9976d67852Cc4b3180f1Ef8692c4aD87c的账户上充值了总供应量1%的代币，并且这1%的代币并未计入总供应量中，就HJL而言，相当于实际发行了43000000+43000000*1%=43000000+430000=43430000HJL，而多出来的这些HJL似乎被这个地址给“偷”走了。
从地址0xfa6dd2b9976d67852cc4b3180f1ef8692c4ad87c关于HJL的转账来看，它确实给人一种凭空获得HJL的感觉，并转出了330000HJL。
该地址内还剩下10万枚HJL，和转出的HJL加起来总额为43万HJL，符合合约中的操作。我们进一步参看了该地址的转账记录，发现有不止一个此类“天降横财”式Token，都是未见转入和合约调用，该地址直接向外转出这些Token
这些项目的合约是不是也遇到类似问题呢？我们查询了PhantomMatter(PHTM2)的合约：https://cn.etherscan.com/address/
不出意外的，我们看到了同样的代码，同样的地址，同样的百分之一增发式“偷取”策略，由此可见这实际上是相关合约留有后门，但是项目方表示并不知情，那么他们又是如何中招的呢。与项目方的沟通进一步了解到，其发币合约并非自己开发，而是在一个名为“易代币”的发币平台完成，接下来的问题就是在使用这个平台的过程中：平台的模板是否带有这样的代码。如果带有这样的代码，是否这本是其功能设置的一部分，或者是客户支付费用的既定方式。如果有这样的功能和设置，是否明示给客户。
于是，我们在测试网上进行了测试，在网站上，用户首先选择发币类型。
接着输入名称、符号、供应量等信息。
最后是支付相应的创建交易费用，然后确认就可以了，全程没有任何地方提及会有最终合约代码中产生的多发1%代币并转到其指定地址的行为，显然这并不是一个其既有的面向客户的功能或者设置。北京链安已经在测试网络使用了该代币生成网站并部署合约，从合约代码来看，也看到了同样的多发Token并窃取的行为，接收地址也是0xfa6dd2b9976d67852cc4b3180f1ef8692c4ad87c。由此可见，该网站以代币发布平台为名，在为客户提供代币发布服务的同时，在客户不知情的情况下获得代币，一旦相关代币可以交易流通，他们将可以将其卖出获益。就0xfa6dd2b9976d67852cc4b3180f1ef8692c4ad87c地址关联的项目而言，主要有：HJL(HJL)Moneyhome(MH)PhantomMatter(PHTM2)CRS(CRS)LibraPi(LP)SMART(SMART)UCC(UC)其中部分Token已经在交易所交易，我们也看到了涉事地址向相关交易所转账的记录，可见其模式便是暗中多发1%的Token，待其中有币上所便跟进卖出获利。整个过程，我们发现项目方处于一种极不安全的“裸奔”状态，在使用所谓的发币平台的时候，整个过程对它们是黑盒的，它们看到的只是些设置选项，根本不知道中间的猫腻。与此同时，尽管代码部署并开验证后会开源，但是使用这样的平台的项目方通常技术能力有限，不会去检查其中的缺陷，而目前很多中小交易所上币的时候也不会对项目方做代码审计要求，这就造成这一代码里如此“张扬”的后门通过层层关卡而未被及时堵截。在这里，北京链安提醒业内各方，对于涉及智能合约的开发请遵循相应的安全原则，如涉及外包开发请在对其能力评估的同时注意道德风险的评估。最后，智能合约的安全审计环节必不可少，请及时联系专业的安全机构进行相应的安全检测。
郑重声明： 本文版权归原作者所有， 转载文章仅为传播更多信息之目的， 如作者信息标记有误， 请第一时间联系我们修改或删除， 多谢。