IDArlingTeam / IDArling

Collaborative Reverse Engineering plugin for IDA Pro & Hex-Rays
https://idarling.re
GNU General Public License v3.0
660 stars 99 forks source link

Local type issue (TBI) #63

Closed NeatMonster closed 6 years ago

NeatMonster commented 6 years ago

However, another problem: open the local types list and add a new type:

typedef int myint;

This won't be copied to other IDA copies. When I defined one more typedef:

typedef int iii;

my first definition got copied, but incorrectly:

50 myint Error typedef myint

NyaMisty commented 6 years ago

Can we reproduce it on a clean idb? I currently has no access to computers, could you please to help me check it?

NyaMisty commented 6 years ago

Reproduced.. When a user changed the local type, the IDA will first delete it, and then re-create it. First, you missed + 1 in [events.py Line 303 and 304] (https://github.com/IDArlingTeam/IDArling/blob/master/idarling/core/events.py#L304), that's why the new type aren't synced. Then you you fixed the struct collpase issue by omitting the del_numbered_type, but doing so will fail when changing the local type, that's the source of error.

NyaMisty commented 6 years ago

Another bug, you used the tinfo_t.get_numbered_type, but this function will give you a typedef to the target type, instead of the type it self. We should use the ida_typeinf.get_numbered_type() instead.

NyaMisty commented 6 years ago

But the get_numbered_type aren't usable before 7.0 sp1, and unfortunately I does not have a newer version than 7.0 170914 Here we have two approaches:

  1. use the idc_get_local_type_raw, which internally uses get_numbered_type, but it does not gave us the fieldcmt
  2. use the ctypes to call the get_numbered_type manually.
NeatMonster commented 6 years ago

@NyaMisty You were absolutely right. Sadly, even the set_numbered_type bindings are broken on the latest version of IDA. So I decided to go the ctypes road as you can see in my commit https://github.com/IDArlingTeam/IDArling/commit/f89c83505ab93da391ad9f8cc41365bb0d8930d9.

I'll report it to Hex-Rays so that we can remove this workaround in the future (cc @patateqbool).