Project Logs

Collapse logs

• New test smart contract

  Dylan Brophy • 07/27/2019 at 15:43 • 0 comments

  I've made a new test contract on the Ropsten testnet.

  You can see it and interact with it here:

  https://ropsten.etherscan.io/address/0x32adc9f58db202a67d92f2367b1903d8ef2c79f3

  Yeet! :)

• Adding The Obvious

  Dylan Brophy • 07/14/2019 at 06:37 • 0 comments

  Why didn't I add buying and selling functionality yet?  Isn't this an obvious step?

  When I first started working on this, that sounded really daunting and complex, not because of programming, but for the legal and security implications.  How can it be integrated into the existing legal system?  What if someone places a sell for a house they do not own?

  I'm not a lawyer.  Nor a realtor.  I'm an engineer, and a programmer.  I'm not going to concern myself with these issues much yet, and instead focus on creating a more useful and capable smart contract.

  So, I came up with this process:

  1. Seller asks to place an offer, providing proof of ownership and any other required legal documents, specifying an offered escrow time

  2. An entry is placed on the blockchain by the smart contract's database owner after a proper inspection is passed

  3. Buyer accepts offer, signs documents electronically, and pays.

  4. When escrow is over, the smart contract allows the seller to claim the HOM Coin paid in the contract

   * The buyer may cancel before escrow is over as well, in which case the payment is refunded.

  I'm sure there are plenty of things I may have left out, or things that could be better, but I am still working on this aspect.  I would say that this is a step up from not being able to buy houses with this contract at all.

  You'll notice that realtors are not included.  I don't really think they are necessary.  If you want to contact the seller to make a counter offer, the smart contract contains contact information, and the seller can cancel the offer and request an updated one.  All houses would need to be inspected before being put on this market.

  I plan on asking my colleague, who is a licensed realtor, more about this.  I'm working with him on this project.

• Hacked Test Contracts!!!! (Interesting Story)

  Dylan Brophy • 07/01/2019 at 01:15 • 0 comments

  Someone (or multiple people) have been exploiting bugs in my test contracts!

  I actually think it's pretty funny, I already fixed these bugs but the old contracts do not reflect the fixes.  I have no idea who did this.

  So what did they do?

  The bug lies in this piece of code here:

  // BUGGED CODE DO NOT USE
  function setOracleAddress(address payable adr) public {
  	oracle_adr = adr;
  }

   The bug has been fixed for a while now, but the contracts on the blockchain have this old function.  It does not check to see if the sender of the transaction is indeed the owner, so anyone can change the oracle address.

  The oracle controls the price, so anyone can now change the price and receive the fees.  If they can change the price, they can buy coins at zero and sell them at any price they want (essentially allows stealing from the contract)

  Lets follow what they did on the contract 0x1574ea34e90db0618c343e6e64a31e03c40383c9
  

  This is a contract actually on mainnet, so it had real Ethereum in it to be stolen.

  At transaction 0x5a606944e75c9c45cfc83810980f94035beb8005887e00b3063d16705906640c, the ethereum account 0xcd7038aff3cd202afc998f655575510424170862 changed the oracle address of my smart contract to 0x43ee0c8e212a3d21c6924159ae7b834e9105d27e.

  In essence, this is the attacker taking the Oracle address.

  The attacker then changed the price of the token to zero (transaction 0x22d03975e23348e62612fd54733c0f5d01110423115cdb5f17c99e8eef95d182)

  Then, this person bought 10% of the tokens for zero ethereum, essentially stealing the tokens. (0x8a2eb797567cbbc79467ad73e3f800c368fda60b8164d34c7dd618bcdb52493b)

  It gets better:  the attacker can now steal real ethereum by increasing the price manually.

  Our attacker chose to set the price at 1 Ethereum = 1 HOM Coin (0x379b936ac73ced7155b9643a3de3c05ad71f5f957222b65338b4d1df8290bca1)

  And, the last step:  sell some stolen tokens.  Since the price was set to one, selling the same amount of tokens as the balance of the smart contract will steal the entire smart contract balance.  That's exactly what happened at transaction 0x5534a39ad4ce457ce7b16d76e3f5fefbeb0c58bddf87b3ed25ea8a4bea84dc97.

  Whoever this was, he/she was nice enough to send me back all the stolen Ether, but they still have 10% of the tokens. :P   See the token holder pie chart here, with our attacker having that 10%.

  What contracts did they hack?  Here are the one's I've found that are exploited:

  https://etherscan.io/address/0x1574ea34e90db0618c343e6e64a31e03c40383c9

  https://ropsten.etherscan.io/address/0x9e405115f9992be0d0bff2ccc81eb647dabb74e4

  I don't think there are any others, but I can't really be sure.  I don't even know if these contracts were hacked by the same person (although they probably were).
  

  This was actually really exciting for me because I've never had anyone actually interact with my projects, especially not in a way like this.  It's like someone just walked up and had a conversation with something I built.  Granted, they manipulated the project, but still;  It's really cool!

• Separation of Powers

  Dylan Brophy • 06/27/2019 at 19:24 • 0 comments

  I'm breaking the contract into two sections, each with a different 'owner' account.

  Why?  If something were to go wrong with one of the accounts (lost, hacked, stolen, etc), at least the attacker would not have access to the entire contract.  Furthermore, half of the contract would still work fine.

  How I've already done this a little bit:
  

  HOM Coin has an Oracle program that keeps it's price steady.  The Oracle account is separate from the owner account.

  I thought about the possibility of someone gaining unauthorized access to either account.  In this case I want one to be useless without the other, so that access must be gained to both.  So I changed some things:

  • Changing the oracle program account requires the permission of the Oracle account itself
  • If the owner destroys the contract then the oracle get's all of the contract's Ethereum

  Attacker tries to destroy the contract to get the Ether?  Nope, Oracle gets it.  Wants to manually manipulate the price by accessing the oracle?  Oracle address can be changed, and the owner cannot change the oracle account without already having the oracle.

  Attacking the contract is now like one of those movies about collecting 'all' of the stones or artifacts or something.  Really cool!

• Stepping Towards Better Security (avoiding overflows)

  Dylan Brophy • 06/24/2019 at 22:38 • 0 comments

  The security in the original HOM Coin smart contract wasn't terrible, except that it didn't check for overflows.  If this is to be a popular coin then it can't have problems like that.

  The problem with overflows
  

  Anyone reading this on hackaday should understand the idea of an overflow - in computers, sometimes when a mathematical operation is executed, the result does not fit in the finite space the result can store.

  With smart contracts, this can allow hackers to steal real money.  Lets say we have this psudocode as a function to send tokens to someone:

  function transfer(sender, receiver, uint8_t amount){
      if(balances[sender]>=amount){
          balances[receiver]+=amount
          balances[sender]-=amount
      }
  }

  This should work fine, right? Nope.  Let's say Alice has 200 tokens and sends 128 of them to Bob who has 128 tokens.  in this case, Bob's balance would become zero because 128+128 = 256, but 256 doesn't fit (used 8 bit unsigned values).  In essence, Alice just destroyed all of Bob's coins!  There are many ways problems like this can exists, and an Ethereum contract needs to be especially careful, because real money can be lost.

  Essentially I fixed security bugs like this, but there are also other security concerns.  The owner of the HOM Coin contract can destroy the contract (taking all the ether in the contract as well), or change the Oracle program's Ethereum address.  This is fine, unless the private key to the owner account is somehow stolen.  In this case the thief would be able to freely manipulate the HOM Coin price, or destroy the coin entirely, taking large sums of Ether.  No good.

  I made a change so that the oracle address can only be changed once the last oracle address has confirmed that the change is allowed.  This way, two private keys would need to be stolen for price manipulation.

  I still need to find a way to make contract destruction trustless.  Perhaps I will make the Ether evenly distributed among token owners - although this would take insane amounts of gas...

View all 5 project logs