VbaProject Compilation

[Beakerboy]

I thought you might want to know about a project I’m working on to create a working vbaProject.bin file from text sources.
https://github.com/Beakerboy/vbaProject-Compiler

This project includes a VbaProject class that contains all the attributes of the project, as well as specialized module classes for the different types of code that can be associated with a project. I’ve only been working with Excel vbaProject.bin files so far.

I’m hoping to read through your project to help learn how the performance cache is formatted, and maybe generate the PCode from the text. Does your project do that already?

Feel free to leverage any of my classes into your project.

[bontchev]

No. My program does not generate p-code form the text. It does not look at the text at all. Instead, it looks at the already present p-code and disassembles it - i.e., converts the p-code instructions into human-readable form.

[Beakerboy]

That’s what I thought. I was hoping it worked in both directions. Let me know if you have any advice on the generation.

[Beakerboy]

Have you ever written up a white paper that describes how the pcode data is packed into the performance cache region of each module’s stream data? If you have a moment to write out a few of the key observations, I’d love to see them. Obviously I can read the source code, but an actual description might help make sense of why the source code is the way it is.

[bontchev]

I'm sorry, I don't know.

The module stream contains much more than two elements... Maybe they mean the execodes? Nahh, can't be - they are in separate streams; not in the module stream.

The p-code area is preceded by a table, containing pointers to the p-codes of each line. The elements of this table are in the correct order of the VBA program lines; the compiled p-code lines can appear in any order (usually in the order in which they are created). The compiled p-code lines are multiple of 8 bytes; the unused part at the end is garbage.

Since I need only the line table and the p-code lines in order to disassemble the module, I try to skip everything else and I don't know what it is for.

[sancarn]

@Beakerboy Is P-Code assembly purely an academic exercise? As far as I understand P-Code assembly is not strictly required, if the P-Code is missing then Excel/Word/The application will perform the assembly instead. So I am curious as to why you want to even attempt P-Code assembly in the first place?

[Beakerboy]

@sancarn This entire project is an academic exercise. In an ideal world, my app would produce the same output vbaProject.bin as Excel given the proper inputs, and Excel automatically creates the performance cache. It’s low priority, but on the list.

[sancarn]

@Beakerboy My only thought was generating a vbaProject with compressed code is useful, not certain if generating p-code has any uses/benefit outside of building malware... Possibly benefits in distribution of proprietary code without distributing source?

[Beakerboy]

I’ve thought the same thing, regarding malware. For, me it’s generating test data and just general understanding.

[Beakerboy]

I’m following the code and I have a question about Line 1113. Is this supposed to be 10 or 12 like the above case. I have a file (https://github.com/Beakerboy/vbaProject-Compiler/blob/Create_cache/tests/blank/vbaProject.bin.txt) with version 0x00B5. File offset 0x0811 is offset 0x11 in the first VBA module. The Dword here is 0x0200, so adding 10 to it gives us offset 0x020A. Adding 0x0800 (the start of the file) says that the TableStart should be at file offset 0x0A0A. However, starting at 0x0A0A is “01 01 40 00 00 00” i’m guessing the next dwLength = getDWord(moduleData, tableStart, endian) is supposed to be reading a value of 4. The only way to get this is to use tableStart = dwLength + 12 instead of 10.

[bontchev]

I'll take a look whenever I have the time, although I'm rather busy right now.

In general, the disassembler does work correctly most of the time. If there was a simple mistake of using the wrong offset, it wouldn't work at all, all the time. There might be some obscure factor, like a VBA version-dependent quirk that I'm not taking into account and that causes trouble in some documents; I'll have to see.

[Beakerboy]

Without tests and code coverage metrics, I have nothing to compare my file to, and have no idea what bytes differ within the file that justify the 10 vs 12 offset. I wasn’t implying that the disassembler would never work, just noting that my file seems to look like a VBA version 6 file, but with an offset of 12 instead of 10. Maybe this is something you’ve seen before, or maybe I’ve discovered something that can help you. Sorry if it came off wrong.