consider switching to the python ida plugin only as well

On OSX 10.11.1

when run ./qira it shows me :

readlink: illegal option -- f
usage: readlink [-n] [file ...]
usage: dirname path

whatever args I give it.

How to fix it?

The new stuff being added, how do I use it?

The point of QIRA is to be usable, not crap to do one experiment on and push out a paper. If you add a feature, add documentation. It doesn't have to be too sophisticated.

Ideally, like the writeups I used to do:
https://code.google.com/p/qira/wiki/ezhpQIRAwriteup

Test on Ubuntu 15.10
After install qira and execute fetchlib.sh.
Then install the gcc-multilib.

qira ./magic
/home/apple/a.out: ��: ̀Í�: D$($: Error 18446744073549524638

https://bugs.launchpad.net/qemu/+bug/1531352
Waiting qemu fix this or patch the qemu code

An extra null pointer check is not needed in functions like the following.

• Process_State::init
• Trace_dealloc

I got an email from a QIRA user that the okami challenge from UIUCTF wasn't working, and it seems broken to me too. QEMU seems to trace it but nothing shows up in the DB. I'll try to find and squash the bug soon as we have a CTF this weekend.

Here's the binary: okami

1. Ability to mark certain functions as hidden, temporarily collapsing them and all their sub functions out of the trace as if they were filtered.
2. Ability to focus on a specific instance of a specific function call, filtering out everything before and after that function. Maybe more like zooming in / locking the qira view on to it temporarily. Would be easier to not get lost, and depending on the implementation might help perf.

I'm working on a statically compiled binary right now, but such things should be useful for ordinary large binaries. These things would go great with some kind of dynamic call trace view.

Hey all,

Recently been making another push at understanding this tool. I can totally see the benefit, but from an outsider it is difficult to get up to speed. A "QIRA In A Nutshell" would be nice.

Anyway, my real purpose here is to comment on some useful features IMHO. One of them would be the ability to attach to already running processes. The second one would be to be able to ingest an IDA Pro full trace file. The reasons for both of these are to help deal with complicated code. While QIRA does have the ability to not start until a given spot, I feel like being able to take advantage of IDA's more powerful tracing would allow us to use QIRA to display and navigate it better.

One of the things IDA does best is propagate all the got names back to the plt, and make functions much more readable. So for a concrete example

qira tests_manual/helloc
g 0x8048404
sub_8048320 should be called write

Also, the jmpl @ 0x8048320 should end the function

I'm having some problems compiling the plugin for 6.5 (win), do you mind posting 6.5 versions along the 6.6 ones?

Thanks!

I'm refactoring my testing framework to be better quality and start from C. I realize there might be a lot of overlap in using test cases for the dynamic portion of QIRA, so what is a good way to deal with this? Perhaps we can splits tests/ into tests-source/ and tests-binary/ or something along those lines. I realize some cases are useful to include without source available (CTF binaries, etc.).

Run "qira ./arm-hello" with WITH_CAPSTONE = True

I tried it locally and it works ok, no need to use dot at all. Should I send a PR?
Also, what is the license for Qira? Can I use some of the Js graph code to improve r2 web ui?

The changes in https://github.com/tim-becker/qira/tree/concrete_execution add a concrete executor for the BAP IL to QIRA. Although initially meant to find bugs in BAP's lifter, the validation actually revealed subtle bugs in QIRA as well (see PR #93 and PR #87). So, it seems like this code could be useful for regression testing as well.

@geohot @nedwill , thoughts?

qira result doesn't appear in chrome browser...

WHY?

please, help!

For some reason the function argument recovery code is broken. I wouldn't be surprised if we had a regression after moving to BAP as the code seems to rely heavily on architecture-dependent constants.

We should be able to track the thumb bit statically with some success, like IDA does. The current thumb hacks are brittle and don't really belong in QIRA.

x86-64 is unreadable shit, I tried a bit to use trunk QIRA for bctf, mostly unusable still.

I see a few things tagged QIRA v1.2, which is a start, but a complete burndown list(or issues) like
https://code.google.com/p/qira/wiki/shippingQIRAv1
would do wonders I feel

If it is, don't reinstall it. Also, where is it coming from when you opam install?

why is this happening if I rerun qira?

The problem is if it's not, the names blink on loading. But now it's hella slow.

There's two ways to address this.

1. Make sure all the relevant names data is sent with the packets used to draw. This is hard because the instructions and hex editor aren't parsed on the server.
2. Properly cache the names client side. This runs into all sorts of invalidation issues.

Anyone want to fix it.

qira looks interesting as one passes by, but there's not enough explanation to hook me in to giving it a try, or suggest it to others with confidence that I understand what it is and why it would be useful to them.

A description of using it like gdb or strace, with a few screenshots, might be one way to improve.

Qira and the build process make a lot of assumptions that the python in path is python2. From an Arch linux experience, It would be great to have it explicitly reference python2.

Default static will need documentation and new screenshots. I'll be happy to add this - perhaps a writeup of a CTF problem like the old ezhp writeup will be nice.

Documentation doesn't have to be much, just a couple of lines in the README.

Also, I added you to BinaryAnalysisPlatform, you are now the 2nd biggest contributor to QIRA, and have the right to merge sensible pull requests.

The source link on http://qira.me redirects to the old google code page.
The google code page, besides being deprecated in favor of github, no longer exists.

After unpacking this binary with UPX and running qira on it, I get the following error:

$ qira flag
/opt/qira/middleware/qira_program.py:360: SyntaxWarning: import * only allowed at module level
  def disasm(self, raw, address):
which: no flag in (/home/gulshan/bin:/usr/local/bin:/home/gulshan/.cabal/bin:/usr/local/sbin:/usr/local/bin:/usr/bin:/opt/android-ndk:/opt/android-sdk/platform-tools:/opt/android-sdk/tools:/usr/lib/jvm/default/bin:/usr/bin/site_perl:/usr/bin/vendor_perl:/usr/bin/core_perl:/opt/android-ndk:/home/gulshan/.gem/ruby/2.2.0/bin)
*** program is /mnt/ubuntu/home/gulshan/code/ctf/pwnable.kr/flag/flag with hash 11e8f196af7d9e404b3900e7b43eb906665fe417
**** using /opt/qira/qemu/qira-x86_64 for 0x3e
Traceback (most recent call last):
  File "/usr/bin/qira", line 96, in <module>
    program = qira_program.Program(args.binary, args.args, qemu_args)
  File "/opt/qira/middleware/qira_program.py", line 174, in __init__
    self.getnames()
  File "/opt/qira/middleware/qira_program.py", line 428, in getnames
    symbol = symtable.get_symbol(rel['r_info_sym'])
AttributeError: 'NullSection' object has no attribute 'get_symbol'

Sometimes when QIRA is running, the view in Chrome is empty. It requires either refreshing or waiting in some instances. This description is super vague because I don't quite know what the bug is, but I'll narrow it down soon! geohot suspects it's a race condition.

There's a lot of stuff broken in trunk, in the middle of codegate now, but why????

from version 3.0.1, it is possible to install Capstone engine just from PyPi, like:

pip install capstone

unlike previous versions, this also downloads, compiles & builds the core (libcapstone.so), so it is no longer necessary to build & install the core separately like before. this means if you only use Capstone from Python, above command is enough to install everything you need to use Capstone.

Is it time? How quality is it?

At present, https://github.com/BinaryAnalysisPlatform/qira/blob/master/install.sh#L55 can (and probably does) may miss dependencies specified in bap's apt.deps file.

P.S. I was told by a friend that this happened on his system and so this is indeed possible.

Why is that callq PC relative? Capstone used to work, why did BAP break it?

But seriously, things like this are why the current QIRA is unusable, and I'm still stuck on 1.0

I don't see the green depth bar on the left side.

Exception in thread Thread-4:
Traceback (most recent call last):
File "/usr/lib/python2.7/threading.py", line 810, in __bootstrap_inner
self.run()
File "/usr/lib/python2.7/threading.py", line 763, in run
self.__target(_self.__args, *_self.__kwargs)
File "/home/ghotz/qira/middleware/qira_program.py", line 390, in analysis_thread
qira_analysis.analyse_calls(self.program, self.flow)
File "/home/ghotz/qira/middleware/qira_analysis.py", line 338, in analyse_calls
endclnum = get_last_instr(trace.dmap,clnum)
File "/home/ghotz/qira/middleware/qira_analysis.py", line 291, in get_last_instr
myd = dmap[clnum]+1
IndexError: list index out of range

So much so that the actual running of the tests is past 10,000 lines and we can't see it

I tried disabling OPAMVERBOSE=1, but then the tests failed because no output was produced for 10 minutes. How can we OPAMVERBOSE=0.5?

Hi,

Ive been reading the new static2 and there are some comment about not using radare. is there any good reason for this? using radare will greatly simply static2 since it provides a great support for almost all archs and it will make capstone, recursive and probably byteweight unneccessary.

Just as an example, I ported loader.py to radare to load other non-elf files and to improved symbol resolution:

elfloader

radare

If it is ok to use radare, let me know and I will commit new loader and proably start porting other parts to radare.

In linux programs, qira seems to handle int 0x80's very oddly.

Let's take a simple example like

0x80480ff: nop
0x8048100: push eax
0x8048101: int 0x80
0x8048103: pop eax

and just imagine the entry point is 0x80480ff to make things simple.
If you try to do something like fetch_clnums_by_address_and_type(0x8048101, 'I', 0, 100, 100), you'll get 2, the clnum where the program executed the int 0x80, and similarly if you do fetch_clnums_by_address_and_type(0x8048103, 'I', 0, 100, 100) you'll get 3, the clnum where the program executed the pop eax. Everything looks great so far...

Now, let's say you do fetch_registers(2)[-1], you'll get the EIP you expected, which is the address of the int 0x80 (again, expected). Now lets say you do fetch_registers(3)[-1], this time you'll get the EIP of int 0x80 NOT the EIP of pop eax!

If you want a simple example, look at something where int 0x80s are done not in libraries ( http://shell-storm.org/repo/CTF/PlaidCTF-2012/simple/simple ) is a good example. If you look at this in the qira gui, you'll notice that when you highlight the instruction immediately after an int 0x80, the EIP displayed will be incorrect.

Anyway, this is super annoying.

If the commented out portion of tci.c dealing with syscalls in the patch is removed ( https://github.com/BinaryAnalysisPlatform/qira/blob/master/tracers/qemu.patch#L973 ) things seem to work. I have no idea why that code is commented out though, or if that leads to other issues.
Disregard that, I don't know what is causing the issue.... -_-

I'm beginning work on the IDA plugin, and I noticed that sometimes selecting data in IDA does not select the data back in QIRA. This is because QIRA filters any setdaddr for an address it believes is an instruction.

In ida.js:

if (dat[0] == "setdaddr") {
  if (get_data_type(dat[1]) != "datainstruction") {
    update_dview(dat[1]);
  }
}

But get_data_type looks this up in the pmap that ultimately comes from the qiradb. The pmaps are stored by page, masked off with PAGE_MASK. If any instructions from that page are executed, the entire page is marked with PAGE_INSTRUCTION.

Trace.cpp:

#define PAGE_MASK 0xFFFFFFFFFFFFF000LL
...
if (type == 'I') {
  ...
  pages_[c->address & PAGE_MASK] |= PAGE_INSTRUCTION;
}

But sometimes code and data are in the same page. See double_link:

vagrant@vagrant-ubuntu-trusty-64:/vagrant/qira$ readelf -S tests_manual/double_link
There are 30 section headers, starting at offset 0x1150:

Section Headers:
  [Nr] Name              Type            Addr     Off    Size   ES Flg Lk Inf Al
...
  [13] .text             PROGBITS        080483f0 0003f0 0001a2 00  AX  0   0 16
  [14] .fini             PROGBITS        08048594 000594 000014 00  AX  0   0  4
  [15] .rodata           PROGBITS        080485a8 0005a8 000013 00   A  0   0  4
  [16] .eh_frame_hdr     PROGBITS        080485bc 0005bc 00002c 00   A  0   0  4
  [17] .eh_frame         PROGBITS        080485e8 0005e8 0000b0 00   A  0   0  4
  [18] .init_array       INIT_ARRAY      08049f00 000f00 000004 00  WA  0   0  4
  [19] .fini_array       FINI_ARRAY      08049f04 000f04 000004 00  WA  0   0  4

According the pmap, only .init_array and .fini_array are data, even though .rodata and eh_frame* are data too. Either I'm misunderstanding something here or we can do better by having static be responsible for informing the UI about the sections. This could lead to a more accurate haddrline as well.

You should be able to annotate type information in the assembly. If you know a certain read reads from a struct, that memory is now marked as that struct. Improve the hexviewer to display this well, and allow input by copying and pasting in C structs.

mserrano?

Now that BAP supports a fair number of architectures (ARM, x86, x86-64) and file formats (ELF, MachO, COFF), it is becoming increasingly more usable for QIRA. BAP implements many of the features that we have in QIRA static, for example:

• Finding symbols
• Identifying Functions
• Recovering CFG

And many features that would be nice to have, for example:

• Callgraph / Callstrings
• Resolving PC-relative addresses (see #84 (comment) and BinaryAnalysisPlatform/bap#140 (comment))

Getting this information from BAP would greatly improve the performance and correctness of QIRA static. Additionally, this would be a nice way to resolve issues #91 and #84.

This thread is meant to start discussion about possibly implementing a full static backend using BAP. Thoughts?

j and k do not hop between instances of an instruction in FF (they're opening up quicksearch instead). FF j/k works in gmail and facebook, so it is possible.

I have looked at a few source files for your current software. I have noticed that some checks for return codes are missing.

Would you like to add more error handling for return values from functions like the following?

• malloc ⇒ ws_send
• pthread_create ⇒ THREAD_CREATE

First things first I'm a huge fan of this utility and this is my first time ever posting on GIT anywhere so don't destroy me k?

I'm trying to run qira on a vm i have been working on with a kali distro on it. I have forwarded the correct ports and try to connect with my host machine's browser. I can get other server's or other utilities to work in this fashion with absolutely no problem. Is there something with Qira that I'm missing that I need to change in order for this to work? Again I'm a newbie so go easy especially if its crazy obvious lulz

Improve testing code to provide timing/memory usage information if possible to measure performance. That way we know when static is ready (sub 5 second load times on reasonable binaries?).

After running static/python32_build.sh and cd static

Expected:
PYTHON32="./python32/Python/python" python ida_parser.py ../tests/changetest
and
./python32/Python/python ida_parser.py ../tests/changetest

to have to same behavior, but they don't

percontation how do I tag you on this bug?

This is fine for trunk builds, but this won't fly for releases. Not sure my bdistrib.sh script even close to works anymore, but if we want to ship a release, this is one of the roadblocks. Shipping binaries in release is fine.

Outlined a way to do it here. I will be so happy

https://github.com/BinaryAnalysisPlatform/qira/wiki/A-starting-point-for-struct-support-in-QIRA