I don’t want to demotivate you, but I really question if what you are aiming for is really feasible. A few thoughts:
- Audio processing routines almost always perform computations on the incoming audio data and some state variables. Let’s take a simple IIR based low pass filter. It has a set of filter coefficients and some filter state, which are both usually members to the processors class. The processing function will access the I/O sample buffer, the filter state and the filter coefficients to perform its processing. However, this is only yields to meaningful processing because at some points you invoked a filter design function first to compute the coefficients. Now even if you had decompiled the processing code, you were not able to recreate the processing if you don’t also find the code that performs the coefficient calculation. And that function might be invoked only in reaction to a parameter change and then need some other side information like the sample rate, that has been set during prepare. I assume that the processing code that you want to reverse engineer is a bit more complex than a simple low pass, so it might become quite more complex than just reverse engineering a single function.
- As I get it, Ghidra will output C code. Your plugin has been written in C++, so the code will differ quite massively from the original version. Taken the issues from 1. aside, it probably needs major refactoring in order to become readable, maintainable and integratable in a C++ plug-in. You will probably only be able to refactor the code accordingly if you have some deep knowledge about what’s going on in the processing. Honestly, at that point, you are probably a lot faster just re-implementing the processing from scratch.
Anyway, good luck
Reverse engineering some plugins processBlock … okay, its an interesting exercise, assuming one is doing this reverse engineering on ones own plugin - but if doing it on others’ plugins, perhaps we ought to reconsider the effort…
Hi all I finally was able to debug my plugin creating it with Projucer (blank project) and the “out-of-the box” Visual Studio solution (VSCode its a bit messy with debugger; I’ve opened a dedicated topic for this). Anyway…
I keep the ScopedNoDenormals code:
but when I look at the breakpoint’s Disassembler:
I don’t find (how you can see) any of the
Am I missing somethings more?
It looks like this wasn’t compiled with optimizations enabled.
I’m now in Release mode:
If I use /O2, can’t debug anymore in Relese mode.
On Release mode, if I add /Oz:
I got the same disassembly:
Switching back to Debug mode and enabling /O2:
I got the same results:
I was using Xcode on Mac, so it’s possible the optimizations done by MSVC aren’t the same.
But I suggest looking at the actual binary in a proper disassembler, not the assembly view in Visual Studio.
Well, that’s the point, locate the entry point within disassembler. Can’t find the processBlock function for example, so I miss the starting point within Ghidra
Anyone other can help on this using MSVC? Thanks for any additional tips
Isn’t the processBlock code after what happens with the ScopedNoDenormals related assembly? The compiler just seems to insert a call to the constructor of that instead of inlining it, for some reason. So what follows in the processBlock code should probably be after that.
It should, but what should I search on Ghidra to intercept those instructions? i.e.
Can’t of course seach “juce::ScopedNoDenormals::ScopedNoDenormals”