IDA SDK C++ tricks and tips
IDA offers a good amount of info about functions but its SDK is basically undocumented for accessing some of it. Fortunately ida64.dll can be decompiled and the little info the SDK docs understood.
Functions: func_t offers function details including members: Code:
uval_t frame; ///< netnode id of frame structure - see frame.hpp Code:
size_t num = get_func_qty(); find_regvar(f, ea, _) although it is undocumented can accept a nullptr for the third argument and regardless it will always load the regvars member on first use. Presumably one could find the register variables by giving every possible canonical register name via enumeration of ph.reg_names[] array but this would be over doing it as regvars can be populated with a nullptr and accessing the array directly. get_spd(f, ea), get_effective_sp(f, ea), get_sp_delta(f, ea) will always populate the points array if you pass the function pointer on first use. Although IDA claims a null pointer is possible, this function will always return 0 until it is called at least once on the function in question with that filled in. It does not call get_func(ea) for you like you would think. Totally misdocumented feature. recalc_spd(ea) will not always work either if one of the get_*sp* functions has not been used first - it works in some cases depending on which address in the function is used. If the ea for recalc_spd is part of a function chunk with no sp changes - it will not do anything leaving the points null. It actually walks through instructions in the particular function chunk/tail entry of the ea only so if there is a stack change in that exact one it will populate but its highly unlikely one would know this in advance. With that in mind, the stack points could be enumerated by going through every assembly instruction in the function using the appropriate enumeration functions, and querying get_*sp* functions to gather the info. But since we know the function has the array already such intensive searching is fortunately not necessary. read_regargs(f) populates the regargs and is the only way to do so. They have to be accessed directly. Now you have a regarg_t structure so what about this strange type_t *type; member? Mostly we want tinfo_t not type_t raw data. Well this again is a poorly documented and tricky to access structure. Obviously we do not want to parse through it ourselves as its not SDK version portable, and its packed in a really detailed format. But if you try to load it directly it will cause corruption and a crash or bad data. Code:
if (f->regargs[i].type != nullptr) { Code:
decl bool ida_export deserialize_tinfo(tinfo_t *tif, const til_t *til, const type_t **ptype, const p_list **pfields, const p_list **pfldcmts); Code:
func_tail_iterator_t fti(pfn); Code:
func_tail_iterator_t fti(pfn); So get_llabel(f, ea) or get_name(f, ea) will reliably do the job and there is no other suitable candidate though get_llabel_ea(f, nullptr) and get_name_ea(f, nullptr) might work if they accept a null pointer for the string. IDA provides a very practical SDK for a very practical purpose. With a very big support price tag for it, it is no wonder there is poor documentation and lack of consistency. Working on the clock, it would be easier to justify a paper trail of support emails asking about these type of details rather than painstakingly tracking them out through trial and error or reverse engineering SDK lib files or the ida64.dll. Perhaps these are part of IDA Pro's trade secrets, if you were to think of it as such. It was quite difficult to get these simple things working correctly as none of them are properly documented. I hope this helps someone on their own IDA SDK development efforts. In a multithreaded plugin, preloading everything is actually a necessity to minimize thread safety issues around various unsafe database access to race conditions. By preloading all of these structures, even if you want to access them using nicer API methods, it will not cause any database calls. Unfortunately the IDA SDK is designed for single threaded use mostly so doing a dump or lots of UI thread callbacks would be the only other options. But this idea will mitigate all contention except those caused by the user's own interaction changing data structures in use. |
Another interesting function is execute_sync with MFF_NOWAIT which is needed when a thread doing work may need to be interrupted to prevent deadlock.
Code:
THREAD_SAFE inline int execute_sync(exec_request_t &req, int reqf) { return callui(ui_execute_sync, &req, reqf).i; } Code:
THREAD_SAFE inline bool cancel_exec_request(int req_id) To deal with this, the best I could come up with was using both a semaphore to track the exec request completion, along with a termination flag and a mutex around that to prevent race conditions: Global (hopefully stored somewhere referenceable from a singular global object): Code:
bool exiting = false; Code:
{ //must be a locked unit otherwise race condition can occur Code:
struct execFunctor : public exec_request_t Now you can just wrap any code into a lambda as an argument to std::function<void()> to bind it and very easily execute anything on the main thread taking into account data thread safety issues if any. This allows for cancellable long running operations. Another area of concern is process creation using Code:
launch_process_params_t procInf; Code:
if (pi.hThread != INVALID_HANDLE_VALUE) CloseHandle(pi.hThread); Any uses of q functions with a create such as qthread_create must always have a matching free e.g. qthread_free and in this case should always have a qthread_join as well. Although qthread_kill is possible, it is a temporary workaround for deeper architectural issues or an emergency as the side effects nearly always outweigh the benefits and it could destabilize the IDA process. Again all of these things were discovered, and not mentioned in any documentation. |
Here is the final clean code of the above which is polling-free since polling technically should not be done in a waiting loop ever in modern OS code where the OS can always schedule that much more safely and efficiently:
Code:
/// Execute code in the main thread - to be used with execute_sync(). Code:
{ //must be a locked unit otherwise race condition can occur Code:
int idx = -1; |
We see in graph.hpp the following events:
Code:
grcode_user_title, ///< render node title of a user-defined graph. Quote:
|
Quote:
https://www.hexblog.com/?p=250 not much has changed since then, here is info for ida 7.3 (i can confirm that this works, including complicated cases such as plugins loaded by qt itself--of course these too must be built against an appropriately configured qt installation): https://www.hexblog.com/?p=1341 if you want to build qt without so much useless garbage, this e.g. will work: Code:
..\qt-everywhere-opensource-src-5.6.3\configure -prefix C:/Qt/5.6.3.0 -debug-and-release -force-debug-info -platform win32-msvc2017 -opensource -confirm-license -shared -no-compile-examples -nomake examples -nomake tests -nomake tools -opengl desktop -no-warnings-are-errors -ltcg -no-rtti -sse2 -sse3 -ssse3 -sse4.1 -sse4.2 -avx -no-ssl -no-openssl -no-dbus -no-audio-backend -no-wmf-backend -no-qml-debug -no-native-gestures -mp -skip qt3d -skip qtactiveqt -skip qtandroidextras -skip qtcanvas3d -skip qtconnectivity -skip qtdeclarative -skip qtdoc -skip qtenginio -skip qtgraphicaleffects -skip qtimageformats -skip qtlocation -skip qtmacextras -skip qtmultimedia -skip qtquickcontrols -skip qtquickcontrols2 -skip qtscript -skip qtsensors -skip qtserialbus -skip qtserialport -skip qtsvg -skip qttools -skip qttranslations -skip qtwayland -skip qtwebchannel -skip qtwebengine -skip qtwebsockets -skip qtwebview -skip qtx11extras -skip qtxmlpatterns -qtnamespace QT https://www.hexblog.com/?p=1261 see hexblog for more entries for previous versions, but again not much changes from release to release regarding qt. |
All times are GMT +8. The time now is 10:58. |
Powered by vBulletin® Version 3.8.8
Copyright ©2000 - 2024, vBulletin Solutions, Inc.
Always Your Best Friend: Aaron, JMI, ahmadmansoor, ZeNiX