There hardly is someone who isn’t aware of how crucial it is to safeguard your assets as you enter the web3 market. You never know — scams, phishing, and all kinds of fraud can be lurking behind so many deals. Besides, scammers are becoming smarter, carefully camouflaging the risks and wrapping them into multiple layers, from web apps to social networks to smart contracts.Many scammers prefer to target their attacks at inexperienced users who are new to blockchain technology. However, no matter how advanced you are in the field, you aren’t 100% immune from getting trapped in a malicious scheme. You may even be able to check smart contract code to figure out the ins and outs of its algorithms… and still not have a safety guarantee.That is precisely why the Web3 Antivirus team has designed a brand-new technique aimed at smart contract simulation and audit. By polishing the feature non-stop, our engineering squad enables the tech to detect many kinds of multi-vector attacks that often go unnoticed by conventional checks.<h2 id="header-0">Uncover malicious logic behind smart contracts</h2>Take, say, contract owners’ privileges — W3A checks them as well. Why? What makes them so dangerous? Well, smart contracts often include methods that are exclusively available to owners, not regular users. These could involve token minting, metadata operations, and the like. But normally, as you know, none of these actions inherently jeopardize your assets.The thing is, a malicious actor can inject ill-intended logic somewhere within the code, so by executing the modified logic users unintentionally approve more privileges on the contract owner’s side. And just like that, the owner will have the freedom to transfer or burn users’ tokens with no permission. In other words, your funds can disappear at any moment.<h2 id="header-1">Learn about token burning in the first place</h2>Now, let’s take a step back to refresh our knowledge about token burning. In a nutshell, it is the process of removing tokens from circulation by calling a specific method. These tokens can be either specific assets or, say, a definite number of ERC20s. Again, naturally, it’s just the owner who can burn them.Imagine your wallet holds three NFTs that you can freely transfer, grant access to, or burn at any time. This means you are the only person who has control over your token balance. If you burn one NFT, you know you still have two left. No one else can manipulate your assets unless you give them access. And this is what we’ll focus on specifically.<h2 id="header-2">Rule out hidden token burning risks</h2>This brings us back to W3A and the real-life cases it helps with. Why do we pay so much attention to burning risks? As mentioned, we’ve recently implemented a brand-new analysis technique. During a test drive, the team discovered an <a href="https://etherscan.io/address/0xda0151513c5Af9f98b07cC3594e8cbFeBCc15cec#code" rel="noopener noreferrer nofollow">NFT contract</a> that allowed its owner to transfer and burn tokens without users’ knowledge.At first, the fact that our analyzer reacted to the contract puzzled us, as manual code checks failed to identify any abnormalities. Yet, a detailed audit enabled us to uncover hidden pieces of code.<img src="https://academy-public.coinmarketcap.com/srd-optimized-uploads/aac35e7a52e94adcb2ab2ab4466c2c62.png" />What you see above is the burn method, where the underlined piece verifies whether the person attempting to burn a token is its rightful owner or has the owner’s approval. Then follows calling the contract’s internal method (the highlighted part, again):<img src="https://academy-public.coinmarketcap.com/srd-optimized-uploads/95f8cdb4df324d67a4c1de7d7a9187f1.png" />Basically, if zooming in, that’s exactly where the major token burning logic resides:<img src="https://academy-public.coinmarketcap.com/srd-optimized-uploads/09cd85030439448b8d5974dc301e9078.png" /><h2 id="header-3">Sit back &amp; watch W3A detect bad burning logic</h2>Now, let’s shed some light on how we’ve managed to detect malicious logic. Technically, we handled this by calling the internal _isApprovedOrOwner method. Under the hood, it first checked if the token that was about to be burned even existed:<img src="https://academy-public.coinmarketcap.com/srd-optimized-uploads/35fdec491bd248199761449b7ebefe58.png" />Then W3A checked if the following conditions were met:1. The one who initiated the token burning transaction is the NFT owner:<img src="https://academy-public.coinmarketcap.com/srd-optimized-uploads/1b867b3346cb4cde9dcfbee64b6f31f8.png" />2. The initiator has approval to burn this particular token:<img src="https://academy-public.coinmarketcap.com/srd-optimized-uploads/4b569afe0bcf47e4b02b83c81c2ce913.png" />3. The initiator has approval to access all the tokens owned by a specified user (in our case, that’s the one whose NFT is being burned):<img src="https://academy-public.coinmarketcap.com/srd-optimized-uploads/e2312bdc35504d5b8e6f4fa148c95f1c.png" />Normally, in line with <a href="https://eips.ethereum.org/EIPS/eip-721" rel="noopener noreferrer nofollow">EIP721</a> specifications, calling a standard <a href="https://github.com/OpenZeppelin/openzeppelin-contracts/blob/master/contracts/token/ERC721/ERC721.sol" rel="noopener noreferrer nofollow">ERC721</a> contract method is meant to be a part of the check by default. However, in this case, the developer has modified the method. Meaning, the method enables proceeding with the check:a) Either in case the burning transaction initiator does have approval to burn all the tokens owned by a particular person:<img src="https://academy-public.coinmarketcap.com/srd-optimized-uploads/bd250a8e064e422aaec05adcfde3671a.png" />b) Or in case the burning transaction initiator is the contract owner:<img src="https://academy-public.coinmarketcap.com/srd-optimized-uploads/8c3bc8db93cb40149963c23ff45aee22.png" />Unsettling, right? See, if one of the three above-mentioned conditions is met, the burning mission will be successfully completed. And it’s specifically the third condition that contains the additional privilege enabling the owner to burn others’ tokens.<h2 id="header-4">Avoid unwanted transfer conditions as well</h2>Notably, the same workflow applies to asset transfer: transaction initiators get checked for approval in the first place. Remember, only the NFT owner or someone with the owner’s approval can transfer the tokens. Which leaves the exact same room for manipulations we’ve described above.So, watch out! If a contract developer modifies the check conditions to their advantage, they gain the freedom to transfer your tokens whenever they want, without your knowledge. And this is what we’re going to discuss in <a href="https://medium.com/&#64;w3a/how-w3a-exposes-unapproved-token-transfer-2df9d126c6bc" rel="noopener noreferrer nofollow">our upcoming post</a>.Stay forearmed with Web3 Antivirus and don’t miss out on more updates!

How W3A Helps Detect Malicious Token Burning Logic

Table of Contents

Web3 Antivirus

Other articles published on Oct 18, 2023

Elon Musk’s X Platform May Charge $1/Year in Two Countries for Posting

ASD (ASD) Price Prediction 2024, 2025, 2030, 2040, and 2050

How to Earn Crypto with Investment

TSLA Earnings: Margins Expected to Shrink, But Tech Narrative Dominates

Unlocking the Potential of Generative AI: NetSuite’s Quest for Clarity

Coinbase selects Germany as a key regional talent hub amid the growing shift of web3 firms from t...

Join our free newsletter for daily crypto updates!