Successfully built the .so, and placed into the IDA 7.1/plugins directory.
It can't load successfully in IDA though:

dlsym(/home/eugenek/ida-7.1/plugins/HexRaysDeob.so._PLUGIN): /home/eugenek/ida-7.1/plugins/HexRaysDeob.so: undefined symbol: PLUGIN
/home/eugenek/ida-7.1/plugins/HexRaysDeob.so: not IDA DLL file

Hi. I've tried to install your plugin in my Ida Pro (Hexrays and Ida version both 7.2).
I'm kinda new to IDA so I just tried to copy .dll file(and other src, hdr files) into %IDA_DIR%/plugins directory and modified plugins.cfg file as that is the general way everyone says in Google, but it didn't worked and I cannot find the plugin in IDA.
Is there another way to install your plugin or am I doing it wrong?

Hi,

I'm modifying HexRaysDeob to work for other binary sample.
The sample uses opaque predicates condition when assigning values to block comparison variable.
For example, in the following flattened blocks, the next comparison magic value is always 0xC504A26C (highlighted).

So I'd like to apply the un-flattening function in more matured level like MMAT_GLBOPT2, not MMAT_LOCOPT.
I noticed the mapping between the variables and Hex-Rays mblock_t numbers is lost in more matured level due to the optimization, so different algorithm is needed for the mapping. But is there any other side effect in the more matured levels?
I'd like to know why you decided to implement in MMAT_LOCOPT.

Thanks.

Hi,

I tried to build the code with IDA SDK and HexRays SDK 7.2 but there were some undefined/undeclared items.

e.g.,

• mfuncinfo_t and mfuncargs_t
• optimize_flat
• mbl_array_t::make_chains_dirty

All are defined in hexrays_sdk 7.1 but not defined in the 7.2.
Could you modify to work on IDA 7.2 or tell me the hints so that I can do that?

Thanks,
Takahiro

Correct me if I'm wrong, I placed it in plugin folder. When I want to load plugin or I find the menu I didn't see it.
Maybe a few screenshot of your brilliant plugin will be helpful

I've saw other issues, I know that this plugin doesn't supported IDA7.0 or lower. Is there other ways to fit it, or it can't do it because of the microcode API?

Any guidance compiling for 7.3 on Mac?
Makefile crashes out early, not finding type definitions that are contained within the SDK.

c++ -m64 -arch x86_64 -mmacosx-version-min=10.9 -isysroot /Library/Developer/CommandLineTools/SDKs/MacOSX10.14.sdk -std=c++11 -g -pipe -O2 -I../../include/ -DNDEBUG -DNO_OBSOLETE_FUNCS -D_FORTIFY_SOURCE=2 -D__MAC__ -fPIC -fdata-sections -fdiagnostics-show-option -ffunction-sections -fno-caret-diagnostics -fno-strict-aliasing -fomit-frame-pointer -fstack-protector-strong -fvisibility-inlines-hidden -fvisibility=hidden -fwrapv -Wall -Werror=format-nonliteral -Werror=format-security -Wextra -Wformat=2 -Wshadow -Wunused -Wno-char-subscripts -Wno-dynamic-class-memaccess -Wno-format-y2k -Wno-int-to-pointer-cast -Wno-invalid-source-encoding -Wno-logical-not-parentheses -Wno-logical-op-parentheses -Wno-missing-field-initializers -Wno-null-conversion -Wno-parentheses-equality -Wno-self-assign -Wno-sign-compare -Wno-unused-const-variable -Wno-unused-function -Wno-unused-private-field -Wno-unused-variable -Wno-varargs -fno-rtti -c -o obj/x64_mac_gcc_32/AllocaFixer.o AllocaFixer.cpp In file included from AllocaFixer.cpp:18: In file included from ../../include/hexrays.hpp:14: In file included from ../../include/idp.hpp:12: ../../include/nalt.hpp:733:3: error: unknown type name 'op_dtype_t'; did you mean 'idtype_t'? /Library/Developer/CommandLineTools/SDKs/MacOSX10.14.sdk/usr/include/sys/wait.h:83:3: note: 'idtype_t' declared here In file included from AllocaFixer.cpp:18: In file included from ../../include/hexrays.hpp:14: In file included from ../../include/idp.hpp:12: ../../include/nalt.hpp:744:24: error: unknown type name 'op_dtype_t'; did you mean 'idtype_t'? /Library/Developer/CommandLineTools/SDKs/MacOSX10.14.sdk/usr/include/sys/wait.h:83:3: note: 'idtype_t' declared here In file included from AllocaFixer.cpp:18: In file included from ../../include/hexrays.hpp:14: In file included from ../../include/idp.hpp:12: ../../include/nalt.hpp:793:7: error: cannot initialize a member subobject of type 'idtype_t' with an rvalue of type 'int' In file included from AllocaFixer.cpp:18: In file included from ../../include/hexrays.hpp:14: In file included from ../../include/idp.hpp:15: In file included from ../../include/ua.hpp:11:

Which version of your hexrays.hpp is it, please?

IDA Version: 7.2

For example, we can write this simple code

#include <stdio.h>

int main(int argc, char **argv) {
    if (argc == 2) {
        printf("2\n");
        return 1;
    }
    printf("1\n");
    return 0;
}

When compiled and thrown into ida, when using IDA under text view, with MMAT_LOCOPT, we get

However, if we switch to graph view with the same function under same optimization, we get

As we see here, the microcode at Block 2, after puts has an extra mov rdi at the end of the block. This repeated extra instruction almost appears in every single block.

The other consequence is that under graph view, no matter how many times I try regenerating the microcode, the line number will never show up.

Although I wonder if this is a bug in the hexray SDK's print function rather than the plugin itself.

Hi,
I'm having trouble building this plugin with the latest SDK.
there is some issue with ObfCompilerOptimizer instantiation.

did any body try building this plugin for IDA 7.5?

Thanks,
Tom

Hi Rolf,

I read your blog article on this little baby at the time, but only now do I have a version of IDA capable of testing it.

I have spent far too much of the 5 years writing de-obfu for arxan obfuscation, which seems to have been designed explicitly to befuddle IDA, most commonly by splitting a function into as many chunks as possible then attempting to play 3 card monte with the stack pointer.

As far as I can tell, the rules of the game are:

1. Never retn when you can use lea + jmp
2. Never jmp when you can use lea + retn
3. Never manipulate rsp directly when you can push it elsewhere, and pop rsp
4. Never use an 8bit mov imm if a 32bit mov imm would be more annoying
5. cmov is great for everybody
6. Never overrate the importance of have an aligned stack. test rsp, 0Fh then conditionally push 10h or push 18h, and arrange for that value to be applied to the stack at the end.

Not having your brilliance with intermediate disassembly languages (or willingness to commit to Ghidra), this has all been done with byte patching, aided by regex, brace expansion, and nasm -- eventually requiring the re-stitching and relocation of entire functions so that IDA can properly read them.

I'm looking forward to see how much help this project will be, though I fear that it will only be able to help if the stack actually balances.

I'm also looking forward to looking at your ComRAT4 idbs, as I'm also a C++ guy (though I use python for IDA), and it's always educational to see how C++ is actually implemented (though not always simple or fun). Don't even get me started on GCC COW string classes.

Keep up the excellent work, I would definitely take your C++ course -- my hobby (converting Javascript's underscore library to C++latest) is a never ending source of challenges and new skills to be learned.

I'm implementing control flow unflattening in more matured level, related to #7.

I like to debug the code by using Microcode Explorer graph but sometimes (especially in MMAT_GLBOPT1) the output generated by Microcode Explorer is different from optblock_t::func callback dump in the same maturity level (e.g.. dumpBefore-MMAT_GLBOPT1-0.txt), so I can't refer to the graph in debugging.

Do you know the reason?