Open xx0red opened 2 weeks ago
xx0red
commented
2 weeks ago and yes I read:
Important : It is important to assert everything works as expected before moving forward. The vast majority of errors at this point can be solved by reinstalling the specific component with kvm-qemu.sh. For example, the error below was raised when trying to open virt-manager but libvirt installation was corrupted for some reason. Reinstalling libvirt with the script solved the issue.
doomedraven
commented
2 weeks ago Run --issues there is msg about this specific error
El mié, 18 sept 2024, 17:20, xx0red @.***> escribió:
and yes I read:
Important : It is important to assert everything works as expected before moving forward. The vast majority of errors at this point can be solved by reinstalling the specific component with kvm-qemu.sh https://github.com/kevoreilly/CAPEv2/blob/master/installer/kvm-qemu.sh. For example, the error below was raised when trying to open virt-manager but libvirt installation was corrupted for some reason. Reinstalling libvirt with the script solved the issue.
— Reply to this email directly, view it on GitHub https://github.com/kevoreilly/CAPEv2/issues/2322#issuecomment-2358765721, or unsubscribe https://github.com/notifications/unsubscribe-auth/AAOFH32VT3LGJ5U3WPMZETDZXGK2LAVCNFSM6AAAAABON6D54SVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZDGNJYG43DKNZSGE . You are receiving this because you are subscribed to this thread.Message ID: @.***>
xx0red
commented
2 weeks ago it just says to run ./kvm-qemu.sh libvirt which I've already done as stated
doomedraven
commented
2 weeks ago oh it was bigger previously :D basically some problem here but no logs so i can't help
https://github.com/kevoreilly/CAPEv2/blob/master/installer/kvm-qemu.sh#L691-L730 gir1.2-libvirt-glib-1.0_1.0.0-1_amd64 or libvirt-glib-3.0.0 wasn't properly installed
xx0red
commented
2 weeks ago xx0red
commented
2 weeks ago not sure which logs you need, I didn't see any errors from what I saw but maybe I overlooked..
doomedraven
commented
2 weeks ago they looks fine, idk what is wrong, but i guess some lib wasn't properly linked
xx0red
commented
2 weeks ago Well I’ve reinstalled fresh twice now and still no luck.
On Wed, Sep 18, 2024 at 2:18 PM doomedraven @.***> wrote:
they looks fine, idk what is wrong, but i guess some lib wasn't properly linked
— Reply to this email directly, view it on GitHub https://github.com/kevoreilly/CAPEv2/issues/2322#issuecomment-2359229956, or unsubscribe https://github.com/notifications/unsubscribe-auth/ARKCO3WYK62QSHGVULLGHK3ZXHGY5AVCNFSM6AAAAABON6D54SVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZDGNJZGIZDSOJVGY . You are receiving this because you authored the thread.Message ID: @.***>
ClaudioWayne
commented
2 weeks ago I really tried to reproduce your error but didn't succeed. Just did what you mentioned here on 2 different systems:
1. sudo ./kvm-qemu.sh all | tee kvm-qemu.log
2. reboot
3. sudo ./kvm-qemu.sh virtmanager | tee kvm-qemu-virt-manager.log
4. reboot
5. try to open virt-manager to verify install -> it worksMaybe it's a more general underlying failure here. Not sure if this failure appears due to lack of virtualization support but it seems your system did not support virtualization as you can see in your logs:
[+] You should logout and login
INFO: Your CPU does not support KVM extensions
KVM acceleration can NOT be used
QEMU: Checking for hardware virtualization : FAIL (Host not compatible with KVM; HW virtualization CPU features not found. Only emulated CPUs are available; performance will be significantly limited)Thanks Claudio, no, that error is due to incorrectly linked dependency, but I can't reproduce it, but I had it in past too
xx0red
commented
2 weeks ago Hmm what to do lol
On Thu, Sep 19, 2024 at 2:34 AM doomedraven @.***> wrote:
Thanks Claudio, no, that error is due to incorrectly linked dependency, but I can't reproduce it, but I had it in past too
— Reply to this email directly, view it on GitHub https://github.com/kevoreilly/CAPEv2/issues/2322#issuecomment-2360212955, or unsubscribe https://github.com/notifications/unsubscribe-auth/ARKCO3V4W7DIWGV4NGWKRO3ZXJ5BVAVCNFSM6AAAAABON6D54SVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZDGNRQGIYTEOJVGU . You are receiving this because you authored the thread.Message ID: @.***>
xx0red
commented
2 weeks ago I've followed the documentation to a T, using VMware Ubuntu 22.04, changed WOOT to 'CORE', rebooted as necessary. Don't know what I'm doing wrong
xx0red
commented
2 weeks ago It doesn't show in the .log file but in the terminal I do see this warning, not sure if relevant?
CCLD libvirt-gobject-1.0.la
GISCAN LibvirtGObject-1.0.gir
/tmp/libvirt-glib-3.0.0/libvirt-gobject/tmp-introspect9qv2n20v/LibvirtGObject-1.0.c: In function 'dump_object_type':
/tmp/libvirt-glib-3.0.0/libvirt-gobject/tmp-introspect9qv2n20v/LibvirtGObject-1.0.c:251:3: warning: 'G_TYPE_FLAG_FINAL' is deprecated: Not available before 2.70 [-Wdeprecated-declarations]
251 | if (G_TYPE_IS_FINAL (type))
| ^~
In file included from /usr/include/glib-2.0/gobject/gobject.h:24,
from /usr/include/glib-2.0/gobject/gbinding.h:29,
from /usr/include/glib-2.0/glib-object.h:22,
from /tmp/libvirt-glib-3.0.0/libvirt-gobject/tmp-introspect9qv2n20v/LibvirtGObject-1.0.c:30:
/usr/include/glib-2.0/gobject/gtype.h:1050:3: note: declared here
1050 | G_TYPE_FLAG_FINAL GLIB_AVAILABLE_ENUMERATOR_IN_2_70 = (1 << 6)
| ^~~~~~~~~~~~~~~~~
/tmp/libvirt-glib-3.0.0/libvirt-gobject/tmp-introspect9qv2n20v/LibvirtGObject-1.0.c:251:13: warning: Not available before 2.70
251 | if (G_TYPE_IS_FINAL (type))
| ^~~~~~~~~~~~~~~~~
/tmp/libvirt-glib-3.0.0/libvirt-gobject/tmp-introspect9qv2n20v/LibvirtGObject-1.0.c: In function 'dump_fundamental_type':
/tmp/libvirt-glib-3.0.0/libvirt-gobject/tmp-introspect9qv2n20v/LibvirtGObject-1.0.c:369:3: warning: 'G_TYPE_FLAG_FINAL' is deprecated: Not available before 2.70 [-Wdeprecated-declarations]
369 | if (G_TYPE_IS_FINAL (type))
| ^~
In file included from /usr/include/glib-2.0/gobject/gobject.h:24,
from /usr/include/glib-2.0/gobject/gbinding.h:29,
from /usr/include/glib-2.0/glib-object.h:22,
from /tmp/libvirt-glib-3.0.0/libvirt-gobject/tmp-introspect9qv2n20v/LibvirtGObject-1.0.c:30:
/usr/include/glib-2.0/gobject/gtype.h:1050:3: note: declared here
1050 | G_TYPE_FLAG_FINAL GLIB_AVAILABLE_ENUMERATOR_IN_2_70 = (1 << 6)
| ^~~~~~~~~~~~~~~~~
/tmp/libvirt-glib-3.0.0/libvirt-gobject/tmp-introspect9qv2n20v/LibvirtGObject-1.0.c:369:13: warning: Not available before 2.70
369 | if (G_TYPE_IS_FINAL (type))
| ^~~~~~~~~~~~~~~~~
GICOMP LibvirtGObject-1.0.gir
make[3]: Leaving directory '/tmp/libvirt-glib-3.0.0/libvirt-gobject'
make[2]: Leaving directory '/tmp/libvirt-glib-3.0.0/libvirt-gobject'
Making all in vapi
make[2]: Entering directory '/tmp/libvirt-glib-3.0.0/vapi'
make[2]: Nothing to be done for 'all'.
make[2]: Leaving directory '/tmp/libvirt-glib-3.0.0/vapi'
Making all in examples
make[2]: Entering directory '/tmp/libvirt-glib-3.0.0/examples'
CC event_test-event-test.o
CC conn_test-conn-test.o
CCLD event-test
CCLD conn-test
make[2]: Leaving directory '/tmp/libvirt-glib-3.0.0/examples'
Making all in docs
make[2]: Entering directory '/tmp/libvirt-glib-3.0.0/docs'
Making all in libvirt-glib
make[3]: Entering directory '/tmp/libvirt-glib-3.0.0/docs/libvirt-glib'
make[3]: Nothing to be done for 'all'.
make[3]: Leaving directory '/tmp/libvirt-glib-3.0.0/docs/libvirt-glib'
Making all in libvirt-gobject
make[3]: Entering directory '/tmp/libvirt-glib-3.0.0/docs/libvirt-gobject'
make[3]: Nothing to be done for 'all'.
make[3]: Leaving directory '/tmp/libvirt-glib-3.0.0/docs/libvirt-gobject'
Making all in libvirt-gconfig
make[3]: Entering directory '/tmp/libvirt-glib-3.0.0/docs/libvirt-gconfig'
make[3]: Nothing to be done for 'all'.
make[3]: Leaving directory '/tmp/libvirt-glib-3.0.0/docs/libvirt-gconfig'
make[3]: Entering directory '/tmp/libvirt-glib-3.0.0/docs'
make[3]: Nothing to be done for 'all-am'.
make[3]: Leaving directory '/tmp/libvirt-glib-3.0.0/docs'
make[2]: Leaving directory '/tmp/libvirt-glib-3.0.0/docs'
Making all in po
make[2]: Entering directory '/tmp/libvirt-glib-3.0.0/po'
make[2]: Nothing to be done for 'all'.
make[2]: Leaving directory '/tmp/libvirt-glib-3.0.0/po'
Making all in tests
make[2]: Entering directory '/tmp/libvirt-glib-3.0.0/tests'
make all-am
make[3]: Entering directory '/tmp/libvirt-glib-3.0.0/tests'
make[3]: Nothing to be done for 'all-am'.
make[3]: Leaving directory '/tmp/libvirt-glib-3.0.0/tests'
make[2]: Leaving directory '/tmp/libvirt-glib-3.0.0/tests'
make[2]: Entering directory '/tmp/libvirt-glib-3.0.0'
make[2]: Leaving directory '/tmp/libvirt-glib-3.0.0'
make[1]: Leaving directory '/tmp/libvirt-glib-3.0.0'
dpkg: error: cannot access archive 'gir1.2-libvirt-glib-1.0_1.0.0-1_amd64.deb': No such file or directory
Cloning into 'virt-manager'...
remote: Enumerating objects: 63544, done.
remote: Counting objects: 100% (1687/1687), done.
remote: Compressing objects: 100% (479/479), done.
remote: Total 63544 (delta 1337), reused 1366 (delta 1208), pack-reused 61857 (from 1)
Receiving objects: 100% (63544/63544), 92.35 MiB | 22.23 MiB/s, done.
Resolving deltas: 100% (52672/52672), done.
[+] Cloned Virt Manager repo
Yes that one is exactly which says what is wrong
xx0red
commented
2 weeks ago Do you have a fix?
doomedraven
commented
1 week ago No, bcz it works for me
El jue, 19 sept 2024, 23:15, xx0red @.***> escribió:
Do you have a fix?
— Reply to this email directly, view it on GitHub https://github.com/kevoreilly/CAPEv2/issues/2322#issuecomment-2362211759, or unsubscribe https://github.com/notifications/unsubscribe-auth/AAOFH335T2J5UYC5FWD5GD3ZXM5HNAVCNFSM6AAAAABON6D54SVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZDGNRSGIYTCNZVHE . You are receiving this because you commented.Message ID: @.***>
kevoreilly
commented
1 week ago using VMware Ubuntu 22.04Hmm VMware? So your Ubuntu is in a vm? What about your windows vms... don't say nested!
xx0red
commented
1 week ago It is indeed nested, I believe the problem was that the VM was not setup for virtualization. Ideally I'd like to just deploy a second Windows VM and use that instead of being nested, but I'm unsure how atm.
kevoreilly
commented
1 week ago Well doomed and I don't always agree when it comes to this issue, but I think it's a terrible idea and something which you probably should have mentioned in the beginning.
The only positive argument for nesting is that it makes the job of installing cape easier somehow for new users - but it comes at a very great price in terms of malware compatibility - to have two distinct hypervisors as well as an extra layer of virtualisation significantly multiplies the chances of samples not running due to vm detection/timing issues. Also issues like this with virtualisation features not being present in the nested hypervisor are to be expected.
It is for this reason that I wrote a machinery module for VMware workstation, to complement that for ESXi so all VMware platforms are covered for non-nested use. But ultimately I still recommend ditching VMware completely as it's not good for malware research for reasons mentioned above, and is one of many reasons we recommend KVM above all else.
doomedraven
commented
1 week ago Well nested not related to the issue, the thing is that till next deploy of my server and if it fail I won't investigate that, as if I can't reproduce it I can't fix it, I did deployment last week without issues
El lun, 23 sept 2024, 17:00, kevoreilly @.***> escribió:
Well doomed and I don't always agree when it comes to this issue, but I think it's a terrible idea and something which you probably should have mentioned in the beginning.
The only positive argument for nesting is that it makes the job of installing cape easier somehow for new users - but it comes at a very great price in terms of malware compatibility - to have two distinct hypervisors as well as an extra layer of virtualisation significantly multiplies the chances of samples not running due to vm detection/timing issues. Also issues like this with virtualisation features not being present in the nested hypervisor are to be expected.
It is for this reason that I wrote a machinery modules for VMware workstation, to complement that for ESXi so all VMware platforms are covered for non-nested use. But ultimately I still recommend ditching VMware completely as it's not good for malware research for reasons mentioned above, and is one of many reasons we recommend KVM above all else.
— Reply to this email directly, view it on GitHub https://github.com/kevoreilly/CAPEv2/issues/2322#issuecomment-2368550706, or unsubscribe https://github.com/notifications/unsubscribe-auth/AAOFH344XMUYAB4Z3WF6X6DZYAUJLAVCNFSM6AAAAABON6D54SVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZDGNRYGU2TANZQGY . You are receiving this because you commented.Message ID: @.***>
doomedraven
commented
1 week ago btw if you need virt-manager and can't fix that by yourself, you can use https://hub.docker.com/r/mber5/virt-manager is what im using on non linux OS
About accounts on capesandbox.com
This is open source and you are getting free support so be friendly!
Prerequisites
Please answer the following questions for yourself before submitting an issue.
Expected Behavior
Install kvm-qemu via installation script and install virt-manager
Current Behavior
after running kvm-qemu.sh all {user} and rebooting and running kvm-qemu.sh virt-manager {user} and rebooting again. I attempt to open virt-manager and get the error Namespace LibVirtGlib not available.
Failure Information (for bugs)
Getting this exact error
Steps to Reproduce
Please provide detailed steps for reproducing the issue.
Context
Ubuntu 22.04.x, latest CAPEv2 versions.