MultiversX Tracker is Live!

SafeMoon clones can fake renounced ownership and there is no way for an investor to tell if that has happened.

All Cryptocurrencies

by COINS NEWS 508 Views

SafeMoon clones can fake renounced ownership and there is no way for an investor to tell if that has happened.

Note: u/Spring_Greedy discovered this renounced ownership back door. I'm posting for him due to karma limits on this sub. Please direct questions / conversation his way. External URL here.

SafeMoon clones have the ability to fake renounced ownership and there is no way for an investor to tell if that has happened.

https://preview.redd.it/kgxrz3pmroy61.png?1366&format=png&auto=webp&s=d1cdf8f26e8d71ce09135702b7ef5e1e35f636e5

Renouncing ownership is achieved by setting the owner address to 0 (the dead address). The value of doing this is debatable, but people like it because it means the creator can’t manually drain liquidity or change the contract. It is considered a feature of a safe, non-scam project and is often a primary selling point.

I am honestly shocked that I haven’t seen any discussion of this, especially with so many of these tokens passing first class audits but here’s the deal:

SafeMoon’s contract code has a very clear potential backdoor in it for tokens advertising renounced ownership.

The code that achieves this looks like this:

function renounceOwnership() public virtual onlyOwner {

emit OwnershipTransferred(_owner, address(0));

_owner = address(0);

}

That example is directly from the SafeMoon code. Nothing wrong with it, it does exactly what it is supposed to do. Owner is now set to 0 and the creator can no longer make changes or call any functions that are OwnerOnly.

The problem is, there are also two other functions in that section of the contract code: lock and unlock

//Locks the contract for owner for the amount of time provided

function lock(uint256 time) public virtual onlyOwner {

_previousOwner = _owner;

_owner = address(0);

_lockTime = now + time;

emit OwnershipTransferred(_owner, address(0));

}

//Unlocks the contract for owner when _lockTime is exceeds

function unlock() public virtual {

require(_previousOwner == msg.sender, “You don’t have permission to unlock”);

require(now > _lockTime , “Contract is locked until 7 days”);

emit OwnershipTransferred(_owner, _previousOwner);

_owner = _previousOwner;

}

In theory, these could be used for a legitimate reason; locking ownership for a specified period of time before restoring it to make changes with community knowledge. But here’s the problem, I have not personally seen that use case even once but what I have seen is countless SafeMoon clones (and forks) that have this code and are advertising “Renounced Ownership” as a selling point and demonstrating that the owner address is indeed set to 0.

This might be entirely innocent in some cases, and if the creator (“dev”) didn’t call the lock function, then the _previousOwner variable would be empty and the flaw is harmless.

The real problem is there is no way for an investor to tell the difference!

this will look the same even if _previousOwner is set

While the _lockTimer variable is publicly viewable, the _previousOwner variable is not.

unlock time is readable, but will be 0 by default

This means that when looking at a token that advertises renounced ownership, there is no way to tell if they called the lock function or the renounceOwnership function, and since _lockTimer defaults to 0, this means that they can reclaim ownership at any moment after launch to drain the liquidity pool or make any other changes that might result in a rugpull or honeypot situation and to the outside observer the token contract would look the same as one where ownership was actually renounced!

From a pure software development standpoint, I can understand companies like Techrate passing this code in audit since in theory it could have valid uses, but in the context of actual applications, with many of these tokens advertising Renounced Ownership as a major feature, this is honestly a pretty big failing in open reporting and scam prevention. It is also a pretty big flaw in the SafeMoon contract code in the context of it being used as one of the most popular contract templates. A simple fix would be to (at the very least) make _previousOwner publicly readable but quite frankly it should just be removed by default and restored in the rare use-case that it actually applies to.

Thanks for reading, and please send me feedback!

I’m also happy to answer any questions if you want to ping me on Telegram: u/cailenfisher

submitted by /u/KromaticMedia
[link] [comments]

Get BONUS $200 for FREE!

You can get bonuses upto $100 FREE BONUS when you:
💰 Install these recommended apps:
💲 SocialGood - 100% Crypto Back on Everyday Shopping
💲 xPortal - The DeFi For The Next Billion
💲 CryptoTab Browser - Lightweight, fast, and ready to mine!
💰 Register on these recommended exchanges:
🟡 Binance🟡 Bitfinex🟡 Bitmart🟡 Bittrex🟡 Bitget
🟡 CoinEx🟡 Crypto.com🟡 Gate.io🟡 Huobi🟡 Kucoin.



Comments