Smart Contract Security and Zero-Knowledge Assurance

Transcript

[music] [music] >> to everyone it's a again small rooms I think I'm loud enough to everyone sitting here. So yeah very good morning to all and one and thanks for turning up for this session. I one of my students here who is also the co-speaker is stuck in traffic so he's he will arrive in a minute. Yeah so as you can see today's topic I think yeah it's research so again when we open Google scholar it says standing on the shoulder of giants. I am standing on the shoulder of my four students listed out here and

unfortunately two of them couldn't make it because of they are sick they ended they came here but yeah I think the Gayatri and Brahmi Shri she fell sick. So Sarvajeet and Tikmani Sarvajeet is my PhD student and Tikmani he is final year BTech so they are doing fantastic job in this area and so yeah as it goes like don't ask me too much about the experiments they are the ones who are doing it. So I am no so I would say maybe like I will talk what how it works and all but then yeah feel please feel free to interrupt me because things might go wrong and go off the track. So yeah again it's I I would say research the beauty is like it's

always a work in progress it's never fully done. So yeah I would be love to happy to have your inputs and also collaborate on this particular work. So I think with this I get started like what is the what motivated us to actually take up this particular topic so my background lies mostly with the layer two protocols so that's what I did my PhD on. I wasn't do much into this part of bug detecting bugs and formal verification of the contracts.

So PhD students joined in the first year and he was already working in IIT Patna as a JRF working on this particular topic and he was the one who proposed this because yeah he was the one who dragged me out of the slumber like okay lot of L2 is done so let us start this and with him I got introduced to this area and thanks to him that it's it's a really nice field and yeah I also got to interact with Professor Subodh from IIT Delhi so he is a master in this particular area so sorry if things go wrong please handle it.

So yeah we really had a lot of discussions on this this and this area is I would say a pretty hot area and yeah also when talking to Sham and Satruki they were like really great I'm really grateful to them to who helped us supported this particular program and got us here to speak on this particular topic. Yeah so as you can see the problem in one slide so I think there are certain statistics but yeah this particular thing like okay so how the this things run in this particular thing I hope everyone is acquainted with this area of how you how this Ethereum ecosystem I would say the blockchain ecosystem works so I think

there are it's a decentralized setup where people come around float their transactions and then it gets piled up in a block and it gets executed but then what are the terms and condition you need to follow certain rules when you're entering the systems. So in a conventional system you know that the traditional setup you have this rules written down somewhere on stone so we called it either written down on paper or maybe somewhere digitally it's kept on the like verified audited by some centralized parties. So again we are moving to the decentralized world it's not the same we come with this notion of smart contracts so again it's nothing but a piece of code as I think all of you are aware of

this smart contract so here the rules are encoded and then they say that okay you're free to enter assistance, but you should adhere to certain checks and ifs and buts should be answered as well. So if you are acquainted with the open source community, I think also they have these certain rules. Also when I was designing the slides, the speakers also had certain guidelines. So it's same as that. There are certain rules you have to adhere to that. If you are not following that, then you are just thrown out of the system. So as simple as that. How what is the purpose of this particular smart contracts? So here what we say, okay, this is the input. It these are the functions or how this should be executed and that is what you're getting as the

output. So yeah, pretty much all the transactions are relying on this. Like this is how things should be executed. But then why this particular system? What is the problem with this particular so-called system which is working perfectly till time long? So what we saw is that okay, so now in this open system again, how these contracts are available? Because I'm doing some execution. There's this input, there's this output, and then I say that this is the logic. So what we observe that sometimes it's what we have this not the code in its human readable form. We have the machine readable codes, that is the bytecode

level. Sometimes the contracts that are coming out are not verified at all. So it might have certain bugs. That is again the pitfall of an open source platform when they say it's verified, but then the system is so huge that you you cannot go and check and audit each one individually. So we rely, okay, whatever you're supplying, it's okay. And then yeah, so I think this February 2025 byte bit attack, let me just glance through it. So what happened is that byte bit gave a guarantee, okay, this is our contract. It is audited. Everything is working fine. But and then they said that okay, this is signed and audited by your community, but the which was into

execution didn't match what was there provided as a source code. So there was a mismatch. So, as you see that there was not a commitment tagging directly that, okay, this is the contract and when I compile it, this is the bytecode. So there is a mismatch and bugs were there existing already in the bytecode because that was a changed version on which you compiled and the original contract, though it was audited, that was not something. So there was one-to-one mapping that was lacking here and that created a lot of problem. And now I think thanks to AI tools like manifesting like anything. So as you can see that maybe this numbers might vary, but last time we saw like until 2026 55.9% of the vulnerabilities, a lot of

vulnerabilities which was previously caught using the static analysis tools or the symbolic checker. More than that, LLM tools were quite effective in decoding, okay, the contracts that you have written bypassed the conventional tools and now we found out that, okay, your this code has a lot of bugs. I think this is a very big news in the community. AI tools going on board and they are pretty much efficient because throughout time and all they are learning the things how to detect the bug and all. So now this is the problem and in comes the fact that okay, so before I talk about obfuscation, one can question like why do I hide? So I think that thanks to yeah, we had a really good discussion as

I mentioned with Saurabh Wj and my team. So yeah, that was the first question that I asked him like why do we obfuscate this particular contracts and all? So yeah, the question is that when you're doing a trading you should build up some trust. So this particular source code should be supplied to you. Only then you can trust it. Okay, this if I compile it gets into the bytecode form and that is okay. But then what we saw that in this particular community, so MEV bot bytecodes, they actually released their bytecode because their trading logic if someone copies it, then it becomes a problem because you have multiple people competing in this system and everyone is looking for profits. So if you release your I would say

very logic which is which you have developed maybe your trading secrets if you are revealing it then it becomes a problem. Certain contracts again that that should be kept proprietary. I mean the code shouldn't be out there in the public because of some NDA signed and all so there are some official guidelines because of which you cannot make certain codes in public. I think what we are telling is not that hide your code and then do the business. That is not the message that we are telling here. We are saying that okay your code could be there out in the public but then what is you as a person viewing it? What are what what is that the attackers are

viewing it? So how does it run? So you have the source code and then you compile you put the bytecode and now as I highlighted that bytecode they have the source code they compile it they get their bytecode. So previously yeah people didn't know that okay so whether this particular one-to-one tagging is there or not. So what we did is that we tested okay these are the source code. I think Sarbojit and Thick Manik will take over regarding the experiments. What we saw is that given the particular source code corpus that we had we did this obfuscation using this beyond tool that was the only reliable tool that we had and then we saw that how the outputs

were giving getting us. So we passed it through certain tools that is starting analyzer tools like My Thrill Slither O&T and then we checked that whatever bugs existed in the source code are these being caught after obfuscation or not because yeah the who needs obfuscation maybe the very niche community needs this obfuscation but then we said that is this niche community again protected from the very attacks that we mentioned like how effective is this obfuscation? That is the first thing we checked. So obfuscation here in its original form doesn't mean that we hiding it completely. It is just that the information is retained there and then you are just garbling certain points. So I think there are three levels of

obfuscation I think Sarbojit will discuss later. But that is more or less that you are changing the renaming the variable names, changing the control flow of the method and so on. So our talk mostly figures out on this particular three aspects and then I will switch to module one. So first is that why do you hide what kind of tools you are using for obfuscation? So we have this source code obfuscator and then analyze its purpose but then we saw that to the attacker it's the bytecode that is available. So even though your source code is obfuscated if it's not utilizable usable because if you have to compile it and check also. So that is again not serving the purpose. The attackers can

still take the bytecode and inject some prompt and introduce additional bugs in that. So again that is the problem. So there is obfuscators how are the attackers using it? How are the defenders using it? Next pass what we did okay bytecodes are something which is pretty much commonly available because most of the contracts they supply the bytecode. Then we analyzed okay bytecode how can we analyze it whether is bugs or not. So there exists certain tools which checks even the bytecodes has some problem but they are not enough to exhaustively check that we cannot say this thing statement that this particular code is free of bugs.

That I would say is a very hard problem to say whether your code is free of bugs or not. So that is very difficult to state. One particular method you can say that can we just decompile this back because you can compile and get the bytecode. So can you get decompile it and get back the source code. So this is something we also tried but then as you see that one process I think if I just give the analogy if you are aware of hash function so what you do you have this large message you hash it you get a small digest but then there is compression loss of information. So we said that there is some hardness so it's one way and going back to the original pre-image of this particular function is hard. Here also we face the same problem. So what is that? We know that

it is compilation of something, but in the process it undergoes certain optimization. Maybe the very obfuscation that you do on the source code level that is not taken into account during the this compilation of the bytecode and then when we go back we have to check whether the source code from which you are getting the bytecode is it equivalent or not. So that is something again very hard to do. We we are still do not know because one easy way we tried out is that just feed it to an LLM tool. So what we got is very interesting results because first in the set we had the training set we had we already supplied the source code. The LLM tools I think we tried Favell 5.1 and

GPT-6 as open as this Astra and OpenAI all these tools we tried out extensively. So in the training set if we supplied the original source code it was working fine, but if we tried out with some bytecodes which didn't have supporting source code that was available to us, but we didn't feed it to the LLM tools then it was going wrong. It was throwing out something gibberish. And then we tried out with the existing decompilers like Giga Hertz, D Dove and Vandal. So even there also we got this opcode format which is machine readable, but that was not human readable. So we needed something which actually gives back the original source code. So still that

that check is still lacking. And then we tried to see that can we design a fuzzer which can check okay this is the reconstructed code and whatever original code that we are having is there is any equivalence or not. So the reconstruction part itself is a challenge and if we say the fuzzer states okay you your code is actually free of bugs, but then there are certain class of bugs which is not attributed to the bytecode. That could be due to cross-chain interactions. So again that is something we can cannot figure out until and until that interaction goes on board. Last part that we will talk about is the proof. So the question is that is obfuscation making sense or do we hide the code completely? If you are actually wanting, if you're too paranoid

about security, hide everything completely and then give us a guarantee that okay, so this is the code which I hided completely and this I give us a proof that my code functions correctly and then you convince the person who is actually executing the code, okay, this is the compilable form and then you also have to put a guard rails that no one can actually inject any kind of bugs into that particular bytecode. So I think the last part, the zero knowledge assurance is again still something that is unanswered. We are still checking that how do we design this logical equivalence because we have defined as a constraint. So if I say that this is this class of bugs are not present, then we have to map it to certain constraint. But again, I am

saying that designing this constraint is very hard and we saw in certain places we might miss certain checks or statements while designing the constraints because the proofs that we are constructing is artifact of how we are mapping this statements to mathematical equations. If things go wrong there, then we are done because it's it's actually an artifact of the human error that is being introduced. So I think this is just a overview of how people are going on board with this Ethereum ecosystem, how they're focusing on privacy. So I think there are a lot of discussions on private mempools, encrypted mempools and also private wallets where you just hide how transactions are going on. You are actually hiding the information like if

if someone knows this is my wallet address, they can see what transactions did I did. So Cohaku wallet, it got introduced in 2025 and then they there they actually ensure that okay, things are going into a shielded pool where no one can actually track. So one way we have privacy, but the other pitfall is that you can introduce a lot of malicious players who can misuse this particular system. So okay, so now apart from that, I think this theme of this very defcon is again security and privacy. So yeah, this is the need of the hour, like how we integrate privacy in all the all the aspects of whatever Ethereum is

dealing with. So yeah, I think this is what I just mentioned previously, how things are working. So you have this publishable source code and then you run the analyzer and say, okay, it is free of bugs. And then you say, okay, now the your decision comes is that you can prove put it in the bytecode format. You can release the source code along with it or you can give the bytecode obfuscate the source code or maybe you can also go for bytecode obfuscation if you do if you are still paranoid, okay, my bytecode could be decompiled and then you get the original source code. So the question arises that what kind of combination works here because these these are a lot of permutation combination things that you need to work out depending on your particular use case. And also we analyzed like

there are certain like situations under which what kind of level of privacy is demanded. It's not that all those contracts need to go undergo strict rigorous level of privacy. So I think we also identified and we wrote a paper on which is an SQ which highlights, okay, these are the different cases. Okay, these are the cases which might need hiding of the particular source code, but for I think majority of them they can actually have their source code given as it is. But then again, the question is that are you getting the correct source code and can we say even this particular source code, whatever tools that are existing, can we say that it will not never cause any problem when you're executing it? So as I mentioned in our talk, we are seeing all these

three aspects. So first is of the power of the obfuscators, then of the LLM tools, how it is working, and then the ZK system from the aspect of an attacker and defender. So I think two first two I mentioned, then about the ZK. So designing ZK proof as an defender is very hard because I had to say that, okay, this is hidden, how things are working perfectly. But for the attacker, as I mentioned that if I just put some malicious transactions, previous transaction or just garble the particular circuit, introduced a bad setup. So, as an attacker, things are easier for me because it is like you do a proof. So, if I say prove that the system is working, it is exhaustively

have to check all the all the constraints. But if I have to just introduce this proof of this I have to introduce one misbehavior, that is easier for me to do. So, for an attacker misusing these set of tools and the which we have in our arsenal is pretty much easy. So, I think this is what we will talk about. So, module one we will see that how our analysis work. So, first we will talk about how this contract analysis works here. So, I think let us see that okay, once we analyze so these are all the static analyzer. This is pretty old convention like 2017-18 people were focusing on this nine class

of bugs. So, till date like the modern solidity compilers like 0.8.26 version is actually done away with this integer overflow and I think timestamp dependency is also pretty much handled because now you're sticking to this slot of 12 seconds. So, mostly I think these two problems are gone. But this reentrancy and transaction ordering is a big problem because MEV all the bots are still playing around direct can they do this front running and get the gains. And also this denial of service access control, all [snorts] these are big much quite bigger problem and I think this last delegate call this is what this 2025 attack relied on. So, it is like

you say so again we saw that what was the problem here. So, that was it says that your untrusted code is now going out there. So, we say that the code was working correctly but then the bytecode that they were functioning was was compiled version of an untrusted code. So, that became the problem because you're relying on a delegated call, someone to whom you delegate this particular task of executing this particular contract. So, we took certain set of codes and that that is a that was a starting point. Though it is a pretty old corpus, but that was a starting point. But I think this is an oldest what does it doesn't highlight upon is the recent losses that is oracle manipulation attack logic and rounding errors, compiler bugs and also

compromised keys. Again this compromised keys is less of a artifact coming from the bytecode more of the how you are doing this interaction cross chain interaction. So, write instruments that we found out is again formally verified formal formal is it is the contract formally verified and how are the fuzzers working? If you have just bytecode how the reconstruction is working. So, yeah so we ran these four tools. I think last two are deprecated. First two tools are still in function the slither and mythril and I think mythril was performing pretty better even it was instrumental in figuring out bugs in the bytecode but again the results were not I would say very much to be happy about because

it has a lot of limitations that I think Sarbojit will discuss when he discusses module three. So, okay so now the question is that in during static analysis how does the bug finding tools work So, I would say that it goes by this check effect and interaction rules. So, once you write the smart contract it should follow a rule that is what I said. So, first if you saying I am doing a transaction from party A to party B. So, first thing you need to check that party A does it have a required balance and then you introduce the effect that says okay if A to B is going account should money should be debited from my account and credited to the other account. Is that effect being is the effect being in place? So, and then you

do the interaction. So, once you have checked everything then you do the interaction. Okay now I can say that pay initiate the payment. So, let us see that this particular exercise I am not sure how visible is this. So, we have three segments of code that is part A, part B and part C. So, so, the question arises that which particular code segment is correct. So, I think this is something we start off when we were introducing the smart work tools and the vulnerabilities of smart contract in my this Ethereum course as well. So, how do you go about checking which particular code segment is okay or not? So, in this particular thing we saw that A was okay.

I mean though it was it had this effect first. So, first you check that the message so that part we saw that first it checks the effect. So, first you check that message sender, the sender is having the enough balance. Then what we say that whatever balance was there in the sender's kitty, so you transfer it to the [gasps] particular particular person to whom you are paying. So, reduce the balance to zero and then you initiate the payable message. So, this is check effect and then interaction. What went wrong in code segment B? So, if I just go back here. So, here what we were doing that first we were doing this particular part of interaction. So, first I am saying that okay initiate the payment and then I am doing this

particular effect that I'm reducing the balance. So, in the process what can happen is that I can actually have a balance of maybe 10 but then I end up doing a transaction of 20. So, that means 10 tokens got generated from nowhere and then got credited. So, so, now you can question that is that possible? No, because I can have 10 and I cannot do 20. But where this can create a problem is that if I balance of 100 and so here I don't need to make this balance as zero. Suppose I have a balance of 100 and then I just say that the pay should get 10 tokens and the balance should reduce to 90. But now what you do? You do this initiate this payable multiple times. So, apparently this might not be

too much visible here. But if you do it multiple times like execute this particular code. So, if you see that multiple requests are coming. So, it can be that the payable gets executed multiple time and then the effect is being done. That means it could be that the minus 10 is getting impacted after this payable is done. So that is something you shouldn't do. First, you should reduce the balance from your account and then initiate the payment. So this is I think the problem in a distributed system. I think if you are idea of how this distributed systems work in database management. So there is problem of concurrency. So do I debit first or does it get credit first? So these are the issues that can arise here.

And also the last one is okay because we checked the we did the effect and so yeah, so last one was a problem because it did the effect first and then it checked. It actually altered the very way but it gets flagged when we are checking but then it worked perfectly because I think that had some guard rail in place. So yeah, so what are the problems that can arise out of this? So you analyze it and then you see that check whether it's vulnerable or not vulnerable. And if it is not analyzed, then this code just goes out in the public and you don't know. So again, how are the tools effective? When we say it is not vulnerable, is it

false positive that you are relying on? So yeah, so I think this is again the workflow what happened in the byte bit attack. So as you can see that what did byte bit do? So they actually said that this is the transfer 30,000 ether and there were three signers were approving it. But what was the gap is that you delegated this particular call. So they replaced it with an attacker contract which had a spurious source code and that was the byte code and no one was there to check that this particular byte code is it matching the source code or not and then it led to a disaster.

So yeah, with this I hand over my session to Thick Manik because who is going to talk about hiding the source code. Yeah, yeah. So Thick Manik over to you. >> [applause] >> preserved

at the source code level as well. Right? They have to be preserved at the source code level. And and once you have those invariants, they act as pivots around which you can do automated test case generation, right? So test case synthesis can happen through invariants. Invariants acts as specifications around so they act as pivots around which the entire downstream tasks can be then automated. Now now where now specification synthesis is a hard problem. If you look at it, specification synthesis in general is undecidable.

In the simplest of cases, it's not in the NP class. Right? Uh So what you can do is that's where your LLMs get in. So you can feed the bytecode to LLMs, figure out specifications which you can independently validate through you know Floyd-Hoare logic or whatever, right? And then use those specifications in your decompilation process. Uh once you have the source code, just apply the same specifications as invariants to see whether those invariants hold or not. And accordingly refine or weaken either strengthen or weaken based on the invariants that you had detected at the bytecode level which were already shown to be valid. So that's one way to go which is tractable.

The other way Yeah. This is a best best effort basis, right? So you assume that uh you have invariants computed at each block and then you go back and apply those invariants to your source code to prune out or uh augment the code blocks vis-a-vis those invariants. So that's one way. The other way is um and which is uh which is even more lightweight.

But because it's lightweight, you have lesser formal assurance is input-output equivalence. So what you do is you N-mass produce inputs. You fuzz and create huge number of inputs at the bytecode level. Note down their outputs. Then back pedal to your source code and maintain that input-output equivalence. And if it is not met, then you figure out whether you have to prune a path or augment a path, uh prune a behavior or augment a behavior.

That's more lightweight. And uh it's it's a function of how comprehensive is your input-output set that you have generated out of the bytecode, not out of the source code, right? Because that's your starting point. And there you can actually rely on statistical and techniques to make sure that you are sampling uniform at random. Right? I mean, if you take a random walk in the forest, it often times works better than any formal verification tool at scale. Right? Um um so these are the two ideas that are worth uh investing.

>> This part >> You have to say this because yeah. >> Okay. So uh Yeah. So uh yeah, this part of input output equivalence, I think they they were trying it out. But um yeah, again the question is that uh I think we didn't do it extensively on the all the sets of input and output because that was something uh still uh it worked for certain conversion like conversion of this bytecode and then whatever reconstruction we are getting back. Some of them were holding, some of them were not. And >> But that's even the second step. The first step is having uh some assurance whether your input output set

>> Yeah. >> pair the set of pairs that you have generated is through a principled strategy. >> Mm. >> And you provide some sort of a um reasonable formal assurance that maybe through coverage metrics, right? That my input output set has covered this aspect or this these many you know, you know, fix your uh metrics. It could be whatever. And based on your metrics, you can see that okay, this is these coverage metrics are being met through my input output pair. And they are sufficiently random uh in the space. And then go back and then see, you know, the second step which you are saying that, you know, in some cases it works, some cases it doesn't.

>> Yeah. >> But when it doesn't, then your repair strategies will have to kick in. Um So I just wanted to stop there. And also for that reentrancy, right? So you don't have to actually run Foundry for the entire execution sequence to figure out uh there's a there's a reentrancy. So it's an order N square check. So you could do it much simply by just taking two paths and seeing whether the output Yeah symbolic. >> did later. So first we checked and then we saw that it's not efficient. Yeah, then we next. But yeah, I mean, yeah, we will >> Sure, we will discuss more. Thanks.

>> Guys for attending our sessions. I would thanks the Defcon team as well. As introduced me myself, I'm Currently doing my BTech final year in IIT Indore. And me and our team we have been doing this research for More than six months. So we have came across a lots of conclusion, various result outputs and all. So once of the things that I'm working on on is this collecting dataset collecting by code source code and then working on this as smart smart smart box and all.

So what we are trying what we are are going to do in this module is that is the question is that is hiding the source code really protects smart contracts from from the attackers or from any adversaries. So the the the the The main question the main question the main thing about this session is is the whole solutions of of of this questions whether do the obfuscations of the source code really protects really protects from the various adversaries or not. So So so I will go through all of this this concept.

And we will love you people to have to have a discussions after after this sessions to share the ideas and all. So let's us check whether whether these obfuscations really really help help us protect from the adversaries. This obfuscation is is it is not a yes or no thing. We cannot say yes obfuscation work or no of obfuscation doesn't work. But it's it's depends from the perspective of whom? It depends from the from from different different point of view. If we talk from different point of view, if we talk from the human's reading points of view, yes obfuscation here is work because if we takes if we take the source code and all

when we try to obfuscate what what we what we what what our purpose is that to scramble the scramble the the the source code in such a way that is not human readable at all. So yes obfuscation in this in in in in in this kind of adversary really work. And when we see about this the attackers attackers when we see about attackers obfuscation the source code doesn't doesn't makes any sense because the attackers can can still attacks through the bytecode which without obfuscation without obfuscation and through the runtime bytecode because bytecode is public publicly available in the on chains and this source code also is publicly available on this on this ether scan and all. So from the

perspective view of this attackers attackers yeah obfuscation doesn't makes some some sense. And then we came across this some kinds of smart box tools also that we have used in our research to to detect and to to check whether obfuscation works or not. So we came across four tools we use my trails Osiris and OYENTE we check that. So here it depends on the output that we got from the from the from the we output that we get from after obfuscations.

So here we will discuss it later on and this one also about from the perspective of this LLM assistant nowadays we came across a lots of this powerful tools powerful models like GPT-6 this entropic fables and all. This this this this tools they can reconstruct even though we even though we we obfuscate the the the source code they can still reconstruct they can still they can still decode. And also obfuscation here also is barely barely works. And then since I'm talking about this obfuscations and also what we did is that BN is once of the tools that we use in our research where it was published

by some of the researchers in 20 2023 and it it it most of the time it yes it it it do a very good work in this four layer rename every it renames everything it it's it removes the comments and it's it packs the variables and all. In this in this way BN do very good very good job but but what we find out is that most of the time that we do obfuscations through this BN what happened is that after after we got the output and then we rerun them into the smart bug tools most of most of the time most of the contract doesn't compile. It's not compilable at all.

It's not compilable. This is the one of the things that we face we face with with BN. We face with BN. So yes as as I have been saying this this one the problem with BN here we will have a look we will have a look once of the valid this contract. Let's say let's say this this is a valid that we have. This is the valid that we have and this the the the white part is the original contract original contract and that in orange is the is the after obfuscation after obfuscation. So here question arise whether this code whether this output after obfuscation still compilable or not. And in the original in the original contract in the

original contract what we have is that if there is there is some bugs in in the original contract. So let's take a moment and and spot some and spot some of the box where does the box actually happens in this original source code and also is this is is this is this output still compilable or not? So I I I I want you guys to to have a look for a moments about this about this one and spot it out where the box happens and is the code still compilable or not.

Yeah, yeah, actually if we if we go through this original source code, if we go through this original source code, we find out that we find out that this there there is a box there, there is a box there in this balance. It subtracts the balance without even checking whether there is sufficient balance or not in the wallet. It subtracts it subtracts this one. This is the real box, but what happened with the obfuscation is that this box totally vanished with it. It doesn't it doesn't it doesn't check that this is the box, but it's totally vanished it totally vanished with it.

And also and also this obfuscation in the in the original contract in the original contract we have we have this one. In the original contract we have this this transfer and there is inbuilt transfer which is inbuilt in the Solidity, but after obfuscation what what happened is that this this this beyond tool it just rename everything. It just it just rename everything. It doesn't differentiate whether it is the the functions of the contract or it is inbuilt inbuilt functions of the Solidity. So it it's it's just renames everything. It just renames everything and it just rename everything and that one of the most problem that after the obfuscations most of the this code doesn't compile level at all. So

so yeah, just I have mentioned before just I have mentioned before like in our research we use three kind of four kind of tools this my trail Osiris and along with this we fetch around 1,000 contract and through this 1,000 contract we divide them into five batches where each batch contain 200 contract and we fetch this contract directly into this four tools into the full smart box tools. And what we found out is that most of the time when we when we when we run with this original contract most of the time this four tools comparable almost 90% plus. But what happened after the obfuscation is that what happened after obfuscation is

that on less less than 15 less than 10% it's it's it's it's compilable. This is what we found out with the thousand thousand contracts thousand thousand contract yeah this one have been discussed before and then and then what we find out is that as mentioned before only out of out of this only 4% is compilable only for after we run all those thousand contract after we obfuscate them after we run it again into the smart box tool only 4.1% is compilable only four 4.1% is compilable. So what happened to that 4.1% we we we we what what we we match them again we cross check whether it's still

what what happened with the original bytecode and then after that we find out that we find out then the the size the identity the the structure of the obfuscation bytecode and the original bytecode is almost identical it's it's almost identical. And and you can you can have a look there this this one and then and also we find out is that after obfuscation we try to after obfuscation the before the original bytecode was their unchanged only and then after obfuscation we try to run this this this the the output that we got from the beans and all we try to run it into the solidity compiler and after we run into the solidity compiler the output that we got the output that we get and the

bytecode is is no no different at all with the original bytecode with the original bytecode so so the four layer that we are doing before this renamings renamings removing the comments and all is still the same with the original bytecode with the original bytecode even though after we obfuscate this source code so this is the the thing. And here also when we look on for for a particular for a particular this one uh particular batch this batch one it it include for 200 contract 200 contract where in my trail you can see the data you can see the statistic and all and originally originally there this consensus positive having 490 and 490 and then 29 for

obfuscated but this one this detected by my trail is is reducing after after this after obfuscations to 18 it reducing so here efficiency you saw that it you saw that it's it's increasing but but this is is we saw the efficiency is increased from 41 to 62 but the actual thing is that but the actual thing is that it doesn't reduce it is it doesn't hide the box and all what happened is that it doesn't compile that's why it doesn't it doesn't compiles it doesn't compiles means if it is compiled then we can have a half a clear clear result to cross check between the source code and the obfuscation bytecode but

but since most of the code is not runnable at all that 's why that's why the the data here is is not as exactly as what we found out and then and then this is the thing that some of the research researcher this in recent this year only they try to hide some of the MV bytecode almost so 1046 they try to hide they try to hide from the attackers attackers but still this attackers they can they can still attacks they can still they can still find the box through this bytecode because when we try to obfuscate is that is not human readable and all for me for the human people or for the normal people means is not is not readable at all but for the automated tools that can

detect bug easily with this bytecode and all and and that is the reason most of the hacker they can still they can still attack and they this they can still steal steal most of their money so this we find out into the conclusion that obfuscated source code doesn't mean that it will prevent us from attacker, attacker, but it will prevent us from the different different perspective. It depends who are the adversaries. It depends. So it's the thing we find out after obfuscation the code. So this is the thing about after this one and will I will go to the next module and I will hand over it to our work by you.

>> [applause] >> Hi. Good morning. Good morning [clears throat] to all. I am very overwhelmed that I got the opportunity to speak here and I am basically doing PhD second year and I am Sarabojit Goswami and my supervisor is very respected and reputed Dr. Subhra Majumdar and she is sitting here.

So Thickmanik told about hiding the source code and the pros and cons and everything. So I'm going to start with hiding the bytecode. So a tool called a tool called Bosk is available on on open source. This paper their paper has been published in ACM Tosem and this tool actually directly converts bytecode to the obfuscated bytecode.

So here is you can see the see some examples like It is visible na? Yeah, it is visible. So what bytecode obfuscate what a bytecode obfuscated [clears throat] obfuscation does? Basically the need of obfuscation in bytecode comes the total and fully decompilation of bytecode is not possible, but we can construct CFG, that is control flow graph, that is an intermediate representation if we go through compiler techniques, we can see that and when we can form a CFG

through the bytecode. The CFG has some nodes and have some edges and those nodes and edges can contain some valuable assets, some API key etc etc which can be stolen and that is the main check and to obfuscate the bytecode and if we obfuscate the bytecode, it will give a gibberish result. From that gibberish result, we cannot come to any conclusion. All right, excuse me, sorry. Yep so

that is the reason of obfuscation. So any morphed bytecode cannot give us any very well designed CFG and from that CFG we cannot do any conclusion, we cannot steal any asset. Going to the next slide, yeah. So we have made a dataset of 569 deployed bridge bytecode because our research in here is not on same chain. We basically want to do some cross chain bridge bytecode. We collected the data and Thick Money collected this data from Ethereum by API calling and we collected this because of to tackle the bridge hacks. Like when

some cross chain transaction happen, it needs bridge bridge for transaction and for this here there is some bytecodes and these bytecodes should be obfuscated because to we thought we can reduce we can reduce the vulnerabilities and here are some protocols. Some cross chain bridge transaction protocols we have taken that is hyper hyperplane layer zero then ohm hole CCIP XLR in total 569 we have collected.

So in these we can we can see these are the five protocols and by this protocol the cross chain money transaction happens and here we can see some statistics also that after we analyze the original this one and this is the bosk output and we can see that our research goal was to after obfuscation can we reduce the attacks or not.

Moving to the next one yeah. There is one special thing about bosk output always bosk give bosk gives us a shrinked bytecode any of any of any of the output of bosk is a shrink bytecode from the original one. So here you can see the output output size is greater than input size that is 100% here written it required but that is 0% because the input size input size is always greater here.

Now despite sorry what is and yeah these are some statistics also there. Median output size and is percentage of input and that is also lesser percentage we have observed and begins with entry dialogues and this is also moved when bosk does is does it work it mobs the entry data it mobs also the metadata and these are the things so everything here observed column everything is less in percentage.

So okay. So you can when and this bosk tool is open source anybody can download and run. Yeah. This is an minimal exercise a bytecode obfuscator only insert bytes. Which output could be real. So you can see that we also told I also told that of bosk reduce bosk reduce the length. So length is so you can easily get the answer. So yeah so answer is answer is only a because the output is things. So this is the main working function of bosk and you can go to their papers and study also how do they do so.

[snorts] The export kept on kept only finding. So we after the output of the bosk tool we run my on. My on is also a smart bug tool and it runs on bytecodes and it we tried it to run run on obfuscated bytecode. So here is some statistics you can you can see after after running the byte after running this on bytecode it it reduces. Running running means successfully run and getting getting a successful output or the vulnerability it is reduces and we can see this in the third column that it everything everything all it is written is dropped. Dropped value because my my

and can cannot give certain reason as as it shrinks and more of the more or big percentage of characters are wiped out my and couldn't come to a conclusion. [snorts] Yeah so this is what we run before any analyzer that is a size size invariant then prologue then opcode swipe and then differential. So this is a concept and why we are proposing we are proposing like we can reduce that bridge hacks and for bridge hacks recently there is a big hack of millions of dollars lost. So

that our proposal that before deploying uh the opcode, before deploying the opcode, if we can obfuscate or not. And if we can see in the Ether Scan nowadays the trend is to deploy mainly the opcodes. Mainly the opcode opcodes means uh 95% or more than 95% codes have been deployed in Ether Scan that is bytecode. Not the um the authors or the code or the developers they don't doesn't trust that they can deploy the source code. So that's why that's why we targeted in this in this research and even we have written a paper that is also uh communicated and under review in Financial Cryptography 2027 conference.

So these things that why we propose this bytecode obfuscation. Okay. Yeah. This is some statistics as you can see the 569 is our dataset and uh un un unchecked means that is everything is checked. Initially uh bytecode Mian and Securify they have run run on the source code and after it uh it it no nothing fails before obfuscation and this is this is 95% thing what I have said and after obfuscation the compilation rate drops obviously because as I told and it gets us to 27 to 83%

and we did one study also uh through DeepSeek Chat and GPT that can the LLM tool as of now can it de obfuscate or not? So we said we we saw that very less percentage uh basically none. So yeah the other side of obfuscates too. So this the study and the finding is our we have a large amount of dataset and data this dataset is made by us and we obfuscation is Tick Manic told the source code obfuscation and told the bytecode of first case and if we put this parallelly and we can tally them.

Nowadays source code deployment is very less. So we came to bytecode and we want to reduce the bridge hacks. So this is one of the biggest reason that we come to this research and here you can see the the boss we have run on the our tools and we checked we after before we before obfuscation we run smart bug tools. After obfuscation we run the smart bug tools and we tally these things and we see the results and you can see the boxes and these boxes is written here is a damage more plus longer it is written written. So you can see this way.

Okay. Now this is the fourth module and I would like to speak this over to ma'am. >> [clears throat] >> Okay. So I think this is just rehashing of what I just mentioned in the beginning. So yeah, I mean this is test that we performed and it is still a work in progress. I think Professor Subodh already we had a nice discussion on how to check equivalence post the reconstruction. So as you can see that most of the mostly the MAV bought bytecodes they were putting out the bytecodes there and what we were focusing much was can we reconstruct. So reconstruct inherently is that you have some information can you can you get

back the original source code. Now that is very important to see that how the source code is compiled and getting to the original bytecode then you were losing out some information because now you're converting it to a machine readable format. [snorts] So what we first tested out is the how good are the analyzer figuring out any bugs in this particular bytecode. So what we had that we originally had the source code then we tested on the raw bytecode how many bugs are getting detected. So we saw that very few bugs were getting detected using MyThrill and originally the source code had few few bugs. So there was a confusion that other compiler smart enough that are they actually getting

rid of the bugs, but that was not the case. It was not that it just failed to detect the bugs which was existing in the bytecode if we are not testing it on the source code and that became a problem because not all the times you are having access to the source code. So what we tried out is so now let me give you a particular idea like we used a gigahertz and that gives a tag representation. So three address code and there we were getting opcode version which was not exactly a full decompilation into a human readable source code, but then it gives okay this is the machine readable course code and can we apply any particular tool to figure out whether exist error or not. So recently this

ACM CCS paper scan it actually claims that it figure out any set of call based call transfer attacks that they could identify, but the other class of bugs they didn't define the equivalence logical checks by which they can detect the attack. So what we did here is that so once you have a reconstruction of this particular tag representation and what the attacker can do is that they can just have this particular tag representation but in a reordered format. So as you can see that suppose one code one part is deployed somewhere and the other part you are forking and you are deploying it

on some other channel. So what is that we have this deployed particular bytecode and then that one the other one which was reconstructed by LLM what it did is that it's saying that okay this bug was already there but what LLMs did they failed to figure out. They said okay this is how the check effect and interact interaction pattern should work. So what they did they said first loaded then store and then do this particular call and then the way the impact interaction should be done that is given out in the machine readable format. But in the meantime, what the attacker does is that maybe the attacker himself has deployed that particular code, but since the bytecode was

given out to there, only the attacker knows in the source code we did revert this particular ordering. So first they did this interaction and then this effect and then the check. So they just reverted the order. So what happens is that if I as an auditor I check the guarantee, even the symbolic tools fail to detect it, but then I'm relying on the reconstructed code that that is done by the LLMs. So what did the LLMs do is that first we took this in between gigahertz of the D of compiler which was giving us the opcode and based on that we were checking that is this a correct way of decoding or not and then we were reconstructing. So the reconstruction was okay, but then we had

to check is there a equivalence holding or not. So I think what we had a discussion with sir, sir said that we could check the input output equivalence. So extensively we generated the test cases. Okay, these are the input output that will give the equivalence. Okay, this is working in the bytecode that was working in the source code. But now consider the situation when we don't have the source code and then what we are reconstructing, is it correct or not. So inherently the bug equivalence is suppose is the one which we need to check. But if the bug detection itself is missed out in the original bytecode and it's not reflected in the reconstructed source code, then there is

no way to actually figure out the lack of bug in this or this bug which was missed out during the reconstruction. So what does it say that when we say the reconstruction matches, matching based on what? So first we have this equivalence. So suppose I have the source code already given and then I reconstruct and say that there is a pattern matching that this just normal English test matching and that we found out for most of the cases, but then it had certain limitation. So we had to check the symbolic equivalence also. Suppose how the control flow is going out. So do we have extensively checked across all the import output? So that is one question. And the other question is that what is not in our hand. So this

unbounded functional equivalence. Unbounded functional equivalence means when this is this contract is interacting with other contract lying on the cross chain, how it is behaving? So are we able to detect that cross chain bugs or not? Even if there's some prompt injection attack occurs in between in the bytecode, do we check for this integrity? Because I am getting some bytecode and along with that we get a commitment, okay, this was generated from this particular source code. But if you don't if you don't have that particular source code, how can you check that there's a one-to-one equivalence? So then it becomes a problem.

So we see that the static and symbolic analyzer is not solution to all our problems. So we also started this fuzzers that is So this we this is giving us an equivalence check, but the only problem is that whatever you're reconstructing, is it correct or not? So again that becomes a problem. If we say x equal to y and you don't know what is x, then it becomes a problem that how even you do the equivalence check. And then the formal verification certora prover, then again it's it's very difficult because you have to first define the specification. As we discussed that certain pivot should be discussed best based on which you should say that there is an one-to-one

equivalence and these specifications should be checked. And that is yet it is still not tractable to say that which specification we should focus on. So okay, so and now what AI agents are really doing now? So they extensively just run and learn from the existing particular codes that are existing and they also have the source code. From that they are figuring out what vulnerabilities they do. So extensively they flatten out the bytecode and they are getting that okay these are the bugs already existing. Can I introduced inject more prompts and create a dummy interaction between the contracts and see if there are other bugs that are getting introduced.

So because AI agents are pretty powerful there are multiple agents working mimicking this interaction. They were able to figure out that okay these are the 55.9% more number of vulnerabilities that are being detected. That was something which was not previously detected even using this existing tools or even for using the fuzzers also they couldn't do a equivalence reconstruction because previously as I said that you we don't even know how to reconstruct. So the easiest part here is that as a defender I need to know that what are the gaps existing and to fix them. As an attacker I just need to figure out only one loophole where I just inject my prompt I know that this will go wrong.

So that means you know that this input output equivalence hold and I'm okay. As an attacker I need to see just this input and things just get disrupted. So as a defender if I miss even that one single input I am doomed but if an attacker is powerful enough so because if the attacker has a lot of power and colludes with the multiple malicious actor and gets one exploitable bug then you are done and that might not be even covered using the set of tests that you are running because we don't even know what are the set of bugs that are increased. I showed you nine bugs I said that there are other bugs but certain set of bugs are not even attributed to the bytecode which is existing there.

Okay so that leads to a particular problem that how do we design this particular flow so that we can reconstruct it. but then I think this gives us the pitfall that is reconstruction even the answer not or it's again undecidable that whatever you reconstructed do you get equivalence across all the possibilities like functional equivalence. We get some bounded equivalence like bounded checks that okay this will work for certain cases and we say it is error free, but there are certain other aspects that we cannot cover. So I think this brings us to the next part of proving instead of hiding.

So that brings us to our final conclusion that why we need the ZK assurance. You don't make things public, so better to hide everything and then give a proof that your input output equivalence is holding and if you say that these bugs, if you say my particular source code is free of these bugs, just give an equivalence check that is it holding or not. So with this we progress to the last module of our talk and I hand it over to Sarbojit. Yeah, over to you Sarbojit. >> Many people have got bored with

with hearing hiding hiding or something like that. So now we come to a new topic. It may be interesting and here we will not hide at at as this is written, we'll do something else. What we want to do is a zero knowledge proof and here we can see here you can see we will create a proof. A proof means a mathematically mathematical random function. We'll create a proof and after it we'll validate that. So for that for that thing why we why we go through this to check the vulnerability? One thing we can we

we can sure that we cannot sure that the code is not vulnerable, but we can assure that this vulnerability is not in the code because because if we verify the proof, if we verify the verify the proof, we can be very sure that this function, which function is leading to vulnerability, that is not not present. That is a check. So this is the basic thing. And other thing to hide any if anybody wants to hide some assets or some API key by ZK, he want he can he can say that I will not publish the source code or bytecode. Who want to who want to transact with me, he will I will send him I will send him a proof and he

will verify that this proof is mine and he he will he can transact transact easily. So this is the main core agenda of our research and this research is ongoing and we have started just five months ago and yeah, it is written in proof is only as strong as its circuit, the setup and it's verified. This is the main line. The rest at this module. So going to the next slide. So publish it. Publish it is very lame idea and it is under attack. So already people are people removed their idea to publish the source code. So 95% of the published code is bytecode and

without this we can obfuscate as the previous module. Our speakers told that of how obfuscation can happen in the basis of bytecode or the source code. Now prove is a property. So as I told that how the proving is work, anyone can check and anyone can check means he or she should have the key or should have the mathematical circuit so that he can verify he or she can verify. So obfuscation blinds the auditor.

Obviously nobody can audit. That is a very like some strings will it will look like some strings. So nobody can audit it. So attack probability of attack probability of attack is very less. Yeah, here is the our our assumption circuit till now but our research is ongoing. So here you can see a source code, a bytecode, bytecode there is a bytecode will be converted to a key with a mathematical circuit. The formula is written and then then you can see the somebody is verifying that proof and after that if the proof is verified then it is pass.

You never publish the source and you publish a proof about it. That is the that is the logic and this is the diagram you can see and this is a very very visible and neat and clear diagram as of now. Yeah. So writing a ZK circuit is a very difficult work very in few years ago but now nobody writes in a handwritten way. It is designed in a computer based way and write in a checker or Jay Shekhar in and you can see the equations also. So now it is in 40 time faster and less than 12 12 second because when you are doing these without

these ZK proving it takes time. So you have to minimize the time taking because in blockchain there is every everything in my minting the the block or everything it is time based and it has some timelines. So proving these things or these these certain ZK proof it will be it should have a less time consuming. So that's why now the now in these modern method it is less time consuming and we can see that okay going to the next slide. Yeah prove a class of absence what what I am telling in previous that no bugs you I cannot prove that there is no bug but I cannot prove that these bugs like the certain bugs suppose X it is not

present. We can be assured of it. So that is that is the thing we can we can I am sure about it that if these proofs suppose this is the reentrancy and this function is a [clears throat] suppose the fallback function this is creating reentrancy. So some proofs should be there which I can verify and this if the the the proof through the proof the code is passed, that means that there is no reentrancy is there. Like that this evaluation evaluation goes and yeah, there is an easy exercise as as we are providing this time types of thing through whole through the throughout our whole presentation. And

here you can see this is a very easy exercise and developer hands you this proof and what you have actually been told. Easy option is there and this is this will be option option C is correct because this is an artifact and two more need extra bindings to never fellow. So this is only option four option B will be correct. So yeah. Here is the statement written out in full also case step one step three and step one step two and step three.

So what must what what should be there? So in in 2D docs it may be we can say that the reentrancy thing we can just found no reentrancy. That means that proof is proof the check or the proof is such a thing the code is passed. So slither in slither detections more than this is much better than detecting through a smart bug tool. The smart bug tool is like slither, but slither takes time takes some takes some times and for if the code is much bigger then slither will take much more time. But here we can collect a collect a function which functions can

cause reentrancy and we generate a proof. And if that those functions is not not passing the proof then then then that means those function has reentrancy and code is code is carrying vulnerabilities. [snorts] Yeah. So this is one thing. Before we go further, what are you now trusting? Yeah, we can anybody say to us what you are trusting now? ZK or this kind of proof giving or the traditional my field tool. Anybody?

Okay, no problem. As of now, we can say that ZK is ZK seems much cool, isn't it? So we are giving a proof. If that proof is verified, the proof is a mathematical equation or an output and the proof is verified, then there should not be vulnerability. But if this is the problem that it is a time consuming and time I'm in terms of money, it is very cost it is not very cost effective. This is one problem. So going to the next slide. Yeah. Circuit and proof system is a part of cryptography and so cryptographically you have to write this general write this circuit and then we have to we have to check the solidity. This is

the post these other tools a portion of solidity. But design designing a circuit is solely the part of cryptography and so we are working on this how to design a circuit. So a ZK system has four layers then the four layers is mentioned as you can see here. [snorts] Yeah, some equations is there. So mathematically something is written and it is like before the demo, the whole bug isn't isn't is one arrow that is written here and like the proof is only as strong as the constraint and proof is basically constraint means these these things if suppose there is a four

constraint X, Y, Z. These X, Y, Z should be should be passed by the code. Otherwise, there will be vulnerability called reentrancy. So these are some constraints that has written written in the mathematical way. Yeah, this is a video and demo to four things zero knowledge proof of something false. Yeah, you can see a demo where if the proof if somebody is failing to pass the proof, then that code is carrying vulnerability. And [snorts] this is the demo. The lie here is the what is the lie that is written and some circuit and same key some key is written. The verifier is the verifier is fine. That's why a demo circuit is video is attached here and

you can see. Yeah, demo two that is another demo. So we have pushing this we is pushing this demo to you because we don't have a sufficient research data set because in our field data set is much more necessary. So we currently lacking of data set. So we are pushing this kind of demo to you and a research is going on and you can see these things and these stocks being hypothetical. Yeah, this still now as I I told it is written that these top being hypothetical in March 2026 and the first is here 2.9 thing the second is 2.26 million and the cause and here the pattern is written.

You can in the small boxes you can see. Yeah. Some tools these these are very fascinating things. Some some company like some company uses till now started using these things like ZK PoX and ZK Foz. You can you can go through the names in here. These company has very recently started to use ZK for their work and privacy pools for privacy privacy pools. Going to the next slide. Yeah, here is some whole some points five points would like to help with the certified completion.

Okay. So we have to assure that the algorithm we are using for ZK things or ZK proof, it should complete by time. It should not be like a never ending process because then the algorithm will fail and will not get will not get any result because it is not like LLM or anything else. It is it is fully we should be deterministic. LLM can work in a probabilistic way, but here it is deterministic way. So here is some here is some patch like starting without ZK as I binding without ZK as I told you without ZK what will happen and with ZK what will happen. And these are the some five patches which will

help you and us to study more and more. If you remember the thing yeah that is that is if you remember the thing now the arrow will tell you what we have going through in this whole session from the first to till now that is in this arrow that is mentioned every total here cuts in the both way. So everything what we have told like or hiding or decoding through or using LLM nothing is fully proven like we are using this and we'll get this nothing nothing like that. Everything is under research and still now for this reason attack is still going on and you can see in the websites or the journal that how much millions of millions of dollars has

been lost till now in cryptocurrency. Okay. This is from our end. Any questions? Thank you. Thank you for attending this session and bear with us. Any questions? [applause] Okay. Okay. Thank you. Thank you so much. >> Anyone have any questions to the researchers? >> [music]