Mercury hangs on connect about drozer

[jduck]

I can confirm that commenting out the jackpal JNI and calling code in Shell.newShell gets it working on ICS.

[metall0id]

Great, thanks for the confirmation. Will be looking at it in the next couple of days

[metall0id]

I think the problem is because of this: http://stackoverflow.com/questions/8714671/galaxy-nexus-wrong-cpu-abi-being-selected-during-install-time

Making mercury.apk with the /lib/armeabi/ folder removed should fix it. It should then select the .so file in the /lib/armeabi-v7a/ folder.

Someone can test it on Monday for me, can anyone else test if this works?

[mattph76]

I removed the /lib/armeabi folder from the mercury.apk and then reinstalled it on my Galaxy Nexus. Unfortunately, I still can't get the client to connect to it.

[luander]

I figured out that commenting the line 37 ('read();') in the "com.mwr.mercury.Shell.java" file solves the problem for me.
I haven't noticed any collateral effect.
Now it is working on my Ice Cream Sandwich Galaxy SII and Galaxy Nexus.

[metall0id]

Great, thank you luander! I have committed the change. I am going to have to rely on people to test this fully until I can test it myself on Monday with a Nexus.

[mattph76]

Yes, thank you Luander! Tyrone - I rebuilt the code last night and confirmed that my Galaxy Nexus now works as well.

[metall0id]

Great stuff! Can you also confirm that you are able to use shell->persistent without any problems?

[mattph76]

The oneoff shell seems to work fine. The persistent shell just seems to hang although to be honest I don't know what it's supposed to do. I tried from both a WiFi connection and locally tethered via USB cable. Let me know if there's anything that you'd like me try.

[metall0id]

The oneoff shell takes your command, executes it and gives you the result without maintaining a persistent shell connection. Persistent shell actually uses the JNI to maintain a persistent shell connection. It should not hang and will provide a shell interface that feels very similar to an installed Android Terminal Emulator app. It provides a "$" prompt when working correctly.

The thing that confuses me is that this functionality works perfectly on an ICS emulator but it has caused problems on devices, that is why I have actually ordered myself a Nexus now to see for myself :)

Tyrone

[mattph76]

Thanks for the information on the persistent shell.

I just tried removing armeabi/libjackpal (in addition to the Shell.java line 37 comment) and then rebuilding - the persistent shell seems to work fine on a ICS emulator for me as well but still not on the Galaxy Nexus.

[luander]

I'm so sad that the fix is not working properly.
The shell->persistent isn't working, I'll study the code, maybe I figure out what's happening.

[metall0id]

I am suspecting that the problem is in the read() function in Shell.java. Maybe that while loop's condition never equals false and so it hangs there

[luander]

I've made a fix that is working properly on ICS, including Shell-> Persistent Feature. I've created a patch to be applied, how can I submit that to the repository?

[mattph76]

Luander, I'm not sure about how to post the fix to the repository as I'm new here but did have a question. It's probably unrelated to the Shell class, but I was wondering, have you had any luck getting the reverseshell module to work at all? Thanks!

[luander]

The reverseshell module doesn't work for me either. It always ask me to run the busybox module.

[metall0id]

Great luander, you can either follow this guide and create a pull request for me (see http://help.github.com/fork-a-repo/) OR you can send the patch to mercury [at] mwrinfosecurity.com and I will apply the patch.

With regards to the reverseshell module, first put busybox on the device by running setup.busybox. Then if you are connected to a wireless lan or you have some box available on the internet, open a netcat listener on that box. Then run the reverseshell module with the ip and port of the netcat listener and it gives you a shell on the Android device :) It is actually just a POC for getting a shell remotely from a malware perspective