Loading executable into qMedusa works but then nothing happens about medusa HOT 10 OPEN

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 #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.

from medusa.

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.

from medusa.

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.

from medusa.

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?

from medusa.

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.

from medusa.

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.

from medusa.

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.

from medusa.

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.

from medusa.

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.

from medusa.

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

from medusa.