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
