Implicitly Setting an Architecture

[theqlabs]

I have issues (Ubu 14.04, lldb 3.7) with voltron views recognizing architecture types. I tried compiling from both clang and gcc.

file reports: ELF 64-bit LSB executable, x86-64, version 1 (SYSV), dynamically linked (uses shared libs), for GNU/Linux 2.6.24, BuildID[sha1]=, not stripped

I am thinking about just modifying register.py to implicitly set an architecture - I could submit a pull request if there's no resources to support this. I realize this is more a feature request than a bug. It looks like we could possibly just add an argument to configure_subparser and then I would have to spend a few minutes digging into where targets sets it to propagate properly. Shouldn't be too difficult. Let me know if you think i should just do it and submit a pull request.

Regards,

-- q

[snare]

I'm not sure I understand. Is it misidentifying the architecture and displaying the wrong registers? The architecture is retrieved from the current inferior and used to determined which register template to use. If it's doing this incorrectly I'd rather fix it than add another flag.

[theqlabs]

I have tried different compilers and configs and i continue to get "Architecture 'None' not supported" from my "view register -v" and "Unhandled exception <type 'exceptions.Exception'> disassembling: Unsupported architecture: None" from my view stack ... etc.

No matter how I compile the binary I want to debug, I continue to get "None" as the target architecture.

[snare]

Would you mind trying this again at some point? I've rewritten a bunch of stuff and I'm hoping this is just resolved as a side effect :)

[snare]

If not, could you send me a debug log/binary to try/etc?

[theqlabs]

Currently traveling in South America happy to try it out again, will respond soon. Thanks for all the work man, lately it's been working very well within my Vagrant Ubuntu 14.04 64 bit VM.

On Mon, Dec 28, 2015, 9:46 PM snare notifications@github.com wrote:

If not, could you send me a debug log/binary to try/etc?

— Reply to this email directly or view it on GitHub https://github.com/snare/voltron/issues/82#issuecomment-167703745.

[snare]

No rush man, thank you :)

[snare]

I just rewrote the whole guts of it to work properly on Linux/GDB. Currently squashing (hopefully) the last few bugs.

[alopatindev]

Probably I've got the same issue. Steps to reproduce:

1)

$ echo "#include <stdio.h>\nint main(){puts(\"hey\");return 0;}" > hello.c && clang hello.c -g -o hello && file hello && lldb ./hello
hello: ELF 64-bit LSB executable, x86-64, version 1 (SYSV), dynamically linked (uses shared libs), for GNU/Linux 2.6.32, not stripped
Voltron loaded.
Run `voltron init` after you load a target.
(lldb) target create "./hello"
Current executable set to './hello' (x86_64).
(lldb) b main
Breakpoint 1: where = hello`main + 25 at hello.c:2, address = 0x0000000000400579
(lldb) r
Process 26021 launched: './hello' (x86_64)
Process 26021 stopped
* thread #1: tid = 26021, 0x0000000000400579 hello`main + 25 at hello.c:2, name = 'hello', stop reason = breakpoint 1.1
    frame #0: 0x0000000000400579 hello`main + 25 at hello.c:2
   1    #include <stdio.h>
-> 2    int main(){puts("hey");return 0;}
(lldb)

2) In the other terminal $ voltron view register

Gives the red text "Architecture 'None' not supported".

I use Gentoo GNU/Linux with llvm-3.7.1, gdb-7.10.1 and python-2.7.10

Other dependencies installed:

scruffington-0.3.1
requests-2.6.0
requests-unixsocket-0.1.4
blessed-1.14.1
scruffy-0.3
rl-2.4
snowballstemmer-1.2.0
blinker-1.3
aniso8601-0.83
sphinx_rtd_theme-0.1.9
alabaster-0.7.6
simplejson-3.8.1
itsdangerous-0.24
simplejson-3.8.1
Babel-2.1.1
docutils-0.12
itsdangerous-0.24
werkzeug-0.9.6
flask-0.10.1
sphinx-1.3.1
flask-restful-0.2.12
pygments-2.0.2

P.S.: With gdb (7.10.1) it's even worse (might be unrelated): when I run voltron view register I see a frozen black emptiness in the terminal.

Before that I had gdb-7.9.1 installed and I saw the same black emptiness for a few seconds and then an exception:

$ voltron view register
Encountered an exception while running the view 'RegisterView':
Traceback (most recent call last):
  File "/usr/lib64/python2.7/site-packages/voltron/main.py", line 53, in main
    inst.run()
  File "/usr/lib64/python2.7/site-packages/voltron/view.py", line 239, in run
    self.render()
  File "/usr/lib64/python2.7/site-packages/voltron/plugins/view/register.py", line 306, in render
    api_request('registers', block=self.block))
  File "/usr/lib64/python2.7/site-packages/voltron/core.py", line 376, in send_requests
    t.join()
  File "/usr/lib64/python2.7/threading.py", line 949, in join
    self.__block.wait()
  File "/usr/lib64/python2.7/threading.py", line 340, in wait
    waiter.acquire()
  File "/usr/lib64/python2.7/site-packages/voltron/view.py", line 329, in sigwinch_handler
    self.do_render()
  File "/usr/lib64/python2.7/site-packages/voltron/view.py", line 309, in do_render
    self.fmt_body = self.body
AttributeError: 'RegisterView' object has no attribute 'body'

The server runs fine, with both gdb versions:

$ wget -O - http://localhost:5555/api/request
--2016-01-17 18:31:48--  http://localhost:5555/api/request
Resolving localhost... ::1, 127.0.0.1
Connecting to localhost|::1|:5555... failed: Connection refused.
Connecting to localhost|127.0.0.1|:5555... connected.
HTTP request sent, awaiting response... 405 METHOD NOT ALLOWED
2016-01-17 18:31:48 ERROR 405: METHOD NOT ALLOWED.

[theqlabs]

I retested with recent builds on Ubuntu Trusty 64 and LLVM 3.7 and have gotten the same black screen. I personally think its llvm 3.7 but I havent tracked down whats going on yet. Doesnt happen on my Trusty/llvm 3.4 build

• I have other issues with 3.7 which is why I refuse to upgrade.

Can you try with a llvm 3.4 build? id be curious to see if it still happens.

On Sun, Jan 17, 2016, 7:52 AM Alexander Lopatin notifications@github.com wrote:

Probably I've got the same issue. Steps to reproduce:

1)

$ echo "#include \nint main(){puts(\"hey\");return 0;}" > hello.c && clang hello.c -g -o hello && lldb ./hello Voltron loaded. Run voltron init after you load a target. (lldb) target create "./hello" Current executable set to './hello' (x86_64). (lldb) b main Breakpoint 1: where = hello`main + 25 at hello.c:2, address = 0x0000000000400579 (lldb) r Process 26021 launched: './hello' (x86_64) Process 26021 stopped

• thread #1: tid = 26021, 0x0000000000400579 hellomain + 25 at hello.c:2, name = 'hello', stop reason = breakpoint 1.1 frame #0: 0x0000000000400579 hellomain + 25 at hello.c:2 1 #include -> 2 int main(){puts("hey");return 0;} (lldb)

2) In the other terminal $ voltron view register

Gives the red text "Architecture 'None' not supported".

I use Gentoo GNU/Linux with llvm-3.7.1, gdb-7.10.1 and python-2.7.10

Other dependencies installed:

scruffington-0.3.1 requests-2.6.0 requests-unixsocket-0.1.4 blessed-1.14.1 scruffy-0.3 rl-2.4 snowballstemmer-1.2.0 blinker-1.3 aniso8601-0.83 sphinx_rtd_theme-0.1.9 alabaster-0.7.6 simplejson-3.8.1 itsdangerous-0.24 simplejson-3.8.1 Babel-2.1.1 docutils-0.12 itsdangerous-0.24 werkzeug-0.9.6 flask-0.10.1 sphinx-1.3.1 flask-restful-0.2.12

P.S.: With gdb (7.10.1) it's even worse (might be unrelated): when I run voltron view register I see a frozen black emptiness in the terminal.

Before that I had gdb-7.9.1 installed and I saw the same black emptiness for a few seconds and then an exception:

$ voltron view register Encountered an exception while running the view 'RegisterView': Traceback (most recent call last): File "/usr/lib64/python2.7/site-packages/voltron/main.py", line 53, in main inst.run() File "/usr/lib64/python2.7/site-packages/voltron/view.py", line 239, in run self.render() File "/usr/lib64/python2.7/site-packages/voltron/plugins/view/register.py", line 306, in render api_request('registers', block=self.block)) File "/usr/lib64/python2.7/site-packages/voltron/core.py", line 376, in send_requests t.join() File "/usr/lib64/python2.7/threading.py", line 949, in join self.__block.wait() File "/usr/lib64/python2.7/threading.py", line 340, in wait waiter.acquire() File "/usr/lib64/python2.7/site-packages/voltron/view.py", line 329, in sigwinch_handler self.do_render() File "/usr/lib64/python2.7/site-packages/voltron/view.py", line 309, in do_render self.fmt_body = self.body AttributeError: 'RegisterView' object has no attribute 'body'

The server runs fine, with both gdb versions:

$ wget -O - http://localhost:5555/api/request --2016-01-17 http://localhost:5555/api/request--2016-01-17 18:31:48-- http://localhost:5555/api/request Resolving localhost... ::1, 127.0.0.1 Connecting to localhost|::1|:5555... failed: Connection refused. Connecting to localhost|127.0.0.1|:5555... connected. HTTP request sent, awaiting response... 405 METHOD NOT ALLOWED 2016-01-17 18:31:48 ERROR 405: METHOD NOT ALLOWED.

— Reply to this email directly or view it on GitHub https://github.com/snare/voltron/issues/82#issuecomment-172343408.

[alopatindev]

@theqlabs I've got the same behavior with llvm 3.4.2 (and gdb 7.10.1): a frozen black screen.

[snare]

Ok, thanks. I'll have a go at reproducing it today and figure it out.

[snare]

Could you guys please paste me the results of the following with a configuration that produces the "Architecture 'None' not supported" error:

$ gdb hello
gdb$ b main
gdb$ run

$ wget -q -O - http://localhost:5555/api/targets
$ wget -q -O - http://localhost:5555/api/registers 

[snare]

Working OK for me with both GDB and LLDB (the latter installed from the latest Swift package) on Trusty64 with everything else installed from packages. Will try with LLVM 3.7.

[snare]

BTW there's a basic web interface for submitting arbitrary API requests now if you put http://localhost:5555 in your browser.

[snare]

Also please pull the latest version from github as I've pushed a few commits in the last few days

[alopatindev]

With gdb:

$ wget -q -O - http://localhost:5555/api/targets
{"status": "success", "data": {"targets": [{"byte_order": "little", "addr_size": 8, "state": "stopped", "num": 1, "file": "/tmp/hello", "arch": "x86_64", "id": 0}]}, "type": "response"}
$ wget -q -O - http://localhost:5555/api/registers
{"status": "success", "data": {"registers": {"gs": 0, "rip": 4195705, "r9": 140737351954240, "fs": 0, "cs": 51, "rax": 4195680, "rsi": 140737488346200, "rcx": 0, "st4": "N/A", "st5": "N/A", "st6": "N/A", "st7": "N/A", "st0": "N/A", "es": 0, "st2": "N/A", "st3": "N/A", "rflags": 518, "st1": "N/A", "r14": 0, "r15": 0, "r12": 4195424, "r13": 140737488346192, "r10": 0, "r11": 140737348257632, "rsp": 140737488345952, "ds": 0, "rbx": 0, "ss": 43, "r8": 140737351875648, "rdx": 140737488346216, "rbp": 140737488345968, "rdi": 4195860}}, "type": "response"}

With lldb:

$ wget -q -O - http://localhost:5555/api/targets
{"status": "success", "data": {"targets": [{"byte_order": "little", "addr_size": 8, "state": "stopped", "file": "./hello", "arch": null, "id": 0}]}, "type": "response"}
$ wget -q -O - http://localhost:5555/api/registers
{"status": "error", "data": {"message": "Exception getting registers from debugger: Unsupported architecture: None", "code": 4096}, "type": "response"}

BTW there's a basic web interface for submitting arbitrary API requests now if you put http://localhost:5555 in your browser.

Hmm, I see only

Internal Server Error

The server encountered an internal error and was unable to complete your request. Either the server is overloaded or there is an error in the application.

instead of the web interface. Is there any server log?

Also please pull the latest version from github as I've pushed a few commits in the last few days

Yeah, I use the newest commit all the time

[snare]

If you have debug logging enabled in your config, it'll create a log file in ~/.voltron/voltron_debugger.log

But the only time I've seen that error is when the package hasn't installed correctly and the template files or static content is missing from the package. If you want to try installing the package in develop mode, that might fix the web UI:

python setup.py develop or python3 setup.py develop depending on which python you're using

[snare]

The GDB output looks fine and should not produce the "Architecture 'None' not supported" error as far as I can see. If it does, that's another issue

LLDB on the other hand looks bad. I'll try with LLVM 3.7 and see if I can reproduce that.

[snare]

OK LLDB architecture 'None' issue on v3.7 should be fixed in 4b0df53026486688f9b496fa422b12aee8621d78. It's returning a triple that was failing to parse correctly like x86_64-unknown-linux-gnu (extra hyphen there in linux-gnu. Yeah.)

[alopatindev]

@snare I've installed voltron on another machine with approximately the same software installed

voltron view registers now works with lldb, good job!

With gdb it still hangs on the black screen though

Also http://localhost:5555 returns the same internal server error. With enabled logs it's:

2016-01-18 16:04:28,150 ERROR         app.py:1423        log_exception -- Exception on / [GET]
Traceback (most recent call last):
  File "/usr/bin/../lib64/python2.7/site-packages/flask/app.py", line 1817, in wsgi_app
    response = self.full_dispatch_request()
  File "/usr/bin/../lib64/python2.7/site-packages/flask/app.py", line 1477, in full_dispatch_request
    rv = self.handle_user_exception(e)
  File "/usr/bin/../lib64/python2.7/site-packages/flask/app.py", line 1381, in handle_user_exception
    reraise(exc_type, exc_value, tb)
  File "/usr/bin/../lib64/python2.7/site-packages/flask/app.py", line 1475, in full_dispatch_request
    rv = self.dispatch_request()
  File "/usr/bin/../lib64/python2.7/site-packages/flask/app.py", line 1461, in dispatch_request
    return self.view_functions[rule.endpoint](**req.view_args)
  File "/usr/bin/../lib64/python2.7/site-packages/voltron/core.py", line 262, in index
    return make_response(render_template('index.html', views=voltron.plugin.pm.web_plugins.keys()))
  File "/usr/bin/../lib64/python2.7/site-packages/flask/templating.py", line 127, in render_template
    return _render(ctx.app.jinja_env.get_or_select_template(template_name_or_list),
  File "/usr/bin/../lib64/python2.7/site-packages/jinja2/environment.py", line 830, in get_or_select_template
    return self.get_template(template_name_or_list, parent, globals)
  File "/usr/bin/../lib64/python2.7/site-packages/jinja2/environment.py", line 791, in get_template
    return self._load_template(name, self.make_globals(globals))
  File "/usr/bin/../lib64/python2.7/site-packages/jinja2/environment.py", line 765, in _load_template
    template = self.loader.load(self, name, globals)
  File "/usr/bin/../lib64/python2.7/site-packages/jinja2/loaders.py", line 113, in load
    source, filename, uptodate = self.get_source(environment, name)
  File "/usr/bin/../lib64/python2.7/site-packages/flask/templating.py", line 64, in get_source
    raise TemplateNotFound(template)
TemplateNotFound: index.html
2016-01-18 16:04:28,154 INFO    _internal.py:87                   _log -- 127.0.0.1 - - [18/Jan/2016 16:04:28] "GET / HTTP/1.1" 500 -

the template files or static content is missing from the package. If you want to try installing the package in develop mode, that might fix the web UI

Okay, I'll try it later, thanks.

[snare]

Note that with GDB the views are only refreshed when the debugger stops, due to the fact that the GDB API can only be accessed from the main thread. Have you stepped in the debugger after connecting the views?

[snare]

If the issue is still happening after stepping the debugger, let me know what the software configuration is and I'll try to reproduce the issue here.

[alopatindev]

@snare Ahh, I got it! It shows me registers when I'm stepping with gdb. Sorry for confusion. BTW, that's might be a good thing to clarify in FAQ this gdb limitation.

[snare]

Yeah it's kinda covered in the readme, but given someone else just asked me about it on IRC as well I'll put it in the FAQ :)