This bug was fixed two weeks ago. Are you using r2 from git? On Jul 22, 2013, at 8:06, Andrew Case <[email protected]> wrote:
> One instruction I found not correct in a function I was analyzing: > > # file libd.so > libd.so: ELF 32-bit LSB shared object, ARM, version 1 (SYSV), > dynamically linked (uses shared libs), stripped > # /usr/bin/radare2 -a arm -b 16 libd.so > [0x0001db80]> pd@0x687f4 > <snip> > 0x0006882c 4ff48070 mov.w r0, #256 > 0x00068830 7944 add r1, pc > 0x00068832 dcf7 ; <UNDEFINED> > instruction: 0xf7dc0000 > 0x00068836 c4f8b000 str.w r0, [r4, #176] > 0x0006883a 0020 movs r0, #0 > > IDA Pro disassembles the opcodes at 0x00068832 as: > > 00068832 DC F7 51 FA BL <function name> > > so for some reason, r2 is reading two sets of 0 where IDA is reading "51 > FA"... > > On Fri, Jul 19, 2013 at 6:04 AM, pancake <[email protected]> wrote: >> I'm sorry to tell you that, besides you like anal, it's not the library you >> are looking for. If you want the mnemonic, just use the op_str(addr) method. >> >> You need to use the RAsm api. I have uploaded another test example for >> ctypes. it should work fine with the swig bindings too: >> >> https://github.com/radare/radare2/blob/master/r2-bindings/ctypes/test-asm.py >> >> If you want to do this from RCore. you have an instance of RAsm inside >> core.assembler. You can also use malloc IO, so you can write bytes in RCore >> IO layer. >> >> If you want to open a full binary file and handle all the symbol, relocs, >> etc.. information i'll reocmmend you to use RCore. >> >> To get one opcode disassembled: >> >> opstr = rc.cmd_str ("pi 1 @"+address) # get >> >> The analysis in ARM is far from complete, arm assembler works for most >> common opcodes (let me know if you need any other opcode), and the >> disassembler is complete for thumb/thumb2, 32bit and 64bit arm. >> >> The problem with analysis is that i've recently decided to switch to another >> paradigm (ESIL) and it's not yet ready, so you cant use this yet. >> >> The plan is to keep current RAnalOp struct to keep basic opcode information >> (type of opcode, address, size, memory references, branching destinations, >> etc..) and use ESIL to get a complete intermediate representation of the >> opcode. >> >> The src[] field of RAnalOp in arm is not implemented, and its not suposed to >> show the 'source' of the opcode', it contains an array of all the 'source' >> elements of the opcode, this is .. a list of registers and memory addresses. >> >> THe problem with this approach is that using structs with nested fields in >> arrays takes a lot of memory and it's hard to maintain. >> >> My plan is to have ESIL implemented for r2-1.0, i have a long todo list >> before working on this right now, but the basic api design is done, feel >> free to suggest ideas or contribute with code. >> >> >> >> >> On 07/19/13 05:08, Andrew Case wrote: >>> >>> I have a test script that seems to be getting where I want, but having >>> an issue with swig and accesing the source information for an >>> instruction. Here is the simple script: >>> >>> ----------------- >>> import sys, os, struct >>> >>> from r2 import r_core >>> >>> def main(): >>> fname = sys.argv[1] >>> start = int(sys.argv[2], 16) >>> >>> rc = r_core.RCore() >>> rc.file_open(fname, 0, 0) >>> rc.bin_load("") >>> >>> rc.anal_all() >>> >>> end = start + 40 >>> >>> while start < end: >>> a_op = rc.op_anal(start) >>> >>> if a_op.length == 0: >>> print "0 len instr at %d" % start >>> break >>> >>> print dir(a_op.src) >>> print a_op.src[0] >>> >>> start = start + a_op.length >>> >>> if __name__ == "__main__": >>> main() >>> >>> --------- >>> >>> Which outputs: >>> >>> # python gen.py test 0x4004e4 >>> ['__class__', '__cmp__', '__delattr__', '__doc__', '__eq__', >>> '__format__', '__ge__', '__getattribute__', '__gt__', '__hash__', >>> '__hex__', '__init__', '__int__', '__le__', '__long__', '__lt__', >>> '__ne__', '__new__', '__oct__', '__reduce__', '__reduce_ex__', >>> '__repr__', '__setattr__', '__sizeof__', '__str__', >>> '__subclasshook__', 'acquire', 'append', 'disown', 'next', 'own'] >>> Traceback (most recent call last): >>> File "gen.py", line 30, in <module> >>> main() >>> File "gen.py", line 25, in main >>> print a_op.src[0] >>> TypeError: 'SwigPyObject' object is unsubscriptable >>> >>> >>> So I googled how to access array indexes in Swig objects and it seems >>> like the package needs to define access to them through get & set >>> functions. I tried looking for radare's version of these but could not >>> find them. Should I try to write my own or are they just somewhere I >>> could not find? >>> >>> Thanks for all the help! >>> >>> On Thu, Jul 18, 2013 at 10:00 PM, Andrew Case <[email protected]> wrote: >>>> >>>> I am still going through the files you pointed to, but I want this >>>> option from your email: >>>> >>>> "Do you want to use rasm api by providing its bytes" >>>> >>>> Basically pass in a chunk of bytes and then have it disassembled with >>>> the instruction/opcode context >>>> >>>> On Wed, Jul 17, 2013 at 12:59 PM, pancake <[email protected]> wrote: >>>>> >>>>> Hi andrew, been busy irl. >>>>> >>>>> Sorry for the readme false hint. Will fix soon. >>>>> >>>>> You may like to read bokken source code as another source for python >>>>> examples using r2 api. >>>>> >>>>> Do you want to use rasm api by providing its bytes or just read binaries >>>>> with rcore like r2 does and call rasm api obeying the rules imposed by >>>>> rbin >>>>> (arch/os/bits) and rio maps/sections? >>>>> >>>>> Im answering from phone right now, but you may find the test-asm.py >>>>> example which should assemble and disassemble an opcode. Just change the >>>>> arch to arm and bits to 16, 32 or 64. >>>>> >>>>> Ranal is used to analyze code. This is: extract low level information >>>>> from the opcode. >>>>> >>>>> To assemble/Disaseemble you should use the rasm api. >>>>> >>>>> Nope, the full r2 api is binded with ctypes and swig. No textual parsing >>>>> is required. The radare.py is there for historic reasons, but it shouldnt >>>>> be >>>>> used for any serious task. >>>>> >>>>> I'll try to type some more examples and will commit them, so you can >>>>> check them for your needs. >>>>> >>>>> >>>>> On Jul 16, 2013, at 7:07, Andrew Case <[email protected]> wrote: >>>>> >>>>>> Thanks. Using the git version and the sys/python.sh I was able to get >>>>>> it installed with the Python bindings. >>>>>> >>>>>> Also, I got the --enable-devel and general process from the README >>>>>> file and its still mentioned in the last version of that file. >>>>>> >>>>>> And, I had another question(s) that hopefully you could help with. >>>>>> What I really want to use radare for is disasm of ARM instructions >>>>>> through python scripting. I am having trouble figuring out how to get >>>>>> it to work though.. >>>>>> >>>>>> I have read the documents for libr (e.g. >>>>>> http://radare.org/vdoc/libr/Radare.RAnal.Op.html ) and I see there are >>>>>> classes defined for them, but after grepping through the source code >>>>>> and using dir() throughout different parts of r2 python bindings, I >>>>>> still cannot find what I am supposed to be using. >>>>>> >>>>>> From what I see of other scripts throughout the git checkout, it seems >>>>>> like much of the python scripting is just calling out to radare and >>>>>> then getting back the text output. Is that the correct way to use it >>>>>> or is there a structured/API for the Python use? >>>>>> >>>>>> The only thing I really found close was "libr/lang/p/radare.py", but >>>>>> this seems to be based on radare v1. >>>>>> >>>>>> If you could just point me to the correct documents and some sample >>>>>> code to get the process started with the latest version of radare that >>>>>> would be great. >>>>>> >>>>>> On Mon, Jul 15, 2013 at 10:01 AM, pancake <[email protected]> wrote: >>>>>>> >>>>>>> Various comments here: >>>>>>> >>>>>>> - in debian/arch/void/gentoo there are binary packages for those >>>>>>> bindings (i >>>>>>> also built a version for windows too) >>>>>>> - it's recommended to use git version >>>>>>> - enable-devel is deprecated >>>>>>> - bindings are inside r2-bindings subdirectory >>>>>>> - r.py is just a r_core_cmd() wrapper api, not real api, just parses >>>>>>> commands text instead. >>>>>>> - current git have two different implementation of the python >>>>>>> bindings, both >>>>>>> based on valabind (ctypes and swig) >>>>>>> - both implementations should be compatible and same code should run >>>>>>> on both >>>>>>> - there are scripts in sys/*.sh to automate those builds >>>>>>> - You may like to run sys/python.sh >>>>>>> - the bindings are compiled by the farm (see bin.rada.re and >>>>>>> ci.rada.re) >>>>>>> - "import radare" are the old text-based bindings for radare1 >>>>>>> - see r2-bindings/python/test-*.py to see some code examples. >>>>>>> - if you want to build bindings for windows see doc/windows >>>>>>> >>>>>>> Hope this helps :) >>>>>>> >>>>>>> Here's a sample program: >>>>>>> >>>>>>> from r2.r_bin import * >>>>>>> b = RBin () >>>>>>> b.load ("/bin/ls", False) >>>>>>> baddr= b.get_baddr () >>>>>>> print '-> Sections' >>>>>>> for i in b.get_sections (): >>>>>>> print 'offset=0x%08x va=0x%08x size=%05i %s' % ( >>>>>>> i.offset, baddr+i.rva, i.size, i.name) >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> On 07/15/13 04:20, Andrew Case wrote: >>>>>>>> >>>>>>>> >>>>>>>> Hello, >>>>>>>> >>>>>>>> I have compiled radare with python bindings following the >>>>>>>> instructions >>>>>>>> in the source code: >>>>>>>> >>>>>>>> ./configure --prefix=/usr --enable-devel --enable=python >>>>>>>> >>>>>>>> but I cannot import radare as it will error with being unable to find >>>>>>>> a module named 'r', which from reading docs and source code seems to >>>>>>>> be the module that drives everything. >>>>>>>> >>>>>>>> I did a search across disk and could not find a "r.py" file. >>>>>>>> >>>>>>>> Is there other documentation I should be following? >>>>>>>> _______________________________________________ >>>>>>>> radare mailing list >>>>>>>> [email protected] >>>>>>>> http://lists.nopcode.org/listinfo.cgi/radare-nopcode.org >>>>>>> >>>>>>> >>>>>>> _______________________________________________ >>>>>>> radare mailing list >>>>>>> [email protected] >>>>>>> http://lists.nopcode.org/listinfo.cgi/radare-nopcode.org > _______________________________________________ radare mailing list [email protected] http://lists.nopcode.org/listinfo.cgi/radare-nopcode.org
