Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

[Question]: Solidity output includes storage mapping access, causes compilation error "Expected primary expression" #85

Closed
2 tasks done
pepperstepper opened this issue Apr 7, 2023 · 19 comments
Assignees

Comments

@pepperstepper
Copy link

Version

Version 0.4.2:

Please check the following

  • This is not a duplicate question
  • I have checked the wiki beforehand

Operating System

macOS (Apple Silicon)

Ask your question here

Hi, I am asking this as a question, not a bug, as it is most likely me misunderstanding some aspect of the project.

I have decompiled a solidity contract and it has accesses to a global storage map, to access storage variables, and my solidity compiler won't compile this and complains with the error "Expected primary expression".

Can this be changed so an equivalent solidity output is generated, which can compiler, or is the solidity output not meant to able to be compiled and is just for illustration?

Thanks,
Pepperstepper.

@pepperstepper
Copy link
Author

This is an example of a problem line:

if (!(storage[keccak256(var_a)]) - arg1) { revert(); } else {

Error:

"Expected primary expression".

Due to the storage variable access.

@Jon-Becker
Copy link
Owner

Hey! The decompiled source is not meant to recompile, it's just used to illustrate contract logic.

In the future I might* be able to produce compiling source, but that's far off.

@pepperstepper
Copy link
Author

Ah okay, no worries. I tried the JEB EVM free compiler and that at least seems to not use the storage variable, which causes the compilation issue. It doesn't allow easy copying of the source code it produces in the free version however.

Your tool seems to better matchup the function names however, which is a nice bonus.

@Jon-Becker
Copy link
Owner

I can postprocess the invalid storage vars away, but it would still likely be invalid due to other issues

@pepperstepper
Copy link
Author

I think that (getting rid of the storage vars) would definitely be a plus.

Another thing that could be useful is spotting common require patterns at the top of setter functions, as well as maybe matching certain common library references in the byte code to top of line imports, such as the openzeppelin standards etc. would be huge.

Of course any solidity file produced from it would be provided without guarantee, but reducing the number of steps the user would have to do, if their goal was source code recreation, would always be useful.

@Jon-Becker
Copy link
Owner

I'll take these suggestions and try to build something out!

@pepperstepper
Copy link
Author

That would be amazing <3

@Jon-Becker
Copy link
Owner

I've added event and error declarations in 0.4.3, so it's closer to compileable. Storage will come next in 0.4.4.

@pepperstepper
Copy link
Author

Awesome! For me the storage aspect was the most high effort thing to attempt to resolve by hand, so am looking forward to giving that a go! Will definitely report my usage report here once added.

@Jon-Becker
Copy link
Owner

image

nearly there haha, sorry for slow progress had some finals to deal with

@pepperstepper
Copy link
Author

Oh super. It's looking promising :)

I can't wait to test it out!

I think your tool might soon be the best decompiler for solidity, and also free and accessible. Lovely stuff.

@pepperstepper
Copy link
Author

I wonder if it would be possible to get the names for the public storage variables? As they generate view functions essentially anyway dont they? And ive seen your program get the names of view functions already.

@Jon-Becker
Copy link
Owner

Yeah I can make it pull names for some storage variables under certain circumstances. For example, we can look at name() returning RLP decoded storage[0], so we can assume name() is a getter for string public name or something.

@pepperstepper
Copy link
Author

Yeah, I dont think even the paid for JEB decompiler does that from what ive seen, so that would definitely set heimdall apart!

@Jon-Becker
Copy link
Owner

Will have a release for you this weekend!

@Jon-Becker
Copy link
Owner

A bit delayed, but I havent forgotten :D

@pepperstepper
Copy link
Author

No complaints from me! I hope you had a good weekend.

@Jon-Becker
Copy link
Owner

You can track progress here: #87

A bit busy since I'm moving in this week, but should be merged soon! (Also features up to ~45% speed increases across decompile and cfg modules!)

@Jon-Becker Jon-Becker self-assigned this May 12, 2023
@pepperstepper
Copy link
Author

Very exciting! I too am moving this week haha.

I have a particular use case I am hoping to use this for. Looking forward to it!

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants