Sentryx

We can make sure your smart contracts are safe and secure for deployment. All you need to do is reach out and let us know.

[flacko @flack00n]

Yesterday @aviggiano hosted a live CTF with a $5k bounty up for grabs. The CTF was a Safe wallet with a custom Guard which had only certain targets and actions whitelisted.

I got curious about the solutions so I summarized them in an article.

https://t.co/Hvgsi8O9lR

[flacko @flack00n]

Managed to put our team in the top 5 spot this time🫡

My solo finding has an interesting story around it that I'll share very soon, stay tuned in!

[Sentryx @sentryxsec]

Improvise. Adapt. Overcome.

Two months ago we had a hunch more Go audits are about to pop up🔮 Turns out we were right🤷‍♂️

https://t.co/dUDwENsNmk

[flacko @flack00n]

Learning Go and Cosmos SDK seems to be one of the better decisions I've made in my auditing journey so far.

Had 10 days to prepare and 3 weeks to hunt. It was a first timer for me and I'm extremely happy with the result.

Also it's my first five digits reward from a competition.

[Sentryx @sentryxsec]

@Undisputed_Win @flack00n @cantinaxyz Appreciate you asking out! We are currently not looking to expand our team, unfortunately.

[flacko @flack00n]

Is the pot going to be conditional? – Probably, yeah🤷‍♂️

Do I support conditional pots? – Not really a fan 😒

Am I going to try breaking another Cosmos SDK application? – Abso-fckn-lutely🤠

[flacko @flack00n]

First competition on @cantinaxyz as part of team @sentryxsec.

The codebase was extremely vague to reason about from my POV and it was first of its kind that we've encountered so I didn't expect much out of all that.

Still, we managed to find 1 / 4 mediums so we'll take that🏆

[Sentryx @sentryxsec]

The report with our findings is available in our portfolio on GitHub:
https://t.co/BxU0kIo77Z

Go and check it out! The solo medium vulnerability we managed to find was quite well hidden.

[Sentryx @sentryxsec]

We've managed to find 1 of the 8 solo issues in the @FlayerApp Contest on @sherlockdefi along with 3 other High severity issues.

Due to technicalities we couldn't cover the entire codebase within the timeframe of the audit and this will be the last time you hear this from us🫡.

[Sentryx @sentryxsec]

@S7w74_rllMb91d_ @FlayerApp @sherlockdefi 🙌

[Sentryx @sentryxsec]

@MartinMarchev @FlayerApp @sherlockdefi Thank you!💪

[Sentryx @sentryxsec]

@jack__sanford @FlayerApp @sherlockdefi Our solo is a medium, ser, but we believe it's still an impressive one 🫡 Next time we'll deliver a solo high.

[Sentryx @sentryxsec]

@zarkk01 @FlayerApp @sherlockdefi Appreciate it, man! Congrats for your result too!

[flacko @flack00n]

While digging through an article about gas on Ethereum and more specifically the 63/64 gas rule I had a hard time making sense of this safety check in the code that the article suggests.

If you had a hard time understanding the inequality like me this thread is for you🧶

[Sentryx @sentryxsec]

Give us a follow if you found this helpful! 🛠️

And if you are a protocol looking to get an audit don't hesitate do contact us!

[Sentryx @sentryxsec]

💡VS Code Smart Contract Navigation Pro Tip!

You can easily navigate between identifiers (functions, variables, struct fields, etc.) in a given contract by pressing `⌘/Ctrl + Shift ⇧ + o` and searching for the one you want.

(⌘ - on Mac, Ctrl - on Windows/Linux)

[Sentryx @sentryxsec]

That functionality is called "Go to Symbol" and can easily take you to the definition of a symbol that's on the other end of the contract you are reviewing.

To use it you only need to install the Solidity extension by @NomicFoundation👇
https://t.co/Q2nGON8h4f

[Sentryx @sentryxsec]

Sentryx's recent audits and research happen to revolve around Ethereum infrastructure.

Which made us think:

"Is it just us or focus in crypto development and security has actually been shifting from smart contracts towards infrastructure lately?🤔"

What do you think?

[Uniswap @Uniswap]

Introducing @unichain — a new L2 designed for DeFi ✨

Fast blocks (250ms), cross-chain interoperability, and a decentralized validator network

Built to be the home for liquidity across chains

[Sentryx @sentryxsec]

@HalbornSecurity That's a good summary👏
One of our security researchers wrote a short explainer on EIP-3607 a month ago, which can shed more light on the "Contract Frontrunning" security implication when CREATE2 is used for deployment.
https://t.co/DMXEmAaAdY

[Sentryx @sentryxsec]

@HalbornSecurity That's a good summary👏
One of our security researchers wrote a short explainer on EIP-3607 a month ago, which can shed more light on the "Contract Frontrunning" security implication when CREATE2 is used for deployment.
https://t.co/DMXEmAaAdY

[flacko @flack00n]

Have you heard of EIP-3607 👀?
It suggests introducing a security check to Ethereum clients that reject transactions from senders with deployed code.
If you want to know why this is actually important – keep on reading 👇

A short background:
Due to ethereum addresses being only 160 bits long, there are possible collision attacks (at a significant cost of course) where an attacker can generate keys for 2^80 EOAs and simulate the deployment of 2^80 contracts from these EOAs and find a collision where an EOA has the same address as one contract.

What does that mean?
Well, it means that prior to this EIP if you had a contract (a router of an AMM or a liquidity pool for example) and people had given it infinite allowances for various numbers of tokens, an attacker could've generated themselves a key which would've had the same address as the contract with the allowances. This would've allowed the attacker to drain all funds since they would've been able to sign transactions on behalf of that contract.

How does the EIP fix it?
From this EIP onwards, Ethereum clients are expected to reject transactions where `tx.sender` has any code deployed. This means that their codehash must be empty or the transaction would be rejected otherwise. This, however, doesn't eliminate all possible attack vectors. The EIP (https://t.co/X7pCPuJcep) outlines some of them, but one stands out:

"1. An attacker can convince a user to send funds to an account before it is deployed..."

Sounds familiar, doesn't it?
Yes, you guessed it correctly. The famous collision attack issue submitted by 0x52 in the KyberSwap contest on Sherlock from last year – https://t.co/32lInCjQPJ. Long story short, the issue is viable because the router never verifies that `msg.sender` is actually a deployed pool (as the `_getPool` function states too) and thus leaves room for an attacker with a generated private key for the same address to come in and drain the funds before a pool is actually deployed at that address.

This EIP has been introduced a bit over 3 years ago and only a month after its creation it was implemented in the geth client. The commit introducing the security check can be seen here – https://t.co/HN18CLLmw6.