Mozart Finance Developer Exploit

Notice: This page is a freshly imported case study from the original repository. The original content was in a different format, and may not have relevant information for all sections. Please help restructure the content by moving information from the 'About' and 'General Prevention' sections to other sections, and add any missing information or sources you can find. If you are new here, please read General Tutorial on Wikis or Anatomy of a Case Study for help getting started.

Notice: This page contains sources which are not attributed to any text. The unattributed sources follow the initial description. Please assist by visiting each source, reviewing the content, and placing that reference next to any text it can be used to support. Feel free to add any information that you come across which isn't present already. Sources which don't contain any relevant information can be removed. Broken links can be replaced with versions from the Internet Archive. See General Tutorial on Wikis, Anatomy of a Case Study, and/or Citing Your Sources Guide for additional information. Thanks for your help!

Mozart Finance

Mozart Finance launched their yield farming project with a professional audit from ImmuneBytes. However, they apparently also hired an external developer who installed a backdoor so they could withdraw funds after the audit.

The project was relaunched and obtained an audit from Hacken instead. There were no further problems noted. The website appears to be down at the moment, though social media is still online.

This is a global/international case not involving a specific country.

About Mozart Finance

"Mozart Finance is a Binance Smart Chain defi project focused on yield farming and NFT's. Thе project developers are vеrу resilient іn making a platform whісh incorporates аll major applications оf DeFi lіkе yield farming, AMM, lotteries, betting, musical NFT's and much more. We expect that the platform will go big as time goes on."

"Mozart Finance is a fork from similar PancakeSwap and other Dex AMM DeFi projects. It aims to deliver DeFi features exclusively away from the traditional types. PIANO is the native token of the platform with the burn mechanisms embedded in its code to control inflation and a buy-back program to maintain the price."

"Low fees Using pancakeswap AMM while our is not finished trading fees are lower than other top decentralized exchanges too, so that's a double win for you!" "Trade directly from your wallet app (bsc wallet, metamask, trust wallet etc.) Unlike centralized exchanges like Binance or Coinbase, we don't hold your funds when you trade: you have 100% ownership of your own crypto. Do your own research!" "That's what we all are focused on. Musical NFT's are coming together with NFT's marketplace on BSC! Our roadmap will be updated shortly."

"According to the team, the last contract used on the test network was 100% secured; immunity Byte was paid to audit the code and was given a save rating." "ImmuneBytes team has performed thorough testing of the project starting with analyzing the code design patterns in which we reviewed the smart contract architecture to ensure it is structured and safe use of third-party smart contracts and libraries." "Our team then performed a formal line-by-line inspection of the Smart Contract in order to find any potential issues like Signature Replay Attacks, Unchecked External Calls, External Contract Referencing, Variable Shadowing, Race conditions, Transaction-ordering dependence, timestamp dependence, Dos attacks, and others."

"[A] project called Mozart finance that got hack by internal team. The developer left a backdoor in _mint function to a personal wallet address."

"Mozart’s contracted Solidity developer built a minting function in the PIANO contract’s code. He left the minter role in place, deeply rooted among the core functions of the contract."

"The deployed smart contract was swapped for a malicious one, containing the minting functions employed during the attack. These minting functions were not present in the code at the time of the audit." "[T]he original contract that was audited by ImmuneBytes did not have any externally exposed (public/external) mint functionality."

"The original code intended to have only a single minter role, the hacker, however, added a minter role for himself too. The attacker also did not transfer the Ownership to the intended recipient. The modified code also had an initial supply added to it, uint256 private constant _initialSupply = 45000*10**18 , with the use of which a supply of 45K PIANOs would be transferred to whoever deployed the smart contract. This was something that the code did not intend to do, originally."

"The true logic of the project was based on a Decreasing Supply Model, implying that as the funds are transferred, 1% of the transferred tokens would be burned. For example, let’s say you were to farm 100 PIANOs. According to the project model, you would burn 1% of these 100 PIANOs and would acquire 99 PIANOs. The hacker altered this decreasing supply model such that no percentage of PIANOs were burnt, using transferFrom() function."

"We have been hacked. @cz_binance @binance Developer left a minting function from his address: 0xdA9f9d44F4c5022c789641802c10Da5992557D35."

"It turns out this outsourced developer slipped in a minting code without the original developers from the team and the project owners noticing. The project team had the code audited before deployment on the BSC network but failed to check the codes thoroughly again. After the audit it seems the outsourced developer must have handled the codes."

"For now, the team has warned traders through its handle to halt the purchase of $PIANO as the exploit hacker has minted over 100,000 PIANO tokens and is actively dumping."

“In short, we strongly advise you not to buy PIANO because the contract has NOT been fixed and is not safe. We are very sorry, but this is the inconvenient truth.”

"Users [had] the opportunity to vote any of the three options available to pick from; [a]irdrop new tokens to PIANO holders in a 1-to-1 ratio, [r]edeploy [the] PIANO smart contract and give a fair launch, or [c]lose the project."

"From the look of things, this is far from over for the Mozart Finance team as the odds are not on their side judging from the angry users’ response both on Twitter and Telegram platforms."

"That’s why we have decided to give our lovely community a chance to check our smart contract before we deploy them. This is our first ‘community check’ and it surely isn’t the last one! We plan to do this before the deployment of each and every smart contract — as transparent as possible."

"We’re happy to announce that the audit company our lovely community chose, Hacken, finished the official audit of MELODY contracts. After two reviews and thorough analysis of code functionalities, MELODY contracts passed its test with flying colors."

This is a global/international case not involving a specific country.

The background of the exchange platform, service, or individuals involved, as it would have been seen or understood at the time of the events.

Include:

• Known history of when and how the service was started.
• What problems does the company or service claim to solve?
• What marketing materials were used by the firm or business?
• Audits performed, and excerpts that may have been included.
• Business registration documents shown (fake or legitimate).
• How were people recruited to participate?
• Public warnings and announcements prior to the event.

Don't Include:

• Any wording which directly states or implies that the business is/was illegitimate, or that a vulnerability existed.
• Anything that wasn't reasonably knowable at the time of the event.

There could be more than one section here. If the same platform is involved with multiple incidents, then it can be linked to a main article page.

The Reality

This sections is included if a case involved deception or information that was unknown at the time. Examples include:

• When the service was actually started (if different than the "official story").
• Who actually ran a service and their own personal history.
• How the service was structured behind the scenes. (For example, there was no "trading bot".)
• Details of what audits reported and how vulnerabilities were missed during auditing.

What Happened

The specific events of the loss and how it came about. What actually happened to cause the loss and some of the events leading up to it.

Key Event Timeline - Mozart Finance Developer Exploit

Date	Event	Description
April 5th, 2021	Main Event	Expand this into a brief description of what happened and the impact. If multiple lines are necessary, add them here.

Technical Details

This section includes specific detailed technical analysis of any security breaches which happened. What specific software vulnerabilities contributed to the problem and how were they exploited?

Total Amount Lost

The total amount lost is unknown.

How much was lost and how was it calculated? If there are conflicting reports, which are accurate and where does the discrepancy lie?

Immediate Reactions

How did the various parties involved (firm, platform, management, and/or affected individual(s)) deal with the events? Were services shut down? Were announcements made? Were groups formed?

Ultimate Outcome

What was the end result? Was any investigation done? Were any individuals prosecuted? Was there a lawsuit? Was any tracing done?

Total Amount Recovered

There do not appear to have been any funds recovered in this case.

What funds were recovered? What funds were reimbursed for those affected users?

Ongoing Developments

What parts of this case are still remaining to be concluded?

General Prevention Policies

The source of the problem was an anonymous developer who was able to create an exploit and provide a final modified version of code after the audit.

Individual Prevention Policies

No specific policies for individual prevention have yet been identified in this case.

For the full list of how to protect your funds as an individual, check our Prevention Policies for Individuals guide.

Platform Prevention Policies

Policies for platforms to take to prevent this situation have not yet been selected in this case.

For the full list of how to protect your funds as a financial service, check our Prevention Policies for Platforms guide.

Regulatory Prevention Policies

No specific regulatory policies have yet been identified in this case.

For the full list of regulatory policies that can prevent loss, check our Prevention Policies for Regulators guide.