Open SecSamDev opened 4 years ago
Normally that doesn't happen. Can I get a copy of the actual document with macros? Maybe there's something weird in it.
Sure, sample sended.
Thanks. OK, I can see why this is happening. Problem is, I don't see how to fix it...
The code that is causing the problem is this:
if idCode > 0xBE:
idCode -= 1
If I don't subtract 1, this sample will be disassembled correctly. But then others (that are now disassembled correctly) won't be. I'll have to see if I can find a way to fix it properly, but for now I have no idea how.
I would be happy to help you. But I don't understand what exactly idCode does.
The purpose of the function this code resides in is to take the operand of an opcode instruction that refers to a symbolic argument (like a variable or function name) and locate the corresponding symbol in the symbol table. Problem is, the algorithms have changed with the VBA and Office versions and it's a bit of a hit-and-miss to figure out the correct one. I'll keep digging.
The problem is further exacerbated by the fact that I don't have all the Office versions. The last one that I have is 2002. I have some documents created by later versions (like 2010 and 2013) but I don't have these versions of Office, so I can't freely experiment with them. And I don't think I have anything created with Office 2016 or Office 365...
I really don't know how to solve this... If I don't subtract 1 there, the macro in the document in this repository won't be disassembled correctly. If I do, your Emotet sample won't be disassembled correctly.... On the top of everything, both problematic documents are made with an Office version that I don't have and can't experiment freely with... I'll keep digging but for now I'm out of ideas.
If you need sample files created with different versions of Office, maybe we can help. What would you need exactly?
I'm not really sure; I would have preferred to experiment with different things myself... For starters, the problem seems to occur when the VBA project uses lots of different symbols - like 200 or more.
Thanks. OK, I can see why this is happening. Problem is, I don't see how to fix it...
The code that is causing the problem is this:
if idCode > 0xBE: idCode -= 1
If I don't subtract 1, this sample will be disassembled correctly. But then others (that are now disassembled correctly) won't be. I'll have to see if I can find a way to fix it properly, but for now I have no idea how.
I met this problem too, any more progress?
No, I couldn't figure out how to solve it, sorry.
Share with me a sample where this occurs and a normal one; I will dig it and see whether I can figure it out
I really don't know how to solve this... If I don't subtract 1 there, the macro in the document in this repository won't be disassembled correctly. If I do, your Emotet sample won't be disassembled correctly.... On the top of everything, both problematic documents are made with an Office version that I don't have and can't experiment freely with... I'll keep digging but for now I'm out of ideas.
I've noticed that the Pafish.docm document has an empty identifier. Empty identifiers are not appended to the identifier list, and I guess that is the reason why the index does not match?
I'd suggest:
if idLength:
ident = decode(vbaProjectData[offset:offset + idLength])
identifiers.append(ident)
offset += idLength
else:
identifiers.append("<unknown>")
What is an empty identifier?
Anyway, your proposed change does not solve the problem - it just makes the output wrong in a different way. I'm not accepting it.
What is an empty identifier?
I mean an identifier without a name (where idLength is 0)
Anyway, your proposed change does not solve the problem - it just makes the output wrong in a different way. I'm not accepting it.
I forgot to mention that this part:
if idCode > 0xBE:
idCode -= 1
has to be removed as well, because the index adjustment is not needed anymore.
I've tested it and it seems it work:
...
Line #388:
FuncDefn (Public Sub mark())
Line #389:
Line #390 (2 leading spaces):
Ld ActiveDocument
MemLd Range
MemLd Text
St Text
Line #391 (1 leading spaces):
Line #392 (4 leading spaces):
Ld Text
Ld vbCr
ArgsLd Split 0x0002
St toks
Line #393 (4 leading spaces):
Line #394 (4 leading spaces):
LitDI2 0x0000
St c
Line #395 (4 leading spaces):
Line #396 (4 leading spaces):
StartForVariable
Ld tok
EndForVariable
Ld toks
ForEach
Line #397 (8 leading spaces):
Line #398 (8 leading spaces):
Ld tok
FnLen
St l
Line #399 (8 leading spaces):
Line #400 (8 leading spaces):
Ld tok
LitStr 0x0002 "OK"
Eq
IfBlock
Line #401:
Line #402 (12 leading spaces):
Ld vbGreen
Ld c
Ld c
Ld l
Add
Ld ActiveDocument
ArgsMemLd Range 0x0002
MemLd Font
MemSt color
Line #403 (5 leading spaces):
Line #404 (8 leading spaces):
EndIfBlock
Line #405 (2 leading spaces):
Line #406 (8 leading spaces):
Ld tok
LitStr 0x0008 "DETECTED"
Eq
IfBlock
Line #407:
Line #408 (12 leading spaces):
Ld vbRed
Ld c
Ld c
Ld l
Add
Ld ActiveDocument
ArgsMemLd Range 0x0002
MemLd Font
MemSt color
Line #409 (5 leading spaces):
Line #410 (8 leading spaces):
EndIfBlock
Line #411 (8 leading spaces):
Line #412 (8 leading spaces):
Line #413 (8 leading spaces):
Ld c
Ld l
Add
LitDI2 0x0001
Add
St c
Line #414 (4 leading spaces):
StartForVariable
Next
Line #415 (4 leading spaces):
Line #416 (4 leading spaces):
LitDI2 0x0000
Ld ActiveDocument
MemLd Range
MemLd ParagraphFormat
MemSt SpaceBefore
Line #417 (4 leading spaces):
LitDI2 0x0000
Ld ActiveDocument
MemLd Range
MemLd ParagraphFormat
MemSt SpaceAfter
Line #418 (4 leading spaces):
LitDI2 0x0008
Ld ActiveDocument
MemLd Range
MemLd Font
MemSt Size
Line #419 (2 leading spaces):
Line #420:
EndSub
OK, this seems to work. I'm a bit busy right now but when I can find the time (and remember how to release a new version on PyPi), I'll merge your change.
The code is using the wrong object names. And more specifically, it's choosing the name of the previous object as the current one, so all the names of the objects / functions in the macro are wrong. Maybe the (empty macro) is making the algorithm confused.