Analise smart-contract
23.01.2024

Jak zidentyfikować token BlackList DeFi?

Kontynuujemy serię artykułów poświęconych opisowi oszukańczych schematów w smart kontraktach. Dziś przeanalizujemy smart kontrakty z funkcjami Czarnej Listy (BlackList).

Ryzyka związane z smart kontraktami posiadającymi funkcje BlackList:

Smart kontrakty zawierające funkcje Blacklist niosą ze sobą pewne ryzyka i problemy zarówno dla projektu, jak i jego użytkowników. Oto niektóre z zagrożeń związanych z funkcjami blacklist:

  1. Centralna kontrola: Funkcje Blacklist często dają centralną kontrolę właścicielowi kontraktu lub administratorom.

  2. Wykorzystanie Blacklisty dla nieuczciwych praktyk: Nadużycia (w tym przez właściciela kontraktu) mogą używać blacklista do celowania w konkretne adresy. Może to obejmować zamrażanie lub ograniczanie funkcjonalności kont bez uzasadnienia.

  3. Brak przejrzystości: Istnienie funkcji blacklisting, szczególnie jeśli nie są udokumentowane, może prowadzić do braku przejrzystości. Użytkownicy mogą nie być świadomi kryteriów blacklisting lub procedury blacklistingu.

  4. Ryzyka związane z bezpieczeństwem: Jeśli BlackList nie jest wdrożony w sposób bezpieczny, istnieje ryzyko wystąpienia podatności, które mogą umożliwić nieautoryzowanym stronom manipulowanie blacklist, co może prowadzić do nieautoryzowanego zamrażania lub transferu funduszy.

  5. Brak zaufania użytkowników: Istnienie funkcji blacklist może podważyć zaufanie użytkowników, ponieważ ich aktywa mogą zostać umieszczone na liście czarnej bez jasno określonych zasad.

  6. Konfiskata tokenów: Atakujący mogą użyć blacklisty do konfiskaty tokenów lub aktywów z określonych adresów bez odpowiedniego uzasadnienia. Może to skutkować znacznymi stratami finansowymi.

Jak można niezależnie określić, czy takie zagrożenia występują w smart kontraktach?

Przy weryfikacji smart kontraktu można podjąć pewne kroki, aby określić, czy istnieje zagrożenie związane z funkcjami blacklist:

  • Przed rozpoczęciem pracy z smart kontraktem dokładnie przeczytaj i przeanalizuj jego kod, w tym wszystkie funkcje związane z blacklistą. Szukaj funkcji związanych z dodawaniem, usuwaniem lub ograniczaniem funkcjonalności konta. Sprawdź, czy istnieją funkcje umożliwiające dodawanie lub usuwanie adresów z blacklisty.

  • Przeanalizuj, kto ma własność lub kontrolę administracyjną nad kontraktem. Oceń stopień kontroli i uprawnień związanych z właścicielem lub administratorami.

  • Przeglądaj dokumentację kontraktu, aby zrozumieć, w jaki sposób mają być używane funkcje blacklisting. Szukaj informacji na temat mechanizmów zarządzania, które kontrolują stosowanie blacklistingu.

  • Oceń przejrzystość: Czy kontrakt zapewnia, że kryteria blacklistingu są transparentne? Sprawdź, czy istnieją jasne procedury eliminowania fałszywych pozytywów lub usuwania adresów z blacklisty.

  • Audyty bezpieczeństwa: Sprawdź, czy smart kontrakt został poddany audytowi bezpieczeństwa przez renomowane firmy zewnętrzne.

  • Zapoznaj się z opinią społeczności lub forami internetowymi na temat stosowania blacklists w projekcie. Bądź czujny na jakiekolwiek sygnały alarmowe podnoszone przez członków społeczności dotyczące nieuczciwych praktyk lub braku przejrzystości.

  • Przeprowadzając szczegółową analizę i uwzględniając powyższe czynniki, będziesz lepiej przygotowany do oceny ryzyka związanego z funkcjami blacklist w smart kontraktach. Bądź na bieżąco z najnowszymi wydarzeniami w naszej społeczności (kanał Telegram) oraz najlepszymi praktykami w zakresie wykrywania oszustw (nasz blog i kanał YouTube).

 

Dobra wiadomość: nasz Skaner Bezpieczeństwa wykrywa wszystkie wspólne (w tym ukryte) funkcje Blacklist (BlackList) w 99,9% przypadków. Skorzystaj z naszej subskrypcji premium i zabezpiecz swoje fundusze przed zagrożeniami.

 

Następnie przyjrzymy się kilku najczęstszym przykładom funkcji BlackList, które nasza platforma skutecznie wykrywa.

Zauważ, że są to uproszczone przykłady, a rzeczywista implementacja może się różnić. Przy analizie smart kontraktów zawsze należy przeprowadzać dokładny przegląd kodu i brać pod uwagę kontekstowe czynniki.

Przykład 1: Podstawowa funkcjonalność Czarnej Listy


    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;
      }
  }

Sposoby wykrywania:Szukaj funkcji (takich jak addToBlackList i removeFromBlackList), które mają modyfikatory dostępu (onlyOwner). Obecność takich modyfikatorów oznacza, że tylko właściciel może modyfikować blacklistę.

common tips

Przykład 2: Blacklist z mechanizmem opłat (BlackList z opłatą)


    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;
      }
  }

Sposoby wykrywania:Zdefiniuj funkcje (takie jak addToBlackListWithFee), które wymagają opłaty (msg.value), aby być umieszczonymi na liście czarnej. Jest to bardzo niebezpieczny sygnał.

Przykład 3: Blacklist z warunkami czasowymi


    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;
      }
  }

Sposoby wykrywania:Zdefiniuj funkcje (np. addToBlackListTimed), które narzucają warunki zależne od czasu blokowania. Jest to zazwyczaj stosowane dla opóźnionych lub zaplanowanych list czarnych.

Przykład 4: Blacklist z logowaniem zdarzeń


    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);
      }
  }

Sposoby wykrywania:Logowanie zdarzeń: Szukaj zdarzeń rejestrujących akcje blacklistingu. Zdarzenia zapewniają przejrzystość i są bardzo ważne do monitorowania działań kontraktu. Można powiedzieć, że jest to najbezpieczniejszy rodzaj BlackList, ponieważ deweloperzy nie ukrywają tej funkcji, ale otwarcie rejestrują wszystkie jej wywołania w dziennikach zdarzeń.

Przykład 5: Blacklist z funkcjami WhiteList (Lista biała)


    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;
      }
  }

Wskazówki dotyczące wykrywania: Funkcjonalność WhiteList: Zwróć uwagę na kontrakty posiadające jednocześnie funkcje dodawania do blacklisty i whitelisty. Taka podwójna funkcjonalność może mieć wpływ na transfery tokenów bez wiedzy właściciela lub inne oszustwa.

common tips

Przykład 6: Blacklist z kontrolą zarządzania (Kontrola zarządzania)


    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;
      }
  }

Wskazówki dotyczące wykrywania: Identyfikuj kontrakty, gdzie działania blacklistingu są kontrolowane przez zewnętrznych zarządców kontraktów. Przy ocenie smart kontraktu dokładnie analizuj kod, zwracając uwagę na kontrolę dostępu, mechanizmy płatności, warunki czasowe, logowanie zdarzeń, ochronę przed omijaniem i inne istotne czynniki. Dodatkowo, uwzględnij szczegóły projektu i jego cele przy ocenie implikacji korzystania z funkcji blacklist.

Przykład 7: Blacklist z funkcją awaryjnego zatrzymywania (Awaryjne zatrzymywanie)


    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;
      }
  }

Wskazówki dotyczące wykrywania: Mechanizm awaryjnego zatrzymywania może wstrzymać niektóre funkcje, w tym zmiany na liście blacklist.

Przykład 8: Blacklist z warunkami dynamicznymi


    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;
      }
  }

Wskazówki dotyczące wykrywania: Blacklisting często może być oparte na określonych warunkach lub wydarzeniach. Dokładnie analizuj funkcje, które są sprawdzane przed aktywacją BlackList. Te funkcje zawierają logikę dodawania właściciela do BlackList, w tym przykładzie warunkiem dodania jest przekroczenie określonego progu salda konta.

Przykład 9: Blacklist z usuwaniem opóźnionym czasowo (Usuwanie opóźnione czasowo)


    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;
      }
  }

Wskazówki dotyczące wykrywania: Identyfikuj kontrakty, gdzie usunięcie z blacklisty jest ograniczone czasowo. Często w takich przypadkach używa się obliczeń czasowych opartych na block.timestamp.

Przykład 10: Blacklist z ochroną przed limitem gazu (Ochrona przed limitem gazu)


    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;
      }
  }

Wskazówki dotyczące wykrywania: Identyfikuj kontrakty, gdzie określone funkcje, takie jak blacklisting, są ograniczone przez limity gazu.

common tips

Przykład 11: Blacklist z zewnętrzną integracją z 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");
      }
  }

Wskazówki dotyczące wykrywania: Bądź ostrożny wobec kontraktów, które polegają na zewnętrznych Oracle do podejmowania decyzji o blacklistingu. Zawsze sprawdzaj wiarygodność i przejrzystość Oracle, które używa smart kontrakt.

Przykład 12: Czarna lista z interakcją z zewnętrznym kontraktem


    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);
      }
  }            

>

Wskazówki dotyczące wykrywania: Podczas podejmowania decyzji o umieszczaniu na czarnej liście, należy uważać na kontrakty, które interaktywnie działają z zewnętrznymi kontraktami, zwłaszcza jeśli kod źródłowy zewnętrznego kontraktu nie jest zweryfikowany.

Przykład 13: Czarna lista z dynamicznym progiem (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;
      }
  }

Wskazówki dotyczące wykrywania: Identyfikuj kontrakty, w których próg czarnej listy jest dynamiczny i może być ustalany przez właściciela w czasie (poprzez wywoływanie określonych metod kontraktu).

Ogólne wskazówki dotyczące identyfikowania funkcji Czarnej Listy (BlackList)

  1. Szukaj funkcji modyfikujących listę adresów (mapowanie):
    Przeglądaj kod smart kontraktu, aby zidentyfikować funkcje modyfikujące listę adresów, takie jak dodawanie lub usuwanie adresów.

  2. Sprawdź dostęp tylko dla właściciela:
    Funkcje Czarnej Listy często mają ograniczenia dostępu, które pozwalają tylko właścicielowi kontraktu lub administratorom na ich wykonanie. Szukaj użycia modyfikatora onlyOwner lub podobnych mechanizmów kontroli dostępu.

  3. Sprawdź funkcję konstruktora constructor():
    Funkcja konstruktora określa początkowy stan kontraktu. Sprawdź, czy jakiekolwiek powiązania adresowe lub listy są inicjowane w konstruktorze, co wskazuje na czarną listę.

  4. Zbadaj logikę modyfikatorów:
    Analizuj logikę modyfikatorów typu onlyOwner, aby zrozumieć, pod jakimi warunkami mogą być wykonywane funkcje związane z czarną listą.

  5. Szukaj kluczowych terminów:
    Poszukaj słów kluczowych takich jak "BlackList", "addBlackList", "removeBlackList" lub podobnych terminów w kodzie smart kontraktu (w najprostszych przypadkach funkcje te mają podobne nazwy, w bardziej złożonych wariantach nazwy mogą nie odzwierciedlać istoty funkcji w celu jej ukrycia).

  6. Sprawdź dokumentację i komentarze:
    Przejrzyj dokumentację i komentarze kontraktu pod kątem wzmianek o funkcjach czarnej listy. Developerzy często udzielają informacji na temat tego, jak powinny być używane pewne funkcje, w tym funkcje czarnej listy.

  7. Sprawdź wywołania zewnętrzne (call) lub zdarzenia (event):
    Szukaj wywołań zewnętrznych lub zdarzeń, które mogą być uruchamiane podczas dodawania lub usuwania adresów z czarnej listy. Może to dać wgląd w to, jak kontrakt współdziała z komponentami zewnętrznymi na podstawie działań związanych z czarną listą.

  8. Ocena możliwości aktualizacji i zarządzania kodem kontraktu:
    Oceń smart kontrakt pod kątem mechanizmów aktualizacji lub struktur zarządzania, które pozwalają na zmiany w jego logice czarnej listy. Zrozumienie, jak zarządzane są aktualizacje, jest kluczowe dla przewidzenia potencjalnych zmian funkcjonalności czarnej listy.

  9. Sprawdź logikę czarnej listy w innych funkcjach:
    Przeglądaj inne funkcje w kontrakcie pod kątem sprawdzeń, czy dany adres znajduje się na czarnej liście przed wykonaniem określonych działań.

  10. Odkryj przypadki użycia i tokenomikę:
    Zrozum scenariusze użycia i tokenomikę projektu. Jeśli projekt jest związany z zarządzaniem adresami użytkowników lub ma funkcje związane z prawami użytkowników, może istnieć powód do umieszczenia na czarnej liście.

  11. Logowanie zdarzeń:
    Zwróć uwagę na obecność logów zdarzeń związanych z działaniami czarnej listy. Zdarzenia są często używane do rejestrowania istotnych zmian stanu, zapewniając przejrzystość zachowania kontraktu.

  12. Ochrona limitu gazu:
    Ostrożnie podchodź do funkcji z ochroną limitu gazu. Chociaż może to być implementacja funkcji bezpieczeństwa, może też służyć do kontrolowania lub ograniczania wydajności niektórych kluczowych funkcji kontraktu.

  13. Warunki zależne od czasu:
    Sprawdź warunki zależne od czasu związane z czarną listą. Na przykład kontrakty mogą wdrażać zamknięcia czasowe na usuwanie lub inne mechanizmy zależne od czasu.

  14. Niezależne audyty:
    Szukaj smart kontraktów, które zostały niezależnie zaudytowane przez reputacyjne firmy audytorskie. Raporty z audytów dostarczają informacji na temat bezpieczeństwa i funkcjonalności kontraktu.

  15. Przegląd opinii społeczności:
    Sprawdź fora społecznościowe, media społecznościowe lub oficjalne kanały komunikacyjne w celu przeglądania dyskusji na temat obecności i używania funkcji czarnej listy. Użytkownicy mogą dostarczyć cenne wskazówki i opinie.




  16.  
  17.  
  18.  

common tips

Przy analizie smart kontraktu kluczowe jest pełne zrozumienie jego funkcji i działania. Te wskazówki pomogą Ci zidentyfikować i ocenić obecność funkcji czarnej listy, umożliwiając podejmowanie świadomych decyzji dotyczących interakcji z kontraktem.

Gdzie to możliwe, wybieraj kontrakty zgodne z ustanowionymi standardami (np. ERC-20). Standardy te są często analizowane i cieszą się reputacją niezawodności.

 

Mamy nadzieję, że te przykłady pomogły Ci lepiej zrozumieć schematy Czarnej Listy (BlackList) w smart kontraktach.

 

Ponieważ wszystkie informacje na blockchainie są publiczne (oczywiście pod warunkiem, że kod źródłowy kontraktu jest zweryfikowany), z tą wiedzą możesz samodzielnie badać smart kontrakty i identyfikować różne schematy oszustwowe.

Jednakże, my już to wszystko dla Ciebie zrobiliśmy! Zapisz się na subskrypcję premium i uzyskaj dostęp do ekskluzywnych filtrów funkcji smart kontraktów oraz świeżych analiz. Zwiększ swoje szanse na pomyślne inwestowanie w zyskowne tokeny.

Z poważaniem, zespół Lotus Market.

All posts

Connect to a wallet

Metamask