I believe the equivalent function from a plugin is ua_code() - see ua.hpp. IIRC, you may need to call autoWait() afterwards if you need to wait for the resultant automated analysis.
There is still one problem. When there is already an instruction at ie eip+1, i the plugin doesnt convert the bytes at eip to code (if the new instructionsize if bigger than 1). Does anybody know how to fix this?
A workaround would be to set everything at eip + instruction size to data and then eip back to code. but i think this is a little bit gay (and slow during tracing).
> bodzcount: There is still one problem. When there is already an instruction at ie eip+1, i the plugin doesnt convert the bytes at eip to code (if the new instructionsize if bigger than 1). Does anybody know how to fix this?
>
> A workaround would be to set everything at eip + instruction size to data and then eip back to code. but i think this is a little bit gay (and slow during tracing).
I currently use auto_make_code in x86emu. Generally IDA won't undefine things automatically which is why you have a problem if the thing at eip+1 is already code and the thing at eip is a multi-byte instruction.
Your workaround would be something like:
int len = ua_ana0(eip);
do_unknown_range(eip, len, DOUNK_EXPAND | DOUNK_DELNAMES);
ua_code(eip);
ah sorry i have found your codeCheck routine. I have missed it, because you don't execute it for every instruction while running. Do you have a reason for that?
I am not sure if your routine works that way, because if you have unknown byte at eip and a ie data at eip+1, auto_make_code will fail to convert eip to code.
At the moment I only check when control returns to the user because I did not want to slow things down to a crawl by checking at the beginning of every instruction. It could be a on/off option. The only check I make at the moment is whether the item at eip is already defined or not, and if it is I undefine it.
Note: Registration is required to post to the forums.