Closed geekscrapy closed 2 years ago
looks like a bug on iIj
command.
can you provide the binary? or this happens with any pdb binary?
which version of rizin are you using?
can you provide the binary? or this happens with any pdb binary?
The binary is 6a09bc6c19c4236c0bd8a01953371a29 (a version of procdump), available on VirusTotal
rizin 0.3.0 @ darwin-x86-64
commit: 0e11486f36aa784b471d8d4ecf291a8d962b4c47, build: 2021-07-07__18:43:13
Seems to work with: rzpipe.open(p, flags=['-2']).cmdj('iIj')
looks like a bug on
iIj
command.
More than a problem in iIj
it seems a problem in conversion from json to python object.
In [19]: rzpipe.open('/home/rschiron/Downloads/6a09bc6c19c4236c0bd8a01953371a29').cmdj('iIj') [15/358]
rz_config_set: variable 'cfg.oldshell.autocompletion' not found
Out[19]:
{'arch': 'x86',
'baddr': 4194304,
'binsz': 651424,
'bintype': 'pe',
'bits': 32,
'canary': False,
'retguard': False,
'class': 'PE32',
'cmp.csum': '0x000a52d4',
'compiled': 'Mon Apr 24 22:38:08 2017',
'compiler': '',
'crypto': False,
'dbg_file': 'C:\\Builds\\13810\\Tools\\ProcDump_master\\bin\\Win32\\Release\\procdump.pdb',
'endian': 'little',
'havecode': True,
'hdr.csum': '0x000a52d4',
'guid': '35DC14947AF44564BC0C59336A3D8F741',
'intrp': '',
'laddr': 0,
'lang': 'c',
'linenum': False,
'lsyms': False,
'machine': 'i386',
'maxopsz': 16,
'minopsz': 1,
'nx': True,
'os': 'windows',
'overlay': True,
'cc': 'cdecl',
'pcalign': 0,
'pic': True,
'relocs': False,
'rpath': '',
'signed': True,
'sanitiz': False,
'static': False,
'stripped': False,
'subsys': 'Windows CUI',
'va': True,
'checksums': {}}
In [20]: rzpipe.open('/home/rschiron/Downloads/6a09bc6c19c4236c0bd8a01953371a29').cmdJ('iIj')
rz_config_set: variable 'cfg.oldshell.autocompletion' not found
Out[20]: X(arch='x86', baddr=4194304, binsz=651424, bintype='pe', bits=32, canary=False, retguard=False, _7='PE32', _8='0x000a52d4', compiled='Mon Apr 24 22:38:08 2017', compiler='', crypto=
False, dbg_file='C:\\Builds\\13810\\Tools\\ProcDump_master\\bin\\Win32\\Release\\procdump.pdb', endian='little', havecode=True, _15='0x000a52d4', guid='35DC14947AF44564BC0C59336A3D8F741', in
trp='', laddr=0, lang='c', linenum=False, lsyms=False, machine='i386', maxopsz=16, minopsz=1, nx=True, os='windows', overlay=True, cc='cdecl', pcalign=0, pic=True, relocs=False, rpath='', s$
Notice how the problem is in cmdJ
and not in cmdj
.
Is this still a problem with the latest Rizin? @geekscrapy @wargio @ret2libc
Is this still a problem with the latest Rizin? @geekscrapy @wargio @ret2libc
I think we did nothing to fix this.
>>> import rzpipe
>>> rzpipe.open('6a09bc6c19c4236c0bd8a01953371a29').cmdJ('iIj')
X(arch='x86', baddr=4194304, binsz=651424, bintype='pe', bits=32, retguard=False, _6='PE32', _7='0x000a52d4', compiled='Mon Apr 24 22:38:08 2017 UTC+1', dbg_file='C:\\Builds\\13810\\Tools\\ProcDump_master\\bin\\Win32\\Release\\procdump.pdb', endian='LE', _11='0x000a52d4', guid='35DC14947AF44564BC0C59336A3D8F741', laddr=0, lang='c', machine='i386', maxopsz=16, minopsz=1, os='windows', overlay=True, cc='cdecl', pcalign=0, signed=True, subsys='Windows CUI', stripped=False, crypto=False, havecode=True, va=True, sanitiz=False, static=False, linenum=False, lsyms=False, canary=False, PIE=True, RELROCS=False, NX=True)
and
[0x004171e7]> iIj
{"arch":"x86","baddr":4194304,"binsz":651424,"bintype":"pe","bits":32,"retguard":false,"class":"PE32","cmp.csum":"0x000a52d4","compiled":"Mon Apr 24 22:38:08 2017 UTC+1","dbg_file":"C:\\Builds\\13810\\Tools\\ProcDump_master\\bin\\Win32\\Release\\procdump.pdb","endian":"LE","hdr.csum":"0x000a52d4","guid":"35DC14947AF44564BC0C59336A3D8F741","laddr":0,"lang":"c","machine":"i386","maxopsz":16,"minopsz":1,"os":"windows","overlay":true,"cc":"cdecl","pcalign":0,"signed":true,"subsys":"Windows CUI","stripped":false,"crypto":false,"havecode":true,"va":true,"sanitiz":false,"static":false,"linenum":false,"lsyms":false,"canary":false,"PIE":true,"RELROCS":false,"NX":true}
I've only tested with one sample and one command (
iI
), but I dont seem to get the same details when I use:As when I do (in
ptpython
):As you can see, there are some fields which as represented as
_6
,_7
,_11
. So the data is there, just with the wrong name.