Kā identificēt BlackList DeFi žetonu?

Turpinām rakstu sēriju, kas veltīta krāpniecisku shēmu aprakstam smart līgumos. Šodien analizēsim smart līgumus ar Black List funkcijām (BlackList).

Smart līgumu ar funkcijām BlackList bīstamība:

Smart līgumi, kas iekļauj Blacklist funkcijas, rada noteiktus riskus un problēmas gan projektam, gan tā lietotājiem. Šeit ir daži bīstamības aspekti, kas saistīti ar blacklist funkcijām:

1. Centralizēta kontrole: Blacklist funkcijas bieži nodrošina centrālizētu kontroli īpašniekam vai administratoriem.


2. Blacklist ļaunprātīga izmantošana: Ļaundarīgi elementi (ieskaitot līguma īpašnieku) var izmantot blacklist, lai uzbruktu konkrētiem adresātiem, iesaldējot vai ierobežojot kontu funkcionalitāti bez pamatota iemesla.


3. Pārredzamības trūkums: Blacklist funkciju esamība, it īpaši ja tās nav dokumentētas, var radīt pārredzamības trūkumu. Lietotāji var nebūt informēti par blacklist kritērijiem vai blacklistēšanas procedūru.


4. Drošības riski: Ja BlackList nav īstenots droši, pastāv ievainojamību risks, kas var atļaut neautorizētām personām manipulēt ar blacklist, kas var novest pie līdzekļu neautorizētas iesaldēšanas vai pārvedes.


5. Lietotāju neuzticība: Blacklist funkciju pastāvēšana var apdraudēt lietotāju uzticību, jo viņu aktīvi var tikt iekļauti blacklist bez skaidrām noteikumiem.


6. Žetonu konfiskācija: Uzbrucēji var izmantot blacklist, lai konfiscētu žetonus vai aktīvus no noteiktām adresēm bez pienācīgas pamatojuma, kas var novest pie būtiskām finansiālajām zaudējumiem.

Kā neatkarīgi noteikt, vai šādas draudi pastāv smart līgumos?

Validējot smart līgumu, var veikt dažus soļus, lai noteiktu, vai pastāv draudi, kas saistīti ar blacklist funkcijām:

• Pirms sākat darboties ar smart līgumu, rūpīgi izlasiet un izpētiet tā kodu, ieskaitot visus funkcijas, kas saistītas ar blacklist, iekļaušanu. Meklējiet funkcijas, kas saistītas ar blacklist, iesaldēšanu vai ierobežošanu konta funkcionalitātes. Pārbaudiet funkcijas, kas ļauj pievienot vai noņemt adreses no blacklist.


• Analizējiet, kam piederība vai administratīvā kontrole pār līgumu. Novērtējiet kontroles līmeni un tiesības, kas saistītas ar īpašnieku vai administratoru.


• Pārbaudiet līguma dokumentāciju, lai saprastu, kā tiek domāts izmantot blacklist funkcijas. Meklējiet informāciju par pārvaldības mehānismiem, kas kontrolē blacklist izmantošanu.


• Novērtējiet pārredzamību: Vai līgums nodrošina, ka blacklist kritēriji ir pārredzami? Pārbaudiet, vai ir skaidri procedūras nepareizu pozitīvo rezultātu izslēgšanai vai adresu noņemšanai no blacklist.


• Drošības auditu: Pārbaudiet, vai smart līgums ir izgājis drošības auditus no reputētām trešās puses kompānijām.


• Iepazīstieties ar kopienas atsauksmēm vai tiešsaistes forumiem par blacklist izmantošanu projektā. Būt uzmanīgiem pret jebkuriem signāliem no kopienas par netaisnīgām praksēm vai pārredzamības trūkumu.


• Veicot pamatīgu analīzi un ņemot vērā minētos faktorus, jūs labāk spēsiet novērtēt riskus, kas saistīti ar blacklist funkcijām smart līgumos. Sekojiet mūsu kopienas jaunumiem (Telegram kanāls) un labākajiem krāpšanas atklāšanas (mūsu Blog un YouTube kanāls) praksi.

 

Labas ziņas: mūsu Drošības skeneris 99,9% gadījumu atrod visus vispārīgos (ieskaitot slēptos) Blacklist funkcijas (BlackList). Izmantojiet mūsu premium abonementu un aizsargājiet savus līdzekļus no draudiem.

 

Tālāk mēs aplūkosim dažus visbiežāk sastopamos BlackList funkciju piemērus, ko mūsu platforma veiksmīgi atpazīst.

Jāatzīmē, ka šie ir vienkāršoti piemēri, un faktiskā īstenošana var atšķirties. Analizējot smart līgumus, vienmēr veiciet rūpīgu koda pārskatu un ņemiet vērā kontekstam atkarīgos faktorus.

Piemērs 1: Pamata funkcionalitāte Black List

    contract TokenWithBlackListAndFee {
      address public owner;
      mapping(address => bool) public BlackList;
      uint256 public BlackListFee;
  
      constructor(uint256 _fee) {
          owner = msg.sender;
          BlackListFee = _fee;
      }
  
      modifier onlyOwner() {
          require(msg.sender == owner, "Only the owner can modify the BlackList");
          _;
      }
  
      function addToBlackListWithFee(address _account) public payable onlyOwner {
          require(msg.value >= BlackListFee, "Insufficient fee");
          BlackList[_account] = true;
      }
  
      function removeFromBlackList(address _account) public onlyOwner {
          BlackList[_account] = false;
      }
  }

Atrasto ieteikumi:Meklējiet funkcijas (piemēram, addToBlackList un removeFromBlackList), kam ir piek ļuves modificētāji (onlyOwner). Šādu modificētāju klātbūtne nozīmē, ka tikai īpašnieks var modificēt blacklist.

Piemērs 2: Blacklist ar maksa mehānismu (BlackList ar maksu)

    contract TokenWithBlackListAndFee {
      address public owner;
      mapping(address => bool) public BlackList;
      uint256 public BlackListFee;
  
      constructor(uint256 _fee) {
          owner = msg.sender;
          BlackListFee = _fee;
      }
  
      modifier onlyOwner() {
          require(msg.sender == owner, "Only the owner can modify the BlackList");
          _;
      }
  
      function addToBlackListWithFee(address _account) public payable onlyOwner {
          require(msg.value >= BlackListFee, "Insufficient fee");
          BlackList[_account] = true;
      }
  
      function removeFromBlackList(address _account) public onlyOwner {
          BlackList[_account] = false;
      }
  }

Atrasto ieteikumi:Definējiet funkcijas (piemēram, addToBlackListWithFee), kas pieprasa maksu (msg.value), lai iekļautu blacklist. Šis ir ļoti bīstams signāls.

Piemērs 3: Blacklist ar laika atkarīgām nosacījumiem

    contract TokenWithTimeLock {
      address public owner;
      mapping(address => bool) public BlackList;
      uint256 public BlackListTimeLock;
  
      constructor(uint256 _timeLock) {
          owner = msg.sender;
          BlackListTimeLock = _timeLock;
      }
  
      modifier onlyOwner() {
          require(msg.sender == owner, "Only the owner can modify the BlackList");
          _;
      }
  
      function addToBlackListTimed(address _account) public onlyOwner {
          require(block.timestamp >= BlackListTimeLock, "Time lock not yet expired");
          BlackList[_account] = true;
      }
  
      function removeFromBlackList(address _account) public onlyOwner {
          BlackList[_account] = false;
      }
  }

Atrasto ieteikumi:Definējiet funkcijas (piemēram, addToBlackListTimed), kas uzliek bloka laika atkarīgus nosacījumus blacklist. Tas parasti tiek izmantots atliktai vai plānotai blacklistēšanai.

Example 4: Blacklist with Events logging

    contract TokenWithBlackListAndEvents {
      address public owner;
      mapping(address => bool) public BlackList;
  
      event AddressAddedToBlackList(address indexed account);
      event AddressRemovedFromBlackList(address indexed account);
  
      constructor() {
          owner = msg.sender;
      }
  
      modifier onlyOwner() {
          require(msg.sender == owner, "Only the owner can modify the BlackList");
          _;
      }
  
      function addToBlackList(address _account) public onlyOwner {
          BlackList[_account] = true;
          emit AddressAddedToBlackList(_account);
      }
  
      function removeFromBlackList(address _account) public onlyOwner {
          BlackList[_account] = false;
          emit AddressRemovedFromBlackList(_account);
      }
  }

Atradenas padomi: Notikumu reģistrēšana: Meklējiet notikumus, kas reģistrē blacklist darbības. Notikumi nodrošina pārredzamību un ir ļoti svarīgi, lai uzraudzītu līguma darbības. Varat teikt, ka šāda veida BlackList ir drošākais, jo izstrādātāji neizslēpj šo funkciju, bet atklāti reģistrē visus tās izsaukumus notikumu žurnālos.

Piemērs 5: Blacklist ar Whitelist funkcijām (Whitelist)

    contract TokenWithBlackListAndWhitelist {
      address public owner;
      mapping(address => bool) public BlackList;
      mapping(address => bool) public whitelist;
  
      constructor() {
          owner = msg.sender;
      }
  
      modifier onlyOwner() {
          require(msg.sender == owner, "Only the owner can modify the lists");
          _;
      }
  
      function addToBlackList(address _account) public onlyOwner {
          BlackList[_account] = true;
      }
  
      function removeFromBlackList(address _account) public onlyOwner {
          BlackList[_account] = false;
      }
  
      function addToWhitelist(address _account) public onlyOwner {
          whitelist[_account] = true;
      }
  
      function removeFromWhitelist(address _account) public onlyOwner {
          whitelist[_account] = false;
      }
  }

Atradenas padomi: Balto sarakstu funkcionalitāte: Uzmanieties no līgumiem, kuriem ir gan blacklisting, gan whitelisting funkcijas vienlaicīgi. Šāda divkārša funkcionalitāte varētu ietekmēt žetonu pārvedumus bez īpašnieka zināšanām vai citus krāpnieciskus darbības.

Piemērs 6: Blacklist ar Pārvaldības Kontroli (Governance Control)

    interface Governance {
      function canBlackList(address _caller) external view returns (bool);
  }
  
  contract TokenWithGovernanceControl {
      address public owner;
      address public governanceContract;
      mapping(address => bool) public BlackList;
  
      constructor(address _governanceContract) {
          owner = msg.sender;
          governanceContract = _governanceContract;
      }
  
      modifier onlyOwnerOrGovernance() {
          require(msg.sender == owner || Governance(governanceContract).canBlackList(msg.sender), "Not authorized");
          _;
      }
  
      function addToBlackListGoverned(address _account) public onlyOwnerOrGovernance {
          BlackList[_account] = true;
      }
  
      function removeFromBlackList(address _account) public onlyOwnerOrGovernance {
          BlackList[_account] = false;
      }
  }

Atradenas padomi: Identificējiet līgumus, kur blacklisting darbības ir pakļautas ārēju līgumu pārvaldnieku kontrolei. Veicot smart līguma izpēti, rūpīgi analizējiet kodu, pievēršot uzmanību piekļuves kontroliem, maksājumu mehānismiem, laika atkarīgiem noteikumiem un nosacījumiem, notikumu reģistrēšanai, pretestības aizsardzības līdzekļiem un citiem svarīgiem faktoriem. Turklāt ņemiet vērā projektu specifiku un tā mērķus, novērtējot blacklist funkciju izmantošanas ietekmi.

Piemērs 7: Blacklist ar Ārkārtas Apstādināšanas funkciju

    contract TokenWithEmergencyStop {
      address public owner;
      bool public emergencyStop;
      mapping(address => bool) public BlackList;
  
      constructor() {
          owner = msg.sender;
      }
  
      modifier onlyOwner() {
          require(msg.sender == owner, "Only the owner can modify the BlackList");
          _;
      }
  
      modifier whenNotPaused() {
          require(!emergencyStop, "Contract is paused");
          _;
      }
  
      function addToBlackList(address _account) public onlyOwner whenNotPaused {
          BlackList[_account] = true;
      }
  
      function removeFromBlackList(address _account) public onlyOwner whenNotPaused {
          BlackList[_account] = false;
      }
  
      function toggleEmergencyStop() public onlyOwner {
          emergencyStop = !emergencyStop;
      }
  }

Atradenas padomi: Ārkārtas apstādināšanas mehānisms var apturēt dažas funkcijas, ieskaitot blacklist izmaiņas.

Piemērs 8: Blacklist ar dinamiskajām nosacījumiem

    contract TokenWithDynamicBlackList {
      address public owner;
      mapping(address => bool) public BlackList;
  
      constructor() {
          owner = msg.sender;
      }
  
      modifier onlyOwner() {
          require(msg.sender == owner, "Only the owner can modify the BlackList");
          _;
      }
  
      function conditionallyBlackList(address _account, uint256 _threshold) public onlyOwner {
          require(getBalance(_account) < _threshold, "Account balance exceeds threshold");
          BlackList[_account] = true;
      }
  
      function removeFromBlackList(address _account) public onlyOwner {
          BlackList[_account] = false;
      }
  }

Atradenas padomi: Blacklisting bieži vien ir balstīts uz noteiktiem nosacījumiem vai notikumiem. Rūpīgi pārbaudiet funkcijas, kas tiek pārbaudītas, pirms aktivizējat Blacklist. Šajās funkcijās ir loģika īpašnieka pievienošanai Blacklist, piemēram, šajā piemērā nosacījums ir, ka konta atlikums ir virs norādītā sliekšņa.

Piemērs 9: Time-Locked Removal Blacklist (Laika bloķēšana)

    contract TokenWithTimeLockedRemoval {
      address public owner;
      mapping(address => bool) public BlackList;
      mapping(address => uint256) public removalTimeLock;
  
      constructor() {
          owner = msg.sender;
      }
  
      modifier onlyOwner() {
          require(msg.sender == owner, "Only the owner can modify the BlackList");
          _;
      }
  
      function addToBlackList(address _account) public onlyOwner {
          BlackList[_account] = true;
          removalTimeLock[_account] = block.timestamp + 7 days;
      }
  
      function removeFromBlackList(address _account) public onlyOwner {
          require(block.timestamp >= removalTimeLock[_account], "Time lock not expired");
          BlackList[_account] = false;
          removalTimeLock[_account] = 0;
      }
  }

Atradenas padomi: Identificējiet līgumus, kur blacklist noņemšana ir ierobežota laikā. Bieži šādos gadījumos tiek izmantoti laika aprēķini, pamatojoties uz block.timestamp.

Piemērs 10: Blacklist ar gāzes ierobežojumu (Gāzes ierobežojuma aizsardzība)

    contract TokenWithGasLimitProtection {
      address public owner;
      mapping(address => bool) public BlackList;
  
      constructor() {
          owner = msg.sender;
      }
  
      modifier onlyOwner() {
          require(msg.sender == owner, "Only the owner can modify the BlackList");
          _;
      }
  
      modifier limitGas() {
          require(gasleft() >= 100000, "Insufficient gas");
          _;
      }
  
      function addToBlackListGasLimited(address _account) public onlyOwner limitGas {
          BlackList[_account] = true;
      }
  
      function removeFromBlackList(address _account) public onlyOwner {
          BlackList[_account] = false;
      }
  }

Atradenas padomi: Identificējiet līgumus, kurās noteiktas funkcijas, piemēram, blacklist izmaiņas, ir pakļautas gāzes ierobežojumiem.

Piemērs 11: Blacklist ar ārēju integrāciju ar Oracle (Oracle)

    interface Oracle {
      function isBlackListed(address _account) external view returns (bool);
  }
  
  contract TokenWithOracleIntegration {
      address public owner;
      Oracle public oracle;
  
      constructor(address _oracleAddress) {
          owner = msg.sender;
          oracle = Oracle(_oracleAddress);
      }
  
      modifier onlyOwner() {
          require(msg.sender == owner, "Only the owner can modify the BlackList");
          _;
      }
  
      function addToBlackListByOracle(address _account) public onlyOwner {
          require(oracle.isBlackListed(_account), "Oracle did not confirm BlackListing");
      }
  }

Atklāšanas padomi: Uzmanieties no līgumiem, kas atkarīgi no ārējiem Oraciem, lai pieņemtu Blacklist lemts. Viemēr pārbaudiet oraku uzticamību un pārredzamību, ko izmanto smart līgums.

Piemērs 12: Blacklist ar mijiedarbību ar ārējo līgumu

    interface ExternalContract {
      function addToBlackList(address _account) external;
      function removeFromBlackList(address _account) external;
  }
  
  contract TokenWithExternalInteraction {
      address public owner;
      ExternalContract public externalContract;
  
      constructor(address _externalContract) {
          owner = msg.sender;
          externalContract = ExternalContract(_externalContract);
      }
  
      modifier onlyOwner() {
          require(msg.sender == owner, "Only the owner can modify the BlackList");
          _;
      }
  
      function addToBlackListExternal(address _account) public onlyOwner {
          externalContract.addToBlackList(_account);
      }
  
      function removeFromBlackListExternal(address _account) public onlyOwner {
          externalContract.removeFromBlackList(_account);
      }
  }         

Atklāšanas padomi: Kad tiek pieņemti Blacklist lemt, uzmanieties no līgumiem, kas mijiedarbojas ar ārējiem līgumiem, it īpaši, ja ārējā līguma avota kods nav pārbaudīts.

Piemērs 13: Blacklist ar Dinamisku slieksni (Dynamic Threshold)

    contract TokenWithDynamicThreshold {
      address public owner;
      mapping(address => bool) public BlackList;
      uint256 public dynamicThreshold;
  
      constructor(uint256 _initialThreshold) {
          owner = msg.sender;
          dynamicThreshold = _initialThreshold;
      }
  
      modifier onlyOwner() {
          require(msg.sender == owner, "Only the owner can modify the BlackList");
          _;
      }
  
      function addToBlackListDynamicThreshold(address _account) public onlyOwner {
          require(getBalance(_account) > dynamicThreshold, "Account balance is below threshold");
          BlackList[_account] = true;
      }
  
      function removeFromBlackList(address _account) public onlyOwner {
          BlackList[_account] = false;
      }
  
      function updateDynamicThreshold(uint256 _newThreshold) public onlyOwner {
          dynamicThreshold = _newThreshold;
      }
  }

Atklāšanas padomi: Identificējiet līgumus, kur blacklist slieksnis ir dinamisks un to var pārvietot pa laiku.

Vispārējie padomi par Black List funkciju (BlackList) identificēšanu

1. Meklējiet funkcijas, kas modificē adresu sarakstu (mapējumu):
   Pārbaudiet smart līguma kodu, lai identificētu funkcijas, kas modificē adresu sarakstu, piemēram, pievienošanas vai noņemšanas funkcijas.


2. Pārbaudiet tikai īpašnieku piekļuves ierobežojumus:
   Blacklist funkcijas bieži vien ir piekļuves ierobežojumi, kas ļauj tikai līguma īpašniekam vai administratoriem tās izpildīt. Meklējiet tikaiOwner modifikatoru vai līdzīgus piekļuves kontroles mehānismus.


3. Pārbaudiet constructor() funkcijas:
   Constructor() funkcija norāda līguma sākotnējo stāvokli. Pārbaudiet, vai constructor() tiek inicializētas kādas adreses vai saraksti, kas norāda uz blacklist.


4. Pārbaudiet modificētāju loģiku:
   Analizējiet modificētāju loģiku tipa tikai īpašniek, lai saprastu, kādos apstākļos funkcijas saistītās ar blacklist var tikt veiktas.


5. Atrodi atslēgvārdus:
   Meklējiet atslēgvārdus, piemēram, "BlackList", "addBlackList", "removeBlackList" vai līdzīgus terminus smart līguma kodā (vienkāršākos gadījumos šīs funkcijas ir ar līdzīgu nosaukumu, sarežģītākos variantos nosaukumi var neatbilst funkcijas būtībai, lai to paslēptu).


6. Pārbaudiet dokumentāciju un komentārus:
   Pārskatiet dokumentāciju un līguma komentārus, lai redzētu, vai tie ir pieminēti Blacklist funkcijas. Izstrādātāji bieži sniedz informāciju par to, kā šīs funkcijas, ieskaitot blacklist, jāizmanto.


7. Pārbaudiet ārējos izsaukumus (call) vai notikumus (event):
   Meklējiet ārējos izsaukumus vai notikumus, kas var tikt aktivizēti, kad adrese tiek pievienota vai noņemta no blacklist. Tas var sniegt ieskatu, kā līgums mijiedarbojas ar ārējiem komponentiem, balstoties uz blacklist saistītajiem pasākumiem.


8. Novērtējiet līguma koda atjaunošanas un pārvaldības spējas:
   Vērtējiet smart līgumu atjaunošanas mehānismus vai pārvaldības struktūras, kas ļauj veikt izmaiņas tā blacklist loģikā. Izpratne par to, kā tiek pārvaldīti atjauninājumi, ir kritiska, lai paredzētu potenciālās izmaiņas blacklist funkcionalitātē.


9. Pārbaudiet blacklist loģiku citās funkcijās:
   Pārbaudiet citās līguma funkcijās pārbaudes, lai noteiktu, vai adrese ir blacklist, pirms tiek veiktas konkrētas darbības.


10. Iepazīsties ar lietojuma gadījumiem un tokenomics:
    Iepazīsties ar projektu lietojuma gadījumiem un tokenomiku. Ja projekts saistīts ar lietotāju adreses pārvaldību vai tajā ir funkcijas, kas saistītas ar lietotāju tiesībām, var būt iemesls, kāpēc tiek izmantots blacklist.


11. Notikumu žurnāla reģistrēšana:
    Pievērsiet uzmanību notikuma žurnāla klātbūtnei, kas saistīta ar blacklist darbībām. Notikumi bieži tiek izmantoti, lai reģistrētu nozīmīgas stāvokļa izmaiņas, nodrošinot skaidrību par līguma darbību.


12. Gāzes ierobežošanas aizsardzība:
    Esiet piesardzīgs ar funkcijām, kuras ir gāzes ierobežojuma aizsardzība. Lai gan tas var būt drošības iezīme īstenošanā, tas var tikt izmantots arī, lai kontrolētu vai ierobežotu dažu kritisko līguma funkciju veiktspēju.


13. Laika atkarīgi nosacījumi:
    Pārbaudiet laika atkarīgos nosacījumus, kas saistīti ar blacklist. Piemēram, līgumi var īstenot laika bloķēšanu dzēšanai vai citiem laika jutīgiem mehānismiem.


14. Neatkarīgi auditi:
    Meklējiet smart līgumus, kuriem ir neatkarīgi auditi no uzticamiem auditoru uzņēmumiem. Auditēšanas ziņojumi sniedz ieskatu par līguma drošību un funkcionalitāti.


15. Pārskatiet kopienas atsauksmes:
    Pārbaudiet kopienas forumus, sociālos tīklus vai oficiālās komunikācijas kanālus par diskusijām par blacklist funkciju klātbūtni un izmantošanu. Lietotāji var sniegt vērtīgu informāciju un bažas.





 
16.  
17.  
18.  

Analizējot smart līgumu, ir ļoti svarīgi pilnībā saprast tās funkcijas un darbību. Šie padomi palīdzēs jums identificēt un novērtēt blacklist funkciju klātbūtni, ļaujot jums pieņemt informētus lēmumus par mijiedarbību ar līgumu.

Ja iespējams, izvēlieties līgumus, kas atbilst noteiktajiem standartiem (piemēram, ERC-20). Šie standarti bieži tiek pārbaudīti un ir labi zināmi savas uzticamības dēļ.

 

Mēs ceram, ka šie piemēri palīdzēja jums labāk saprast Black List shēmas smart līgumos.

 

Tā kā visi blokķēdes dati ir atvērti (protams, ja līguma avota kods ir pārbaudīts), iekšējai izpētei varat izmantot šo zināšanu un atpazīt dažādas krāpšanas shēmas.

Tomēr mēs jau visu izdarījām jums! Abonējiet premium abonementu un iegūstiet piekļuvi ekskluzīviem filtriem par smart līguma funkcijām un jaunākajām analīzēm. Palieliniet savas iespējas veiksmīgi ieguldīt ienesīgos žetonus.

Ar cieņu, Lotus Market komanda.

All posts