15-11-25, 04:34 PM
Hacking Smart Contracts are a thing nowadays but its a broad topic, but let me run you down with the basic.
If you are into these kinds of hacking which we all know and the world knows are the source of the entire riches of those hackers (yes they attack smart contracts of those ico/ipo) and new tokens.
Here's a clear general explanation. Let's start with a few basics.
---
What is Reentrancy?
Reentrancy s one of the most famous smart-contract vulnerabilities (e.g., it caused the 2016 DAO hack).
It happens when:
1. Contract A calls Contract B (or an external address).
2. Contract B calls back into Contract A before the first call finishes.
3. Contract A wasn’t expecting that second call and might do something unsafe (like sending funds again).
Analogy:
You give someone access to your house to borrow one item. Instead, they walk back in repeatedly before you finish locking the door.
Example (simplified)
If `msg.sender` is a contract with a fallback function, it can re-enter `withdraw()` before the balance is set to zero.
---
What is `delegatecall`?
`delegatecall` is a low-level Solidity instruction. When Contract A calls Contract B using `delegatecall`:
It runs **Contract B’s code but in Contract A’s storage , using Contract A’s state , and msg.sender stays the same
This is commonly used in proxy patterns (upgradeable contracts).
Why it’s dangerous
If the developer isn’t careful, Contract B can:
* overwrite storage in Contract A
* access admin variables
* hijack control flow
* drain funds
It’s like letting a stranger into your house and giving them the keys to rearrange your furniture—because their actions affect your state.
---
What do I mean discussing these together?
When someone mentions reentrancy / delegatecall , it usually mean:
* These are dangerous low-level behaviors that developers must understand.
* Both can lead to unexpected flows of control.
* Both can cause catastrophic security vulnerabilities if used incorrectly.
A typical point is:
> “Smart contracts are tricky because functions like `call()`, `delegatecall()`, and fallback functions allow unexpected execution paths (reentrancy) that new developers don’t anticipate.”
Often the poster is warning that these mechanisms:
* break the “simple mental model” of code running line-by-line
* allow execution to jump into other contracts mid-function
* require defensive programming (checks-effects-interactions, reentrancy guards, careful storage layout)
Now these are simply yet very useful specially to those who are into cryptography and hacking smart contracts.
In the past, I helped a lot of people recover their crypto from those typical "dashboard" scams, (yeah they've been around for quite sometime now) that preys on vulnerable minds, specially those old folks and retired individuals who relies on their pension and wants to earn some money and bit the promise of new crypto in the scene.
Feel free to dm me or email me at rajesh@dnmx.cc
Thank You!
If you are into these kinds of hacking which we all know and the world knows are the source of the entire riches of those hackers (yes they attack smart contracts of those ico/ipo) and new tokens.
Here's a clear general explanation. Let's start with a few basics.
---
What is Reentrancy?
Reentrancy s one of the most famous smart-contract vulnerabilities (e.g., it caused the 2016 DAO hack).
It happens when:
1. Contract A calls Contract B (or an external address).
2. Contract B calls back into Contract A before the first call finishes.
3. Contract A wasn’t expecting that second call and might do something unsafe (like sending funds again).
Analogy:
You give someone access to your house to borrow one item. Instead, they walk back in repeatedly before you finish locking the door.
Example (simplified)
Code:
solidity
function withdraw() public {
require(balances[msg.sender] > 0);
msg.sender.call{value: balances[msg.sender]}("");
balances[msg.sender] = 0; // too late -- attacker already re-entered!
}If `msg.sender` is a contract with a fallback function, it can re-enter `withdraw()` before the balance is set to zero.
---
What is `delegatecall`?
`delegatecall` is a low-level Solidity instruction. When Contract A calls Contract B using `delegatecall`:
It runs **Contract B’s code but in Contract A’s storage , using Contract A’s state , and msg.sender stays the same
This is commonly used in proxy patterns (upgradeable contracts).
Why it’s dangerous
If the developer isn’t careful, Contract B can:
* overwrite storage in Contract A
* access admin variables
* hijack control flow
* drain funds
It’s like letting a stranger into your house and giving them the keys to rearrange your furniture—because their actions affect your state.
---
What do I mean discussing these together?
When someone mentions reentrancy / delegatecall , it usually mean:
* These are dangerous low-level behaviors that developers must understand.
* Both can lead to unexpected flows of control.
* Both can cause catastrophic security vulnerabilities if used incorrectly.
A typical point is:
> “Smart contracts are tricky because functions like `call()`, `delegatecall()`, and fallback functions allow unexpected execution paths (reentrancy) that new developers don’t anticipate.”
Often the poster is warning that these mechanisms:
* break the “simple mental model” of code running line-by-line
* allow execution to jump into other contracts mid-function
* require defensive programming (checks-effects-interactions, reentrancy guards, careful storage layout)
Now these are simply yet very useful specially to those who are into cryptography and hacking smart contracts.
In the past, I helped a lot of people recover their crypto from those typical "dashboard" scams, (yeah they've been around for quite sometime now) that preys on vulnerable minds, specially those old folks and retired individuals who relies on their pension and wants to earn some money and bit the promise of new crypto in the scene.
Feel free to dm me or email me at rajesh@dnmx.cc
Thank You!