Ethereum Contracts Are Going to Be Candy for Hackers

Smart Contracts and Programming Defects

Ethereum promises that contracts will ‘live forever’ in the default case. And, in fact, unless the contract contains a suicide clause, they are not destroyable.

This is a double-edged sword. On the one hand, the default suicide mode for a contract is to return all funds embedded in the contract to the owner; it’s clearly unworkable to have a “zero trust” system in which the owner of a contract can at will claim all money.

So, it’s good to let people reason about the contract longevity. On the other hand, I have been reviewing some Ethereum contracts recently, and the code quality is somewhere between “optimistic as to required quality” and “terrible” for code that is supposed to run forever.

Dan Mayer cites research showing industry average bugs per 1000 lines of code at 15-50 and Microsoft released code at 0.5 per 1000, and 0(!) defects in 500,000 lines of code for NASA, with a very expensive and time consuming process.

Ethereum Smart Contract Bugs per Line of Code exceeds 100 per 1000

My review of Ethereum Smart Contracts available for inspection at shows a likely error rate of something like 100 per 1000, maybe higher.

Bug Definitions

I categorize bugs into three categories:

  1. Security flaws: loss of money or control possible for users or owners.
  2. Doesn’t do what it claims, either in the description or code comments.
  3. Wastes gas / is inefficient.

Before starting this quick review, I would have expected to see a fair amount of 3, and a bit of 2. I have been surprised to see some significant instances of 1, often combined with 2.

This raises a sort of rhetorical question for me; if contracts are immutable and permanent, and error rates do not approach zero, what are people signing up for?

I have a few suggestions in a later post.

A sample contract with some flaws

Ethstick is a kind of pyramid scheme which incentivizes participants (donkeys) to keep depositing money to get the payout (carrot). As each payment comes in, a “lucky donkey” is chosen for payout; the lucky one is chosen from a list of eligible donkeys.

Payouts vary between 1.1x and 1.2x, adjustable by the owner of the contract. (Termed the “pig” in the code). The pig/owner can sell the contract on and transfer it to a new owner, a common pattern for contracts intended to be micro-businesses.

You can review the code for contract 0xbA6284cA128d72B25f1353FadD06Aa145D9095Af at


A 10 minute check turns up a couple major issues. First, the random function relies only on the following numbers:

  1. A custom integer used as a random factor, hardcoded into the contract.
  2. The prior block’s hash.
  3. The length of the list of eligible donkeys

This random number is used to choose which of the donkeys is paid out. Ethereum blocks come about every 45 seconds; therefore, there is plenty of time for an attacker to calculate out if they would be the paid-out donkey and only trigger the contract with a payment if they are the recipient.

This qualifies as a severe bug to my mind. It is not mitigated by the contract’s popularity — more people playing increase your chances of being lucky — but when the contract is not used often, there is a guaranteed way to prod it and get paid out.

It’s not even easily mitigable using the block hash the transaction is mined in: an attacking miner or pool could only include good transactions in blocks that meet the calculation, otherwise leaving them out and not broadcasting them to the rest of the world.

That attack advantages a savvy consumer of the contract, the next one advantages the owner.

How Long is the List?

The function changeEligibleDonkeys allows the owner of the contract to shorten or lengthen the list of Donkeys. A simple attack by the owner would look like this:

  1. Add self to list of eligible donkeys, perhaps multiple times
  2. Shorten list if ‘whales’ are near the end of it

I’ve skipped a number of ‘efficiency’ related bugs, and I would not claim to have captured all the logic errors in this code; there is a section with a comment labeled //Ranking logic: mindfuck edition in case you would like to hunt down your own edge cases.

Counting whitespace and data declarations, there are 350 or so lines of code here. I’ve pulled out two large bugs, and there are at least five places with rounding issues or efficiency issues in the code. The actual logic in the code is less than 100 lines.

This is a troubling number of errors, and I have not cherry-picked a contract, in fact, this contract seems fairly functional right now compared to many. It will eventually become a cesspit for attack algorithms trying to beat each-other at the randomness game, which will be kind of fun to watch, I suppose, but it will not be doing the job it promises to do.

I would rate it in the middle of code quality that I’ve seen in the last few days. Some popular services, ones with 100s of thousands of dollars flowing through them, are distressingly bad (as in “everyone loses all their money” bad) with no way to mitigate, by design.


Some recommendations — first, I think that it is almost going to be a requirement for all but the simplest contracts that they have some sort of replacement mechanism baked in.

I have a few ideas about how this could work, and will write about them later, but one obvious point to make is that the replacement mechanism would need to be trusted by users of the contract.

Second, it’s probably worth including a ‘suicide’ mechanic for most contracts, and thinking upfront about what the fairest thing to do is. In the case of something like this, the owner of the contract could have easily included some sort of fair pro-rata payout of balances to the ‘donkeys’, paying herself nothing, and that would allow a simple way to close the contract without financial incentive to steal for the contract owner.

Third, smart contract auditing and insurance is going to be a thing.

Original URL:  

Original article

Updated Skimer Malware Infects ATMs Worldwide

An anonymous reader writes: Researchers at Kaspersky have discovered an improved version of Backdoor.Win32.Skimer infecting ATM machines worldwide. The new Skimer allows criminal access to card data, including PIN numbers, as well as to the actual cash located in the machine. The malicious installers use the packer Thermida to disguise the Skimer malware which is then installed on the ATM. If the ATM file system is FAT32, the malware drops the file netmgr.dll in the folder C:WindowsSystem32. If the ATM has an NTFS file system, netmgr.dll is placed in the executable file of the NTFS data stream, which makes detection and analysis of the malware more difficult. Skimer may lie dormant for months until it is activated with the phsyical use of a “magic card,” which gives access control to the malware, and then offers a list of options that are accessed by inputing a choice on the pin pad. The user can then request the ATM to: show installation details, dispense money, start collecting the details of inserted cards, print collected card details, self delete, enable debug mode, and update. Here’s a video of the Skimer malware in action.

Share on Google+

Read more of this story at Slashdot.

Original URL:  

Original article

Komodo X released – new version of Komodo IDE


Newsletter Sign Up


ActiveState Software Inc.
Suite 1700-409 Granville St.,
Vancouver, BC,
V6C 1T2, Canada

General Enquiries: 778.786.1100
Fax: 778.786.1133
Sales: 1.866.631.4581

© 2016 ActiveState Software Inc. All rights reserved. ActiveState®, Komodo®, ActivePerl®, ActivePython®, ActiveTcl® are registered trademarks of ActiveState. All other marks are property of their respective owners.

Privacy Policy |
License Terms

Original URL:  

Original article

X1 Instances for EC2 – Ready for Your Memory-Intensive Workloads

Many AWS customers are running memory-intensive big data, caching, and analytics workloads and have been asking us for EC2 instances with ever-increasing amounts of memory.

Last fall, I first told you about our plans for the new X1 instance type. Today, we are announcing availability of this instance type with the launch of the x1.32xlarge instance size. This instance has the following specifications:

  • Processor: 4 x Intel™ Xeon E7 8880 v3 (Haswell) running at 2.3 GHz – 64 cores / 128 vCPUs.
  • Memory: 1,952 GiB with Single Device Data Correction (SDDC+1).
  • Instance Storage: 2 x 1,920 GB SSD.
  • Network Bandwidth: 10 Gbps.
  • Dedicated EBS Bandwidth: 10 Gbps (EBS Optimized by default at no additional cost).

The Xeon E7 processor supports Turbo Boost 2.0 (up to 3.1 GHz), AVX 2.0AES-NI, and the very interesting (to me, anyway) TSX-NI instructions. AVX 2.0 (Advanced Vector Extensions) can improve performance on HPC, database, and video processing workloads; AES-NI improves the speed of applications that make use of AES encryption. The new TSX-NI instructions support something cool called transactional memory. The instructions allow highly concurrent, multithreaded applications to make very efficient use of shared memory by reducing the amount of low-level locking and unlocking that would otherwise be needed around each memory access.

If you are ready to start using the X1 instances in the US East (Northern Virginia), US West (Oregon), Europe (Ireland), Europe (Frankfurt), Asia Pacific (Tokyo), Asia Pacific (Singapore), or Asia Pacific (Sydney) Regions, please request access and we’ll get you going as soon as possible. We have plans to make the X1 instances available in other Regions and in other sizes before too long.

3-year Partial Upfront Reserved Instance Pricing starts at $3.970 per hour in the US East (Northern Virginia) Region; see the EC2 Pricing page for more information. You can purchase Reserved Instances and Dedicated Host Reservations today; Spot bidding is on the near-term roadmap.

Here are some screen shots of an x1.32xlarge in action. lscpu shows that there are 128 vCPUs spread across 4 sockets:

On bootup, the kernel reports on the total accessible memory:

The top command shows a huge number of running processes and lots of memory:

Ready for Enterprise-Scale SAP Workloads
The X1 instances have been certified by SAP for production workloads. They meet the performance bar for SAP OLAP and OLTP workloads backed by SAP HANA.

You can migrate your on-premises deployments to AWS and you can also start fresh. Either way, you can run S/4HANA, SAP’s next-generation Business Suite, as well as earlier versions.

Many AWS customers are currently running HANA in scale-out fashion across multiple R3 instances. Many of these workloads can now be run on a single X1 instance. This configuration will be simpler to set up and less expensive to run. As I mention below, our updated SAP HANA Quick Start will provide you with more information on your configuration options.

Here’s what SAP HANA Studio looks like when run on an X1 instance:

You have several interesting options when it comes to disaster recovery (DR) and high availability (HA) when you run your SAP HANA workloads on an X1 instance. For example:

  • Auto Recovery – Depending on your RPO (Recovery Point Objective) and RTO (Recovery Time Objective), you may be able to use a single instance in concert with EC2 Auto Recovery.
  • Hot Standby – You can run X1 instances in 2 Availability Zones and use HANA System Replication to keep the spare instance in sync.
  • Warm Standby / Manual Failover – You can run a primary X1 instance and a smaller secondary instance configured to persist only to permanent storage.  In the event that a failover is necessary, you stop the secondary instance, modify the instance type to X1, and reboot. This unique, AWS-powered option will give you quick recovery while keeping costs low.

We have updated our HANA Quick Start as part of today’s launch. You can get SAP HANA running in a new or existing VPC within an hour using a well-tested configuration:

The Quick Start will help you to configure the instance and the associated storage, install the requisite operating system packages, and to install SAP HANA.

We have also released a SAP HANA Migration Guide. It will help you to migrate your existing on-premises or AWS-based SAP HANA workloads to AWS.


Original URL:  

Original article

BitTorrent unveils new live-streaming platform

BitTorrent has been working on its proprietary live-streaming technology for years, but today unveiled its first dedicated app. BitTorrent Live is scheduled to launch on Apple TV this week, before coming to iOS and Android sometime in June. The app will feature free content from more than a dozen small-scale channels, with BitTorrent promising that additional content (including paid and premium tiers) will follow.

apple TV this week; iOS and android apps due in June

The initial launch channels aren’t big names by any means, but BitTorrent can at least say the app covers a broad range of content, including boxing and MMA (Fightbox), arthouse cinema (Filmbox Arthouse), live clubbing (Clubbing TV), and even one network “devoted to taking viewers on a journey of how wealth is achieved, used, and enjoyed” (AWE).

The important part of BitTorrent Live isn’t the content, though, it’s the technology. In the same way that torrents spread the data costs of large downloads among multiple users, BitTorrent’s live-streaming tech turns every viewer into a broadcaster. The company claims that this will solve the problem of lag on live broadcasts, allowing for large audiences to “to view live video with sub 10-second latency and without the need for an expensive CDN.” (That is, a content delivery network: a network of servers pushing out live content to viewers.)

The company cites an interview with Bob Bowman, an executive at, which touches on the difficulty of streaming live events to large numbers of viewers. “To do 10 million concurrent streams in the US? No one’s done it. No one’s come close. You’d have to buy up every CDN.” Bowman tells interviewer Walt Mossberg. “The most we’ve ever done in terms of concurrents is we’ve kissed two million concurrents [….] That’s two major CDNs, you know, really chugging. And you don’t have back up.”

Bowman suggests that new technology like 5G will help solve this issue, but building the necessary infrastructure for these networks will take years. BitTorrent thinks that changing the underlying protocols is the quicker solution. It also says that unlike with current CDN-based live streams, organizers don’t have to worry about scale.

BitTorrent claims its protocol is cheaper than current methods, with much less lag

“Current methods for online live broadcasting over the internet scale linearly with the size of the audience — that means that you have to pay more as additional viewers join your stream,” wrote the company in a blog post last year. “Peer to peer online streaming returns to the model of traditional TV, where there is no incremental cost for growth in audience size.”

But BitTorrent could have the perfect technological solution for live broadcasting and still find no traction. The company’s app is unlikely to attract much interest as it currently stands, and unlike torrent technology for downloads (which became popular primarily as a way to share pirated content) BitTorrent Live will have to attract the interest of major broadcasters to prove its utility. Still, if the technology is as cheap and practical as BitTorrent suggests, it could yet find a place underpinning live streams of the future.

Original URL:  

Original article

Android N hits beta, boasts VR and more

Google’s been hard at work under the hood of its Android operating system, announcing performance, security and productivity updates in the new Android N alongside a swanky new suite of VR capabilities called Daydream and version 2.0 of Android Wear.

Android N is available for select devices in beta today and will be released in a stable version this fall. It’s been publicly available as an open alpha for developer use for some time, but Google’s presentation offers the company’s definitive vision for the future of the Android platform.

Oh, and about the name – Google’s taking suggestions from the public, and you can submit yours here. (Necco wafers. Just saying.) Other than that, here are the highlights.

To read this article in full or to leave a comment, please click here

Original URL:  

Original article

Proudly powered by WordPress | Theme: Baskerville 2 by Anders Noren.

Up ↑

%d bloggers like this: