Support Ref3dPtg, read names to stringify for NamePtg#2
Support Ref3dPtg, read names to stringify for NamePtg#2oleglpts wants to merge 1 commit intoDissectMalware:masterfrom oleglpts:Defined_names_references
Conversation
|
Thank you for the pr. Could you please also provide a sample file? |
|
Test:
|
|
You can modify the test so that relative links are resolved when the cell is known: ` ` There is a better algorithm, this is the first thing that came to mind. Then the output will be like
|
|
Thank you for the explanation and also for the sample. I will merge the code shortly. "GetFormula1 (GET.CELL(6, H4)) is definitely preferred to: "GetFormula1 (GET.CELL(6, [@-1, @0])) As the later is not a valid macro. XLMMacroDeobfuscator, an XLM emulator, relies on pyxlsb2 to extract XLM. XLMMacroDeobfuscator's underlying assumption is that pyxlsb2 output is valid XLM and interpretable. |
|
Ok. Then, I think, the best is "GET.CELL(6, H4)" - it is interpretable, not "GetFormula1 (GET.CELL(6, H4)". GetFormula1 is just the name for GET.CELL(6, [@-1, @0]). |
|
Yup you are right. It was a copy/pasting mistake. My focus was on H4 and [@-1, @0] |
|
Updated cell_address method in Ref3dPtg Does the output make sense? (mixing r1c1 and a1 notations might be a bad idea but we don't have current cell information so it is hard to stick with a1 addressing when we stringfy the formulas referred by the defined names) |
|
I propose this solution: add the optional parameters row and col to NamePtg.stringify and immediately resolve the relative links to the interpreted form when the cell is known (see here ). |

Now, when processing file with defined names, does not occur an exception "External address not supported"