Does CAPEv2 still support physical machinery detonation?

[0xxdovahkiin]

Expected Behavior

Hi,

Using latest CAPEv2 installation with Physical Machinery configured based on these steps: https://mariohenkel.medium.com/using-cape-sandbox-and-fog-to-analyze-malware-on-physical-machines-4dda328d4e2c

However after submission of a file on CAPE web gui, the physical machine reboots and status of the analysis is reported, however the results are all empty.

I am using the following old agent to support the physical machinery configuration: https://github.com/spender-sandbox/cuckoo-modified/blob/master/agent/agent.py

After submitting sample files through the CAPEv2 web interface, the physical machine reboots, and the CAPEv2 web interface shows Status as "reported".

However, there are no reported behavioral analysis results,

No analysis results in storage/analyses/

Any help will be greatly appreciated

[kevoreilly]

It states the agent is not compatible from that critical error in the log, and you are using an agent from spender which is not even Python 3?! No chance this could ever work. You will need to use CAPE's current agent for starters.

[doomedraven]

for start why do you remove template? that is igual to force us asking the same crap over and over. RTFM

[0xxdovahkiin]

Hmm yes the reason why I ended up trying to use the old agent was because when i specified to use "physical" machinery in cuckoo.conf, CAPE server performs a check to /RPC2 endpoint on the guest agent and that fails. Hence i stumbled across this post which says cuckoo Physical machinery doesn't work with new agent. https://github.com/cuckoosandbox/cuckoo/issues/1396

I have tried the agent.py here, for CAPEv2 but none of them seem to be working for physical machinery, /RPC2 does not seem to exist when i try to start the cape service (sudo service cape restart)

[kevoreilly]

But that issue is for Cuckoo?! Cuckoo 2.0 and CAPE are completely different, so that issue is irrelevant.

[kevoreilly]

Also you should be able to test the agent irrespective of machinery. The agent can just be tested with curl IP 8000, Can you connect? The machinery is responsible for getting a clean Windows to the point where the agent can be contacted by the server.

[0xxdovahkiin]

I understand, apologies since it is a very similar issue and I just intended to exhaust all possible avenues before i opened an issue, my bad for not submitting with the template.

Yes CAPE was able to connect to port 8000 guest agent, however the cape service connects to the guest agent at /RPC2 and that does not exist with the new agent. I can observe this request being made to the agent, and the cape service stops there after indicating that the physical machine is offline

[kevoreilly]

This doesn't make sense as you are basically saying cape cannot connect to its own current agent if that is what you mean by 'new' agent - so cape would be broken for everyone... But it's not.

[kevoreilly]

The agent has basically zero to do with physical machinery - I think there is confusion here.

[0xxdovahkiin]

I think I figured out part of where the confusion lies. After more checking, my /opt/CAPEv2/modules/machinery/physical.py seems to be from the original CAPE project rather than from CAPEv2.. hence why it is making the xmlrpc calls to the guest agent.. and hence the HTTP 404 when CAPE server tries to POST to "RPC2" endpoint.

I'm still trying to figure out why this happens, the installation script for CAPEv2 that I'm using is: https://raw.githubusercontent.com/doomedraven/Tools/master/Sandbox/cape2.sh

I just ran a fresh installation today with this script and I am still getting the same old CAPE machinery/physical.py instead of CAPEv2, not sure if this happens to everyone or just me..

[0xxdovahkiin]

Update: Manually replaced physical.py with the latest version and it works with the latest agent. Seems like the other files in modules/machinery are all correct and up to date except for physical.py.

[doomedraven]

cape2.sh clones this repo, and not any other one, so idk how you can have files from other repos. if you had cloned some other repo as capev2 then it won't give you new files

[doomedraven]

Just did it, it loads the correct file %)

On 15 Jul 2022, at 12:41, darrelneo @.***> wrote:

Don't take my word for it, you can try running it and take a look at the physical.py. I installed using the script and recommended steps on a completely fresh ubuntu multiple times, its the same issue. Hope this helps.

— Reply to this email directly, view it on GitHub https://github.com/kevoreilly/CAPEv2/issues/1006#issuecomment-1185419060, or unsubscribe https://github.com/notifications/unsubscribe-auth/AAOFH35CBOT26ANR5JO5NE3VUE54VANCNFSM53RTERKA. You are receiving this because you modified the open/close state.

[kevoreilly]

It seems impossible as the only reference to a repo in cape2.sh is to CAPEv2.

[wit0k]

I actually had exactly the same problem after using the install script... The solution for me was to make a git reset in /opt/Cape/ and git pull ... this pulled the correct code (Most recent master branch)... later i had to manually fix some requirements etc. There were some other files affected (it was looking like the script has initially cloned wrong code (while the git URL seemed correct) which considered itself the newest version. This has caused a lot of hours of troubleshooting until i realised what is wrong ... i even found how to fix the python library which was the culprit of the error related to "/RPC2" mentioned by @0xxdovahkiin hehe

[doomedraven]

we would appreciate PR with fixes or more detailed info on everything. The RPC2 thing was due to old machinery in community repo that was deleted

[wit0k]

Now i know that it was due to old machinery ... I am wondering how is that even possible that git clone clones wrong code from time to time ... I would send you some of my raw notes while troubleshooting it... but if somebody encounters again the RPC2 after using the install script, it would be a strong indication that he/she has the same problem

[kevoreilly]

This can be understood by examining the fix: https://github.com/kevoreilly/community/commit/22ebc5aa9ec2d2ab920165281f074b034010b5ae

[doomedraven]

bcz community runs with force mode and it runs after clone main repo. its imposible anymore to find that as it was deleted 26d ago https://github.com/kevoreilly/community/commits/master/modules/machinery

[wit0k]

Cool so no need for my notes anymore ? I had this problem with the code base cloned more than 2 months ago.

[doomedraven]

you need to watch capev2 and community repo way much closer then ;) if notes are only for physical.py than no no need of them. of they about something else then yes

[wit0k]

Right. Thx

P.S Unfortunately didn't keep other notes.... Once i add new server i will test the install script again, and report errors faster (if any)

[kevoreilly]

Thank you!

[doomedraven]

that would be appreciated. As if nobody report, means there is no problems :P