To pass the&nbsp;<code class="inline-code">MaagiriTrial</code>, a contract must change its bytecode.

Set the&nbsp;<code><code class="inline-code">isPassed</code></code>&nbsp;variable in&nbsp;<code><code class="inline-code">MaagiriTrial</code></code>&nbsp;to&nbsp;<code><code class="inline-code">true</code></code>.

Changing an Address' Bytecode

Like water, the Maagiri have no fixed shape. Help Alecia regain her ability to shapeshift.

Solving the challenge requires an understanding of the EVM’s <code class="inline-code">CREATE2</code> opcode.

What is <code class="inline-code">CREATE2</code>?

It is an opcode for deploying contracts to <b>deterministic</b> addresses. Normally, when we deploy a new contract, the destination address is determined by the <code class="inline-code">msg.sender</code> and its nonce. Because of the inconsistent nonce, there is no way to pre-determine the address beforehand, or deploy to the same address twice.

With <code class="inline-code">CREATE2</code>, the destination address is determined by a function of the new contract’s creation code, the address of <code class="inline-code">msg.sender</code>, and an arbitrary salt value. These, unlike the nonce in <code class="inline-code">msg.sender</code>, are deterministic inputs.

This also means that if we use the same salt, <code class="inline-code">msg.sender</code> and creation code, we can theoretically deploy to the same address twice. Furthermore, two contracts with the same creation code can have varying bytecode if the constructor queries external state and incorporate that into the contract’s deployed bytecode (i.e.&nbsp;the contract can “shapeshift”).

However, there is a small catch. <code class="inline-code">CREATE2</code> fails if the address already has non-empty bytecode (i.e.&nbsp;already has a contract deployed to it). This is where <code class="inline-code">selfdestruct</code> comes into play…

Here is how we can pass the&nbsp;<code><code class="inline-code">MaagiriTrial</code></code>.

Here is how we can call&nbsp;<code><code class="inline-code">CREATE2</code></code>&nbsp;in inline assembly.

To view a contract's bytecode, you can either use Solidity or an external tool like <b>ethers.js</b>.

Eventually, you lose count of the number of attempts you have made to fix Alecia. But finally, when you’ve nearly given up, you land on the correct solution. This time, when Alecia closes her eyes and concentrates, her skin begins to glow a rich sapphire blue. Before your very eyes, her body begins to melt.&nbsp;

At first, you are alarmed as the woman before you sinks into a shapeless ooze. Then she reshapes her anatomy before your eyes. She forms limbs, which slowly morph into tentacles, then dangerous barbed blades before she retakes her human form.

Relieved beyond measure that she can once again rejoin her people, Alecia thanks you profusely for your help. But truth be told, all you gave was a little encouragement. The problem had been little more than a mental block brought on by her infatuation with her human lover. There was never a moment the Maagirus had actually lost her genetic gifts.

But gratitude is gratitude, and you’re not going to turn down her reward…

The Black Forest is home to many strange species. Some are friendly, while many more are decidedly unfriendly. But only a very few possess the elusive ability to shapeshift. The best known of these are the Maagiri, a clan of beings with the ability to take on any number of forms at will. 

Visiting the Chapterhouse near the forest, you come across a Maagirus named Alecia. She has come out of the forest to ask the guardians for help. A few weeks ago, she met and fell in love with a human man. But in doing so, she has found herself unable to shift out of human form. Now her clan has cast her out.

Please, help me. They say the Guardians know magics no one else does. Can you help me return to my people?&nbsp;

mediaLibraryStrapi

Find a way to help Alecia regain her abilities and return to her clan?&nbsp;

There is a common misconception that once a contract has been deployed onto an address, its bytecode can no longer mutate. This is generally true until we consider the possibility of contracts that <code class="inline-code">selfdestruct</code>.

To recap, we can create mutable bytecode by: 

This seems like an odd use case. But it proves that a malicious attacker can deploy a seemingly trustworthy contract to have unknowing users deposit their assets into it. Assuming the contract has self-destructing capabilities, the attacker can destroy the contract and redeploy a new one to steal these assets.

In general, self-destructing contracts are inherently dangerous. We should not assume that these addresses will permanently remain ‘destroyed’ after.

Contracts that contain a <code class="inline-code">SELFDESTRUCT</code>, <code class="inline-code">DELEGATECALL</code>, or <code class="inline-code">CALLCODE</code> opcode all are potentially self-destructive.

There is a common misconception that once bytecode is deployed onto an address, it is immutable. Learn how this assumption can be challenged.

Changing Bytecode

prelude