Assignment operator not supported and wrong XLSB formula parsing #64
Assignees
Labels
bug
Something isn't working
Comments
|
Thank you very much for your post. I skimmed over it and I think I got the main points. But I need to read it more carefully. The test2.xlsb is interpreted without any problem (at least, with the recent changes). There is no ambiguity there. Please update from the master branch of pyxlsb and xlmmacrodeobfuscator. xlmdeobfuscator's output: https://pastebin.com/CcEZPXdW Regarding xlsm, I can see the problem. I will read your code and patch the master. |
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
First of all, thank you for your great work.
Assignment operator
The equal (=) operator is both a comparison and an assignment operator (à là VBA/VB6). Consider this macro:
The first two line are problematic: they set the names
WnZdDroiBxUqPVandRcguQSbkfJZrto two values. Furthermore, the second one is doubly offending since the RHS is a reference (or whatever it is officially called) to the cell$IG$1852.You can tell this must be the case from the code at
AU259which essentially makes the whole code a "set-cell" gadget.However, the deobfuscator currently doesn't support this assignment semantic of the = operator: it evaluates the expression as a comparison and when the formula at AU259 is executed it throws because none of the names are found (and that's an unhandled case).
This macro is found in test1.xlsm attached. This document is derived from test2.xlsb by saving it in XLSM format using Office 2010.
I made a patch I do not am proud of, to handle basic assignment semantic, at least what's needed to parse test1.xlsm.
Since I didn't go through any regression test and I've actually less than a day experience with your code, I attach the patch here rather than making a PR.
The idea is to to consider "=" an assignment unless the rule
expressionis parsed as part of the ruleargument(i.e. unless we are dealing with an argument). I don't know XLM well enough to be sure this is 100% correct, in fact i strongly believe it is not.But it works in this case.
Then if we encounter the "=" operator, we treat it like a
SET.NAMEexcept that if the RHS evaluates to nothing then we assume it is a cell reference (TODO: really check what the tree matched instead!).This ugly fix produces the output
Which is good enough to get the drop URL.
Wrong XLSB formula parsing
Ptg are hellish, I know. There are a lot of them.
The XLSB wrappers fails with the attached test2.xlsb, it tries to stringify an empty formula. I don't know why this happens and if it should in the first place, one can force the code go on by returning an empty string in such a case (and that's what I did, patch not attached though).
The XLSB wrapper return
UserDefinedFunction($GU$614)for what the XLSM parsed as$GU$614().This can be easily handled by retrieving the right function name.
Alas, the deobfuscation abort because the XLSB wrapper return a strange
=RETURN(FORMULA.FILL(#PTG67!, #PTG35!))).Maybe those Ptg are not fully implemented?
Show names command
Finally, I added two lines of code in the interactive shell to show the currently defined names with
:names.You may want to remove those.
Final thoughts
The code I wrote is an ugly hack, test thoughtfully.
The attached documents are few-days-old Ursnif samples (the drop URL and the C2 are now gone) so they are good candidates for tests.
Thank you again for this project :)
tests-xlm.zip
The text was updated successfully, but these errors were encountered: