Thanks to visit codestin.com
Credit goes to github.com

Skip to content

Some errors in cfg recovery #22

@yrp604

Description

@yrp604

Hello,

First, amoco seems really cool. Thanks!

I have an issue, and a question

Issue:
cfg recovery seems to be a bit broken currently. I have a simple 'puts("hello world")' elf which I am using for testing. the lsweep method recovers most of the basic blocks, as expect however others don't seem to get past the first basic block:

>>> p = amoco.system.loader.load_program('hi32')
>>> z = amoco.lforward(p)
>>> G=z.getcfg()
>>> print G.C
[<grandalf.graphs.graph_core object at 0x7fa70251bf10>, <grandalf.graphs.graph_core object at 0x7fa7024660d0>]
>>> print G.C[0].sV
0.| <node [0x8048380] at 0x7fa70251bb90>
>>> print G.C[1].sV
0.| <node [#PLT@__libc_start_main] at 0x7fa7079073d0>
1.| <node [@__libc_start_main] at 0x7fa7024def50>

Furthermore, some methods error:

>>> z = amoco.fbackward(p)
>>> z.getcfg()
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
  File "/usr/local/lib/python2.7/dist-packages/amoco/main.py", line 267, in getcfg
    for x in self.itercfg(loc): pass
  File "/usr/local/lib/python2.7/dist-packages/amoco/main.py", line 289, in itercfg
    if self.check_ext_target(t):
  File "/usr/local/lib/python2.7/dist-packages/amoco/main.py", line 261, in check_ext_target
    self.update_spool(e.v[1],t.parent)
  File "/usr/local/lib/python2.7/dist-packages/amoco/main.py", line 206, in update_spool
    T = self.get_targets(vtx,parent)
  File "/usr/local/lib/python2.7/dist-packages/amoco/main.py", line 373, in get_targets
    func.map[pc] = mpc
  File "/usr/local/lib/python2.7/dist-packages/amoco/code.py", line 33, in map
    self.helper(self._map)
  File "/usr/local/lib/python2.7/dist-packages/amoco/code.py", line 42, in helper
    if self._helper: self._helper(self,m)
AttributeError: _helper

Although interestingly, running it again does not error, it still doesn't recovery the cfg:

>>> z.getcfg()
<amoco.cfg.graph object at 0x7fa702511a90>

(I've also noticed running other cfg recoveries twice gives different results the second time)

I think this these errors stem from certain function calls not getting resolved properly, but I'm not sure:

>>> print n.data
# --- block 0x8048380 ---
0x8048380  '31ed'           xor         ebp, ebp
0x8048382  '5e'             pop         esi
0x8048383  '89e1'           mov         ecx, esp
0x8048385  '83e4f0'         and         esp, 0xfffffff0
0x8048388  '50'             push        eax
0x8048389  '54'             push        esp
0x804838a  '52'             push        edx
0x804838b  '6820850408'     push        #__libc_csu_fini
0x8048390  '68b0840408'     push        #__libc_csu_init
0x8048395  '51'             push        ecx
0x8048396  '56'             push        esi
0x8048397  '687b840408'     push        #main
0x804839c  'e8afffffff'     call        *0x8048350
>>> i = n.data.instr[-1]
>>> print i.misc['to']
0x8048350
>>> p.mmap.read(0x8048350, 4)
['\xff%(\x97']

Im happy to provide the binaries, and/or any other info that would be helpful. I spent some time looking around trying to solve it, but am still wrapping my head around how everything is set up.

Question:
Im interested in tagging the memory sections with their flags (i.e read, write execute). I originally hacked it onto 'mo', before I noticed that MemoryMap has an unused 'perm' attribute. Is this the correct spot to store that info?

Alternatively, the info is stored in p.bin.Phdr. Would it be cleaner to just query that?

Thanks!

Metadata

Metadata

Assignees

No one assigned

    Labels

    No labels
    No labels

    Projects

    No projects

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions