2

I'm trying to understand the winning contract from the Underhanded Solidity Contest.

That contract apparently caused an overflow in the ABI decoder, but I'm having a hard time understanding where in the "stack" (not literal stack, but where in the technologies that comprise Ethereum) the overflow occurred.

From reading the docs and this answer I get that the ABI is not a part of the core ethereum protocol defined in the yellow paper, but my question is this:

What takes:

     0x69f30401
     "00000000000000000000000000000000000000000000000000000000cafebabe"
     "0000000000000000000000000000000000000000000000000000000000000060"
     "00000000000000000000000000000000000000000000000000000000000000A0"
     "F000000000000000000000000000000000000000000000000000000000000001"
     "0000000000000000000000000000000000000000000000000000000000000003"
     "F000000000000000000000000000000000000000000000000000000000000001"
     "0000000000000000000000000000000000000000000000000de0b6b3a7640000"

Decodes it, and executes it on the EVM? Do transactions themselves contain the above^? How then is that not a part of the core ethereum protocol? I don't understand how you get from ABI to EVM instructions being executed and what code is doing the executing.

If the exploit relies on Solidity decoding the ABI and causing an overflow, does that mean all mining nodes are running Solidity? How can that be?

My mental model seems to be missing something fundamental here. Diagrams are appreciated if you have the time, thanks!

5

The ABI encoding is not part of the core protocol of Ethereum because the payload data in transactions is not required to have any structure, it is just a sequence of bytes. Similarly, the Ethereum Virtual Machine also just processes the data as a sequence of bytes.

For example, the first four bytes of a transaction payload sent to a contract are usually used to distinguish which function in the contract to call. For Ethereum and the EVM, a contract is just a single program that is run on this sequence of bytes. Only the higher level language like Solidity, Viper or Bamboo defines how you get from the entry point of the program to the entry point of a particular function (of course you can create a high level language that does not have a concept of functions that can be called from outside).

The ABI decoder is automatically generated by the Solidity compiler depending on which kinds of functions you define in your contract, as is the function dispatch routine that calls the correct function depending on the first four bytes of the payload.

A transaction contains for example the sequence of bytes you gave in the question. How these bytes are interpreted into structured data is up to the program and thus up to the programming language used. In order to make it possible for two programs written in different programming languages to call each other, the compilers of such languages should implement the serialization and deserialization of data in the same way, i.e. they should implement the ABI specification, but they do not have to.

  • Ahhh thank you! The point of the spec being necessary for different languages to call one another makes so much sense, but was not mentioned in anything I read when trying to understand why the ABI exists. Everything is totally clear now, much appreciated. – user1234 Sep 29 '17 at 15:45

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.