mn103 Plugin for IDA and xextool released

[groepaz]

what the topic says our small contribution to the xbox360 scene, grab it here: http://hitmen.c02.at/html/xbox360_releases.html ! have fun!

[BlueCop]

thank you very much. =)

[TheSpecialist]

Wow, great news, *much* appreciated !

[anita999]

I try to compile this source with free borland 5.5 compiler under win32, but lots of error message. Is there any one successfully compiling this module in win32 for IDA 4.8?


C:\IDA\sdk\module\mn103>make -D__NT__
MAKE Version 5.2  Copyright (c) 1987, 2000 Borland
        c:\bcc55\bin\bcc32 +c:\IDA\sdk\w32bor.cfg   -ps -v -O-  -D__IDP__  -c re
g.cpp
Borland C++ 5.5.1 for Win32 Copyright (c) 1993, 2000 Borland
reg.cpp:
Error E2268 ../iocommon.cpp 184: Call to undefined function 'get_cfg_filename' i
n function apply_config_file(int)
Error E2034 reg.cpp 62: Cannot convert 'const char * (*)(const char *,char *,uns
igned int)' to 'unsigned int' in function set_idp_options(const char *,int,const
 void *)
Error E2342 reg.cpp 62: Type mismatch in parameter 'device_size' (wanted 'unsign
ed int', got 'const char * (*)(const char *,char *,unsigned int)') in function s
et_idp_options(const char *,int,const void *)
Error E2193 reg.cpp 62: Too few parameters in call to 'choose_ioport_device(cons
t char *,char *,unsigned int,const char * (*)(const char *,char *,unsigned int))
' in function set_idp_options(const char *,int,const void *)
Error E2034 reg.cpp 333: Cannot convert 'const char * (*)(const char *,char *,un
signed int)' to 'unsigned int' in function cdecl notify(processor_t::idp_notify,
...)
Error E2342 reg.cpp 333: Type mismatch in parameter 'device_size' (wanted 'unsig
ned int', got 'const char * (*)(const char *,char *,unsigned int)') in function
cdecl notify(processor_t::idp_notify,...)
Error E2193 reg.cpp 333: Too few parameters in call to 'choose_ioport_device(con
st char *,char *,unsigned int,const char * (*)(const char *,char *,unsigned int)
)' in function cdecl notify(processor_t::idp_notify,...)
*** 7 errors in Compile ***

[groepaz]

the module has been developed and tested with ida4.7 (which i am using). the ida kernel changed in 4.8 and so you need to update the code. *some* (not all) of the things you need to modify are pointed out in the code itself.

[Pandor]

Nice work!
just compiled xextool on my gentoo box and it's working great.

[anita999]

the module has been developed and tested with ida4.7 (which i am using). the ida kernel changed in 4.8 and so you need to update the code. *some* (not all) of the things you need to modify are pointed out in the code itself.

I got it. The source already indicate that certain shall be modified when IDA 4.8 was used. I simply follow the instruction and it works. good job.

[TheSpecialist]

How's the mn103 IDA plugin working for you guys ? I have some problems with 'calls'. IDA sometimes uses 3 bytes for 'call' instead of 5 bytes. Like for instance:

ROM0:9002D6A2                 call    sub_9002D86F
ROM0:9002D6A5                 cmp     0x10, D0
ROM0:9002D6A7                 extb    D0

(3 bytes reserved for the 'call')
While objdump decompiles this correctly as:

   2d6a2:   cd cd 01 a0    call   0x2d86f,[d2,a2],16
   2d6a6:   10
   2d6a7:   10             extb   d0

and uses 5 bytes for the 'call'.

*EDIT*

Calls should be either 5 or 7 bytes long.

[groepaz]

i have fixed the two call opcodes (0xcd and 0xdd) ... source on our website, i'm to lazy to compile it for windows right now :=P

[TheSpecialist]

Works perfectly now, thanks again, Groepaz

[TheSpecialist]

BTW, is there a way to let IDA use this new info, in an 'old' project ? I mean, if I load a previously saved project, it still shows the wrong call info. If I position the curser at such a 'wrong' call and then change the code to 'data' and back to 'code', then it fixes it. Is there a way to do this for the complete project ?

[groepaz]

mmh good question....maybe "reanalyze program" ?

[anita999]

one more question:
after analyzing the bin file, we can find code like this

ROM0:9002D8DC                 mov     0x90004000, D1

the 0x90004000 shall be a address to the firmware itself. Since I am loading the firmware to 90000000 space. But how shall I make IDA to create a data Xref link from this code to 0x90004000? Is there an automatic way? Shall I modify the mo103 module source code or something else?
because I saw in some other codes IDA will create the data Xref directly. So I am wondering how this can happen automatically.
you can see one more interesting thing is that there is indeed a data xref created on address of 0x90004000, but it's from code 0x9001a889 instead of the code above.


ROM0:90004000 word_90004000:  .word 0xFFFF            ! DATA XREF: sub_9001A889r

ROM0:9001A889                 movbu   (word_90004000), D0

but more interesting is that in 9001a889, you can't find any link to 90004000. So this data xref is somehow not complete. How can we fix it?

[groepaz]

i have updated it again...

Code:

20/01/2006
- fixed instructions which used sign-extended 16bit arguments,
bug reported by TheSpecialist:

affected instructions were: MOV, CALL, ADD, CMP, JMP, CALLS, UDF

- enabled "bad logic" warning to catch some possible mistakes

- data xrefs on immediate operands are automatically created

[TheSpecialist]

Great job again, Groepaz, lots of respect

[groepaz]

Thanks for the flowers :=)

btw if anyone gets the "bad logic" warning, please let me know so i can fix it. there might also be a problem with 8bit arguments which should be sign extended, i havent checked those (i usually prefer "0xff" instead of  "-1")

[zobyone]

Hi Groepaz,

Thanks for the wonderful tool !

I have noticed a little mistake in the plugin :

I will quote source code to explain :

Look at file ANA.Cpp line 80 :

Code:

case 0x6: // movhu (Am),Dn
cmd.itype = MN103_movhu;
cmd.Op1.type = o_displ;
cmd.Op1.addr = 0;
cmd.Op1.reg = AM_0(b1);
cmd.Op2.type = o_reg;
cmd.Op2.reg = AN_2(b1); // <-- Shouldn't be DN_2 ???
cmd.size=2;
break;

Hope it helps,

CU


Edit : Movbu is also affected look on line 68 :

Code:

case 0x4: // movbu (Am),Dn
cmd.itype = MN103_movbu;
cmd.Op1.type = o_displ;
cmd.Op1.addr = 0;
cmd.Op1.reg = AM_0(b1);
cmd.Op2.type = o_reg;
cmd.Op2.reg = DN_2(b1);//Z1 Shall be DN_2 ????
cmd.size=2;
break;

Hopefully when you replace the plugin, ida corrects the disasm automatically !

[groepaz]

thanks for reporting, i've updated the source again...

Hopefully when you replace the plugin, ida corrects the disasm automatically !

yes ofcourse, thats the beauty of using the ida kernel when writing a disasm

[SpenZerX]

I have changed the plugin, but the only way to correct the disasm is to undefine everything and then reanalyze.

i also tried the reanalyze button in options/general menu. no luck.

ROM:9000100B                 call    INIT_E, [], 0
ROM:90001010                 call    CHANGE_CC28_CC1C, [], 0
ROM:90001015                 call    sub_90001981, [], 4
ROM:9000101A                 call    INIT_F, [], 0
ROM:9000101F                  clr     D0

is the empty [] in the call instruction a bug?

Spenzer

[anita999]

For anyone who suffers from applying a new pluging. I got a more quicker/safer way.
1st save your current definitions to a IDC file, which can contents all definitions including code, data, functions, structures, names,etc..
2nd reload the bin file, overite the database, apply the IDC file which includes your previous definition.
and that's done. well, give it a try and tell us whether it works or not.