wisk / medusa

An open source interactive disassembler
Other
1.04k stars 92 forks source link

Loading executable into qMedusa works but then nothing happens #72

Open dnivra opened 7 years ago

dnivra commented 7 years ago

I launch qMedusa and selected a binary to analyze(a simple hello world program). qMedusa identifies the file parameters correct, asks for a database path and then nothing happens: an empty screen is displayed as shown in the image. Did I miss something?

qmedusa-after-loading

PS: Are paths to libraries not setup correctly when qMedusa is invoked? I had to copy files from lib folder into bin for any loaders to be detected.

wisk commented 7 years ago

Hi dnivra,

I guess this is a issue with the way how modules are loaded. By default, medusa tries to load modules from the working directory, this is convenient for testing purpose but not adapted for a release version (see https://github.com/wisk/medusa/issues/62). At this time, I don't have good fix for that issue. If you have any recommendations, feel free to tell me.

Thanks for reporting.

dnivra commented 7 years ago

Hello wisk, Thanks for the response!

Sorry for combining two bugs into a single report: the main issue I faced was after building the dev version and loading a binary in, I get a blank screen like in the screenshot I shared in the bug report. I'm not sure what is wrong - the binary loads fine in 0.4.3 and the disassembly, CFG etc do show up but in dev, nothing seems to be displayed after the executable to be analyzed is loaded. I'm not sure why this happens and am wondering if I missed something. How can I figure out what is wrong?

Also regarding the library loading issue - Typically, most binaries do copy the libraries to a specific location(/lib, /lib64, /usr/lib etc) and they are automatically picked up from there. Alternatively, I think the environment variable LD_LIBRARY_PATH can be used to specify additional paths to load from. I think a shell script can be used to set this variable and then invoke qMedusa so that LD_LIBRARY_PATH isn't modified system-wide but just for qMedusa.

wisk commented 7 years ago

Regarding the blank screen, could you make sure modules (ldr*, arch*, etc) are correctly loaded? To do that, you can either take a look at the log widget or see that using /proc/pid/maps.

medusa.so should be copied in the /usr/lib, but I'm not sure this is the best location for modules. I was thinking about /opt/medusa or /usr/lib/medusa but I can't make my mind.

dnivra commented 7 years ago

These are the modules which are loaded(as per /proc/pid/maps):

arch_arm.so arch_st62.so arch_x86.so arch_z80.so bind_pythond.so db_soci.so emul_interpreter.so ldr_bs.so ldr_elf.so ldr_gb.so ldr_mach-o.so ldr_pe.so ldr_raw.so ldr_st62.so libmedusad.so os_unix.so os_windows.so pydusa.so libmedusad.so

Also, these messages were also printed out by the binary. Perhaps that is the issue?

QFontDatabase: Cannot find font directory /home/introssoc/.hunter/_Base/8c538a0/a1b471c/15fdb4a/Build/Qt/qtbase/Install/lib/fonts - is Qt installed correctly? QFontDatabase: Cannot find font directory /home/introssoc/.hunter/_Base/8c538a0/a1b471c/15fdb4a/Build/Qt/__qtbase/Install/lib/fonts - is Qt installed correctly? QFontDatabase: Cannot find font directory /home/introssoc/.hunter/_Base/8c538a0/a1b471c/15fdb4a/Build/Qt/qtbase/Install/lib/fonts - is Qt installed correctly? QFontDatabase: Cannot find font directory /home/introssoc/.hunter/_Base/8c538a0/a1b471c/15fdb4a/Build/Qt/__qtbase/Install/lib/fonts - is Qt installed correctly? QFontDatabase: Cannot find font directory /home/introssoc/.hunter/_Base/8c538a0/a1b471c/15fdb4a/Build/Qt/__qtbase/Install/lib/fonts - is Qt installed correctly?

dnivra commented 7 years ago

Also, regarding the modules not being detected correctly when qMedusa is installed and run globally. qMedusa uses the directory from which it was launched as the default Module directory. It does detect libmedusad.so(present in /usr/local/lib) when I add it's location to LD_LIBRARY_PATH but doesn't detect the loaders etc(present in /usr/local/lib/medudsa) and so fails to load any binary for analysis.

wisk commented 7 years ago

Regarding the lib name, this is an issue with hunter which set CMAKE_DEBUG_POSTFIX ="d". For some reason, this variable is set globally, that's why you have a medusad.so instead of medusa.so. However, it shouldn't the problem in this case, but could you try to compile it in release mode? -DCMAKE_BUILD_TYPE=release.

The error messages you posted are interesting. Could you try to change the font? To do that, you can either to the menu Edit → Settings → Font / colors → Listing or modify your~/.medusa/cfg.ini``. If Qt cannot find any usable font, medusa won't be able to print anything, so it could explain the white screen.

dnivra commented 7 years ago

I built the release version instead of debug version and ran qMedusa as follows:

$ LD_LIBRARY_PATH=/usr/local/lib:/usr/local/lib/medusa qMedusa

In above, libmedusa.so is in /usr/local/lib and other SO files(including executable format loaders) are in /usr/local/lib/medusa. However, only former is found and not latter. After launching and opening a binary for analysis, I get the error that there is no supported loader. qMedusa displays that it is choosing the directory it was launched from as the module directory and I think that's why it's not finding the loaders of the executable formats.

dnivra commented 7 years ago

And here is screenshot of the available fonts. There is only one font listed there and I think that value is loaded from ~/.medusa/cfg.ini.

qmedusa font list

wisk commented 7 years ago

Hello dnivra,

This issue should be fixed, thanks for your patience. It turns out to be a stupid typo in a variable name. Sorry about that. BTW I didn't test the GUI since a long time(, I usually only use the python bindings), and it seems the graph view is broken too... I'll try to fix that ASAP.

dnivra commented 7 years ago

Sounds good! I will check this out with a clean build sometime.