New Ethereum talks, every Monday. The week's conference uploads by event, in your inbox.

Loading player…

The Unseen Threat: Why Attackers See What Developers Miss | Bartosz Barwikowski - Hacken

Ethereum DenverThu, Oct 9, 2025, 12:00 AM

The main idea of this speech is to share some insights from Bartosz's experience and showcase the scenarios where a developer most likely can make a mistake. 🚀 Get Ready for ETHDenver 2025! 🚀 We're already hard at work preparing for next year's biggest Web3 event! Keep your eyes peeled for more info on ETHDenver 2025—it’s going to be epic! 🌟

Transcript

[Music] hey everyone today I will be speaking about the Unseen threat why attackers see what developer Miss I'm going to speaking for my own experience because I work in cyber security for quite a lot yep and of course yeah it works so yeah I started hacking 15 years ago it started very early you know I was the first kid to get banned during the high school during the it class when I tried to hack the other people uh with Koger so it started very early also I joined uh web Tre in 2013 when you know the Bitcoin was was was still growing up now I remember I had 200 Bitcoins back then it still hurts so yeah for the last three years I work for haken is the cyber security company I found around 70 critical issues and I also found a lot of issues in back Bounty programs so yeah the hacken itself is the cyber security company web Tre cyber security company we do almost everything AIT pant tasting proof of reserves we work with the big clients I even managed to find an issue for binance but let's let's finish on that and let's think how hackers think to be honest I'm only telling from my own experience but I think it all starts with curiosity just a simple question how the things work what will happen if I change something can I somehow bypass the Restriction you know the same story when I was kid I was the one who was disassembling the toys to see how they work the cloaks or some other stuff because it was more interesting than than the to itself to create something better from it was more interesting than just the toy itself and I really love that so you know I would like to show you how I think when I start working with the projects when I start the audit when I do some back Bounty I will show you 10 places my top 10 and general patterns where I search for the issues it's mostly from my own experience I don't know if everybody other hackers work the same but good luck with making a general R ranking so this is my private one okay let's start with number 10 it's the code ported from another platforms or languages yeah so in many cases when we have a project for example in solidity and the team is starting to moving it to Solana or sui Aptos they try to copy everything they have because the product is already audited and uh it works it works so far so let's just copy it but it's not so simple because there is a lot of platform specific behavior so if they have developers who don't have really an experience with other platform they just want to Port it because they think it's easy it's a very big trap and a lot of companies fall for it recently I was working on such project and they were porting from from rust to move to movement and you know it should be almost the same but they made two critical mistakes in their project yeah so they made an issue with filtering data at the bottom is the example so in the OR original code it was Oracle project in the original code they were parsing data for every Oracle every feed they had and it worked and it worked correctly it was taking the time stamp of the first uh package and then it was verifying that time stamp for all other feeds packages is the same but when they ported this code to movement they decided to do an optimization and they added option to filter data to receive only data for given feed from the same signate data and of course they made made a mistake because later when they verified this data they verified only filter data so all the other data which was in the package for the other feds was not validated at all but later in the same code part of this unverified data was used to calculate the time stamp it allowed to move time stamp into the future for an oracle pretty big issue the other very interesting issue I had uh was when code was ported from 64bit platform to 32bit platform so you know right now almost all the code runs in 64 bits but there's very rare case which is web assembly which uses usually 32 bits and by doing that they assume that nothing can go wrong but it did because the change that the size of U size changed for from four from eight to four bytes and it introduce overflow and it was possible to manipulate the signature verification okay next category nine code using algorithms I really love algorith algorithms algorithms because uh before starting my cyber security career I work a lot with optimizations uh games algorithms so I have a lot of experience in this so I always check how the developers use the algorithms even the simple one like sorting like fighting median median or some mathematical calculation do they they know about the complexity or not are they handling edge cases correctly because uh the interesting fact is that actually there's a lot of developers who don't really have experience with algorithms or the only thing they have like maybe sometimes they don't even know what's the difference between stable and unstable sorting but if they don't know that don't don't know that they can introduce some issues in the projects and I will show you one issue like this this one is very very very stupid but I got 50k back Bounty for it so uh it should be interesting and the issue was that one project it was layer one project used base 58 instead of Base 64 to encode the data when you know emitted events for example or some logs Etc they were using base 58 and you know there's not much difference there's only four characters difference when it comes to base 58 and coding but there's one hidden problem which costed them 50k and it's complexity base 58 has n squ complexity so the thing is if you start feeding it with a lot of data the computations will take a lot of time minutes sometimes even hours and base 64 don't have this problem so yeah simple mistake and someone was would and and a potential attacker would be able to take down the entire network just by sending a huge transactions with base 58 so yeah a stupid mistake but it happens I was interested if AI would be able to find out this mistake because right now we're having a lot of uh tools AI based to se for mistakes I asked CH gpt1 Pro yeah I subscribe uh if it's safe to use base 58 it said it is safe okay so I asked it okay in this structure which they had in their project it was used for emitting events and serialization of data is it still safe it said Yes again so I asked it even more directly what are the risk involved with base 58 and it didn't know so for me that's a good thing it means I can still keep my job for maybe few years okay next thing number eight code on which multiple developers work together this is hard to show in a practical example and it would be a little unfair but the thing is when I'm checking the code sometimes the difference between code quality is very visible I can see that there's one experienced developer the lead who's taking who create amazing code but he has like two others who make mistakes and sometimes just by following the other developers those who make mistakes it's very possible to find the issue because yeah because focusing on the weakest point is the best idea and sometimes the developer can be this weak weakest Point okay next thing recently updated code especially old code so let's say we have some big project it has a lot of Legacy code and and they want to introduce a new feature and to do that they need to change something in the old code and the problem is when they do that sometimes this old code changes Behavior or some other code which was used for something else like in many cases the updates like this are being done in rush and it's from my experience it's quite usual to make mistake especially when changing something in Old code so have a lot of tests okay next thing code integrating with third party components okay the problem with this is that usually the developers don't assume how to handle the situation if something goes wrong so okay what what should what should we do if Oracle starts to returning wrong data or if it has some danial of service and don't work correctly there are or even or even worse what if this third party will want

Automatic transcript — names and jargon may be misspelled.