-
Notifications
You must be signed in to change notification settings - Fork 133
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
Comments
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. |
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. |
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. |
I can postprocess the invalid storage vars away, but it would still likely be invalid due to other issues |
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. |
I'll take these suggestions and try to build something out! |
That would be amazing <3 |
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. |
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. |
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. |
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. |
Yeah I can make it pull names for some storage variables under certain circumstances. For example, we can look at |
Yeah, I dont think even the paid for JEB decompiler does that from what ive seen, so that would definitely set heimdall apart! |
Will have a release for you this weekend! |
A bit delayed, but I havent forgotten :D |
No complaints from me! I hope you had a good weekend. |
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 |
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! |
Version
Version 0.4.2:
Please check the following
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.
The text was updated successfully, but these errors were encountered: