# George Loukovitis - Using decompilation to ensure token safety - Channel: [ETHCluj Meetup](https://streameth.org/ethcluj-meetup) - Date: 2025-10-07 - Duration: 14:39 - Watch: https://streameth.org/watch/yt-_JIzHINnj6Y - YouTube: https://www.youtube.com/watch?v=_JIzHINnj6Y ## Description The talk starts with a brief introduction to ERC-20 tokens and their prevalence in the Web3 ecosystem. I give an overview of their functionality and establish some desired behaviors. Once we've establish a baseline of what a "good" token looks like, we go over some examples of malicious tokens and the methods used to detect these undesired behaviors. Finally, I talk about how, with the use of the open source Gigahorse decompiler and static analysis, we can automate those safety checks and ensure the assets we trade are safe. ## Transcript Hello everyone. My name is George and I work at Dub. Now, this is my first time doing this, so I'll do my very best. I'll try not to bore you to tears. For the next few minutes, we're going to be talking about to tokens and their safety characteristics in particular. Now, at first glance, tokens seem pretty simple. You buy them, you wait for them to go to the moon, you sell them, you buy your Lambo, right? Well, not exactly. You see, most of the things we do in DeFi are in some way tied to tokens. If you're voting in a governance protocol, your voting power is represented by an ARC20 token. If you're providing liquidity to a DEX, your participation in that liquidity pool is also represented by a token. If you're staking with some liquid staking protocol like Leo, your share of the total stake is also a token. So, let's start with the definition. What is an ERC20 token? What we refer to as coins or tokens are smart contracts that implement the ERC20 token interface as that was defined by EAP20. So what is a token supposed to do? Amounts of a token can belong to addresses. This is what the balance of function returns. Amounts can also be transferred either directly if a user transfers a token an amount of a token to another address or indirectly if it approves another address to do so in its behalf through the approve function. Now that's at least what we expect them to do because as we've said tokens are smart contracts and these functions defined by the standard are implemented by arbitrary code. As a result, not all tokens behave the same. So, let's set some ground rules. How would a good token behave? Well, for starters, um a user's balance should be solely under their control. There should be no restriction in transferring the token. There should be no central entity that can control who can participate or not participating in trading this token. The token should hold some value that is not easily diluted. And finally, there should be no tax on transfer or at least if there is, it should be constant or capped. Ideally, before trading a token, we would know that it fits this criteria. But how do we do that? Well, a first step would be to simulate the actions we're planning on making with regards to this token and see if the results we get are the ones we expect them. So, let's say we want to trade this thing ape screen. How would we go about it? Um, we would first try and find an address that holds this token. uh this is just a query on our database at dub. This is accessible to all of you through our application. Then we would use a tool like foundry to try and simulate this address transferring tokens to another address and see if the balance delta of the second address matches the amount we tried to transfer and does not. So this tells us that this token has a tax on transfer 5% to be exact. Now, even if uh the simulation came back clean, we're not yet safe because it's not often the case that you're going to sell the token right when you buy it. So, what if you're currently able to sell it as proven by a simulation, but that's no longer the case in the future. In fact, that's exactly how honeys work. Within honeyots, there is some logic that may disallow certain users or all users but the owner from trading the token. So, how do we check for behavior that is not currently observable but may be enabled? We could try and inspect the source code. As a matter of fact, how many of you currently hold USDT tethers coin? Excellent. Let's have a look. We can see here that you're only able to trade this token if you're not blacklisted. Now, this violates our third rule. We can also see that once you get blacklisted, the owner has the power to wipe your balance. This violates our first rule. Finally, we can see that the owner is not renounced. You see, for some tokens, there needs to be an owner for initial setup, but then that role is renounced by setting the storage variable to 0x0 or Xerx dead. That's not the case right now. So, in theory, you could have your your balance wiped. Now, there is a whole social context outside of code that may let us trust Tether and trade USDT. But the point I'm trying to make here is that there is more to tokens than one might first think. Now, we were only able to find that out because we have access to the source code of USDT as that was provided to us by its deployers. That is not always the case. In fact, when a token is first deployed, more often than not, we do not have access to source. Coincidentally, that is also when it sees most of its action. So, what do we do then? That is when we can turn to the compilation. You see, we might not have access to the source code of the contract, but we do have access to the executable in the form of EVM bite code because that is stored on chain. Now, let's make this a bit prettier. Now, unless you're running the EVM stack machine in your head right now, this should not tell you a lot. But one of the things we do at DDOB is that we offer a decompiler. Don't worry, we're not charging for it. We can take this and turn it into this. And finally into this. Now, this we can inspect. Here we can actually find out about all the behaviors. We previously talked about blacklists, owners, taxes, everything. So, until now, we have gone over some of the ways you could go about ensuring the safety of a token you're about to trade. But to be frank, this takes some time and it also requires a bit of technical skill. What my team tries to do is to automate this process. You see, one of the cool things about the decompiler is that it gives us access to its results programmatically. That allows us to do static analysis on these tokens. For those unfamiliar, static analysis is the field of study that tries to gain insight in a program's execution without actually executing it. With it, we can define patterns tied to undesirable behaviors, check for them, and flag tokens. So going back to the ground rules we set for good tokens. We said that a good token should hold some value that is not easily diluted. In other words, it is not infinitely mintable. So how would we go about checking for a mint function? Mind you, they're not always called mint. We know a few things. We know that ERC20 tokens should implement a total supply function. the result of that of that function should not be subject to change. We also know that for a value to change on the blockchain and for that change to persist, it needs to be a storage variable. So we could first go and find the total supply function using its selector. Then we find the statement that is the return statement of the function and check what variable is returned. Finally, we can see if there is a storage variable that flows to to this return variable. Having that storage variable, we can then check for an S load statement that targets this specific variable. Finally, we can check for the public function that contains this sore statement. And that's how you find a min function. Now, this is a pretty simple example. And to be clear, there are some tokens that do need this functionality. You cannot have a stable coin without a mint function. or it might make sense for a token tied to a charity to have a tax on transfer. But the point I'm trying to make is that it is important that we know that the tokens we trade have code that matches how they were advertised to us. Thank you for your time. Thank you for the presentation. Do we have any questions? No questions. I'll ask a question. So, what's the most common token type that is dishonest that you've seen? You mentioned like honey pots and I always receive like random tokens in my wallets um that I normally assume they're honeypotss. uh but what other type of tokens the average user should be aware of and be very careful. >> So there are a few patterns that are typical and might be worth looking out for. One of them is the owner of the token having the ability to manipulate your balance. Another is the ability to block specific actors from participating in trading. That's essentially what a honeypot is. you get blocked from using the token. Uh something else would be the tax. So if you're buying or selling the token, it's one thing to have the DEX take a tax a fee. So UNISAP has a fee, but it's another thing for the token itself in its logic to have some portion of the amount you're trying to send sent to the owner or the developer or whatever. These are the typical things you're trying to look for. But it always makes sense to put this into their perspective of how the token is marketed. So the social context of a token might justify such behaviors, but that is not always the case. I think we're good. >> I just want to give the audience the opportunity to ask. Here's the gentleman. Can you introduce yourself, please? Uh, hey I'm Zuki. I'm a developer. Um, I like the the code you show the code snippet you showed. Is there any tool where which scans the actual contract codes something like that to find if the something like what you researched as if if I was developer can I find similar vulnerabilities? Of course. So uh oh I cannot actually go back to the slide. It's all right. It's all right. So, um, the solution we're trying to make encompasses all of the methods we talked about today, but in particular with static analysis, we're using an open source tool that we uh maintain that's called Gigahorse. Uh the gigahorse tool chain decompiles the EVM bite code and then you can use uh data log to define relationships that you might think are tied to malicious behaviors. That is what you saw earlier. You read the relationships in data log and then gigahorse runs them for you. So you have access to it. Yeah. I have one final question, but anyone else in the audience, do you have a question? I'll ask my question. Um, apologies for the ignorant question, but can a developer launch a code or a token and then change the the token and and once you receive? So, sorry, I I will paraphrase this. Essentially, if you get a token, whatever you get an airdrop, and then you want to engage with this token, you want to sell it for whatever reason, is there a way for the developer to then drain your entire wallet from you engaging with that token? And what are the characteristics that we have to be aware of when something like this might happen? So the thing is uh that tokens the functions uh wallets call when you're trying to trade, buy, sell, transfer or whatever can be whatever. So there is the case where the transfer function on a token actually call uh actually calls approve on some other token that you own and you sign for the whatever attacker might be to be able to transfer this token this other token you own on your behalf. So yes, not knowing the code could actually lead to you losing not just this token but others as well. Thank you. Thank you so much for your time.