Crypto and Hacking — Black Hat Nightmares

Crypto is often portrayed as a castle of cryptography, decentralized consensus and immutable ledgers. But the truth of this digital promised land is much more complicated, and more dangerous. Mainstream media talks about hacking the crypto space usually via social engineering or phishing campaigns, or simply scams where someone makes an unsuspecting user type an exchange address or his private key on a malicious site.

But this article will ignore entirely those human based failures. In this article, we will talk about pure hacking. This is the land of broken cybersecurity and deeply flawed code that results in horrible breaches. These are the black hat dreams where the code is weaponised against its creators, draining hundreds of millions of dollars in minutes without so much as firing a shot; forcing us to the extremes of logical fallibility, compiler bugs and architectural oversight.

Where Smart Contract Exploits Originate

Pure smart contract hacking requires an explanation to begin — one of the most notorious cases at the time in DeFi history, which shifted the course of Ethereum forever. Back in the day of early programmable blockchains, there was a project called The DAO. The fund was intended to be a kind of decentralized venture capital fund managed totally by smart contracts — no humans.

The contract had attracted millions of dollars worth of Ether from investors hoping to vote on proposals and earn rewards. However, the developers have not implemented the process of withdrawing in a secure way, which is a bug called reentrancy.

Reentrancy — A smart contract calls an external contract but does not update its internal state. For example — in The DAO the withdrawal function first transferred the requested funds to the user and only then updated the user state with the withdrawn amount. Black hat hacker realizes they can also deploy a malicious smart contract with a fallback function.

The fallback function is invoked whenever The DAO sent money to this evil contract. The fallback function did not just accept the funds, it called The DAO's withdrawal function again right away. This triggered the fallback function once more, which The DAO executed, as the balance for the hacker had not been previously updated at the time of the first withdrawal.

Over and over again, this process repeated, extracting millions of dollars from The DAO before the network was able to respond.

Fallout and the Hard Fork

The fallout from this hack has been unlike anything we have seen before. The network was in danger of collapsing; and a large percentage of all the Ether that existed was stolen. This created an existential and technical crisis for the community, which eventually resulted in the community implementing the hard fork to roll back the history of the blockchain and return the funds.

This controversial decision caused a permanent schism, leading to Ethereum and Ethereum Classic. This particular vulnerability is today well-known and mostly mitigated with the use of the Checks-Effects-Interactions pattern. This pattern states that a contract first has to validate all conditions, only then will it be able to update its internal state, and it must only call external contracts in the very last stage.

However, although basic reentrancy is now very easily detected by automated auditing tools, subtle, cross-contract reentrancy attacks can still take place under very particular, niche, occasions, showing that even hardened concepts can metamorphosise into fresh attacks.

Uninitialized Logic and Delegate Calls Era

The lessons learned from The DAO were quickly absorbed by the developer community, which has since developed systems with ever-greater complexity, and which tied themselves to concepts such as library contracts and proxy patterns to save on gas and to provide an easier path to upgradability. Within this complexity came an additional vector of pure hacking, with the most notorious example of this being the Parity Multi-Sig Wallet vulnerabilities.

Parity is a widely used Ethereum client and offered a smart contract for a multi-signature wallet that had its core logic in a central library contract. This was intended to be resource efficient, since many wallets would be able to point to the same library instead of deploying the same code multiple times.

The class of the vulnerability was due to misunderstanding the delegatecall function and uninitialized state variables. The delegatecall function enables a contract to execute a function from another contract but gives that function access to the calling contract's storage. Within the Parity library contract was a function to initialize the owners of the wallet.

But the library contract itself was never actually initialized. A hacker figured out they could call the initialization function directly on the library contract, and claim to be the owner of the library. After gaining ownership of the library, they invoked a function to self-destruct it.

Freezing of Multi-Sig Wallets

The multi-sig wallets that depended on that library were immediately rendered dysfunctional when the library was destroyed. All the logic that was required to handle a transaction or let someone withdraw money, or even just to query your balance, was just lost. Over the course of this process, due to a pure architectural mistake, hundreds of millions of dollars in Ether were not stolen, but instead physically frozen.

It brought to light the extreme danger of uninitialized logic contracts and the subtle risks associated with delegatecall functions — a set of risks that seems common knowledge today, but were not as well understood at the time. In order to patch this, developers now rely on special initialization modifiers that enforce that a contract can only be initialized once and they frequently place dummy values in the deployer's logic contract state so that no one can claim payment.

Though the same exact situation is unlikely today, the general risk of mismanaging a proxy pattern is still something that should be considered carefully in any decent decentralized finance architecture.

Cryptographic Mirage of Cross-Chain Bridges

With the spread of the crypto ecosystem to more than one blockchain, there was a demand for interoperability, which manifested in the different kinds of cross-chain bridges. These protocols allow assets to be locked on a chain and mint their representation on the other chain. Due to the sheer volume of assets held by them, they were honey pots of dreams for black hat hackers.

The Wormhole bridge exploit is a truly terrifying reminder of how one minor detail left out in implementation can cause complex cryptographic verification to simply fail. Wormhole permitted the transfer of assets in between Solana and Ethereum. This would entail a group of guardians watching an event on one chain and signing a message to prove it. These signatures would then be verified by the target chain before minting said tokens as new ones.

The weakness was in the signature verification in the Solana smart contract. The cryptographic verification was done by a built-in Solana program called by the contract. But Wormhole developers did not check that the program being called was the actual system program. The hacker also created a program that always returned a success message, regardless of what the input was.

Next, the Wormhole contract was told to use this fake app for validation. Under the false assumption that the signatures were indeed valid, the contract went ahead and minted hundreds of millions of dollars worth of wrapped Ethereum on Solana with zero Ethereum actually being locked on the other side. The hacker then wrapped these newly minted, unbacked tokens back to Ethereum, emptying the protocol of its real assets.

It was a clean and highly technical execution against the Solana account validation model. This was fixed with stricter validation to check that the verification shell is indeed the hardcoded, official system address. The repercussions were huge, needing a bailout from the backers of the project in order to prevent a systemic collapse of the Solana DeFi ecosystem.

Such a vulnerability could recur in the future due to unique characteristics of the smart contract development paradigm, especially in account-model-heavy environments like Solana, if developers do not perform rigorous account and program validation and verification for every external entity invoked within their smart contracts.

The Nomad Bridge Exploit

As Wormhole was a coordinated attack in a specific direction, the Nomad bridge exploit proved how easy it is for one simple logic flaw to leave a protocol filled with chaos like a classless free-for-all. To implement this cross-chain messaging, Nomad used a model of optimistic rollup that relied on a Merkle tree to show that message was valid. The developers made a key mistake on the initialization of the trusted root when deploying an update to the protocol.

This happens because they set the trusted root to zero hash — the default value for an uninitialized variable in solidity. That caused any message that was not explicitly validated to fall back to a zero hash, which was now considered a valid trusted root by the contract. Essentially, a hacker realised that he could create a transaction that asked the contract to withdraw funds, and because the proof hashed to the zero hash, the contract would always accept it.

This hack was unique because of its simplicity and the mad chaos that ensued. After the initial hacker performed the exploit, other users got in on the act. No technical hacking ability was required, it was simply copying and pasting the hacker's transaction information, changing the destination address to their own and posting it to the network. Hundreds of different actors drained the Nomad bridge of close to two hundred million dollars in the space of hours.

It was a textbook cybersecurity failure: one line of misconfigured initialization code that circumvented the entire cryptographic security system. This was mitigated by patching the zero root initialization logic and rejecting it explicitly as a valid root. The users of the bridge paid the price, and this was a harsh reminder that when developing smart contracts, a missing character or mistaken default value can effectively jeopardize an entire protocol.

This particular bug is a no-brainer to avoid with diligent testing, yet the larger class of initialization errors still actively plagues systems.

Compiler Bugs and Market Manipulation

One of the most horrifying types of pure hack is where the fault is not in the developer code but in the tools it used to compile it. We were reminded of this during the Curve Finance exploit which sent tremors through the foundations of DeFi. A leading DEX for stablecoins, much of Curve's core contracts were written in Vyper, a Pythonic smart contract language that emphasizes security and simplicity.

Fortunately, the developers of Curve had implemented reentrancy guards in their smart contracts, defending them against this exact type of attack that had ravaged The DAO. But within one specific older version of the Vyper compiler that bug was buried. The compiler successfully translated the human-readable Vyper code into a machine-readable bytecode that is to be implemented on the Ethereum Virtual Machine, but it did not do a good job of spreading the reentrancy lock over multiple functions.

The code was secure, developers wrote it just like it was supposed to and the compiler turned around and stabbed them in the back, producing bytecode with vulnerabilities. This means that a black hat hacker noticed, and understood that some of the Curve liquidity pools are susceptible to cross-function reentrancy. They took advantage of this to take tens of millions of dollars from the pools.

This hack was especially insidious because there would have been no way to catch that with traditional source code auditing; the source code was correct. The vulnerability was present only in the compiled bytecode. This event compelled the whole industry to reconsider their faith in compilers and infrastructure. The issue has been addressed by updating the Vyper compiler and migrating vulnerable pools to new, safely compiled contracts.

The result was a major confidence crisis and a recognition that security has to reach all the way down through the stack of technology. Compiler bugs are rare, of course, but also near impossible to foresee, so such a nightmare at an infrastructure-level could easily strike again.

Flash loans — a new breed of financial instrument, which emerged with the development of decentralized finance, fundamentally transformed the nature of pure hacking. Flash loans enable a user to take out a nearly limitless amount of crypto without collateral, as long as the loan is paid back before that same transaction completes. In case the money is not settled, the whole transaction is reversed — as if it has not even taken place.

Flash loans, usually intended for arbitrage or liquidations, provided black hat hackers the necessary liquidity to exploit deep logical flaws in the mechanics of the market. Using the Euler Finance hack as a case study, Euler was a lending protocol for making deposits and profits. Users could also have their deposited assets donated to the protocol reserves, a function called donateToReserves in the protocol.

But the developers missed a very important health check in that one function. Neither did they check whether the account from which the donor withdrew money would remain in the balance after the donation. The attacker borrowed a large amount of assets from a flash loan and deposited it into Euler. Next, they called the donateToReserves function to donate part of their deposit.

Without the health check, the protocol approved the donation, driving the hacker account to the highly artificial stage of bankruptcy. The hacker subsequently carried out a liquidation of his account. However, the math behind Euler's liquidation bonuses is complex, and the flash loan was immensely large, so the liquidator ended up capturing more value from the protocol than they were depositing.

They returned the flash loan and scampered off with approximately two hundred million dollars. It wasn't a cryptographic failure or a compiler bug, but rather a plain failure of financial logic in the code. In this case, the developers just forgot to insert a single line of code that checked the health of the account post-some action. The patch consisted of providing the appropriate health check and completely reworking the risk management logic of the protocol.

This had severe repercussions, interrupting the protocol and taking months of negotiation to retrieve some of the capital. Such logical exploits where complex financial mechanisms react in unintended ways with each other represents the most prevalent and dangerous form of pure hacking today. The complexity of the protocol will increase, and this type of logical oversight will likely be virtually certain to repeat itself.

An Ongoing Struggle between Code and Consequence

If you look back at the historical events of these gigantic breaches, you will easily see a pattern. These vulnerabilities are rarely the result of a failure of underlying blockchain consensus mechanisms. No, they are failures of the human logic encoded into unchangeable code. Regardless of whether it is a state update gone wrong, an unwritten codepath for a proxy, a skipped cryptographic check, a compiler error, or an inexistent financial invariance check, the underlying problem is always a mistake in the design of the smart contract in the first place.

To eliminate these risks, the industry has a thorough defense system. These include:

1. Third party human code audits by independent security companies. 2. Formal verification tools that mathematically prove that the code runs exactly as planned. 3. Very large bug bounties that pay white hat hackers to find defects before the bad guys do. 4. Use of time release locks and multi-sig admin key controls to slow the deployment of a malicious update. 5. Using decentralized insurance protocols to provide coverage in the event a breach occurs.

However, black hat hacking still exists, even if these defensive measures have become more sophisticated. The starting point of software development is that complexity creates opportunities for failure. The rising complexity of decentralized finance, with developers building complex protocols integrating dozens of other smart contracts and functioning across multiple blockchains, creates new and unprecedented avenues for attack.

Since attackers are only limited by their own imagination, they only have to find one vector that works in order to succeed, the defense is always reacting and forever behind. This will be a perennial struggle forever where builders of the decentralized future spar with the exploiters of it. The nightmares of all-out hacking will continue to mutate as a constant reminder: in a world where code is law, one typo can take it all away.

With each line of code literally worth hundreds of thousands of dollars, just as important as security is efficiency and precision in day-to-day operations to ensure the highest level of performance. Users are regularly burdened with the friction of network costs when managing digital assets, especially stablecoins. Now, whenever you send USDT, if it is something you do often to transfer capital, you know that this USDT transaction cost can change quite a lot in terms of damaging your capital.

As an active participant in the ecosystem, finding a cheap transfer method for USDT is crucial. This is where specific tools allow you advantages. The netts service: USDT Transfer Calculator is created to boost exactly these apply. When you transfer Tether on the TRON network, it uses some Energy and Bandwidth from you, if you do not have any of them, the network will burn your TRX based on your USDT fees.

The Netts estimator which calculates exact Energy and Bandwidth needed beforehand means that users can save massively by renting energy instead of burning TRX, saving your assets as efficiently managed as possible in a land where every fraction of a token counts.