Shark Jack Cable Starting Payload Reboot

[SecurityVCat]

Greetings!

I recently purchased a Shark Jack cable, and last night, I was able to successfully connect to the device on my network using a Galaxy Tablet A8. I ran several payloads - eight of the default sample map scans when I switched to attack mode, ipinfo, and net discover. I was able to successfully view the output of the payloads in the /root/loot folder through the Serial USB terminal program on the tablet.

After that, I started getting an error each time I switched to Attack mode. After entering the shell, I see root@shark:/# [*] Starting Payload. Then a timestamp and "reboot. system halted." This occurred at least 5 times consistently while I started troubleshooting the problem. I am not running a C2 cloud. All actions were on the local Shark Jack cable.

Troubleshooting steps:

1) I watched it boot up. The checksum verification said, "OK."

2) I can enter Arming mode without error and navigate between folders.

3) I tried to UPDATE_PAYLOADS again (it's running VERSION 1.2.0 firmware), and the issue didn't resolve.

4) I deleted the scan outputs in the root/loot/nmap folder in case a limitation on storage on the Shark Jack was causing the error.

5) I tried to update the firmware. When I ran UPDATE_FIRMWARE, it said that an update was available. It counted down, and then said that /tmp/firmware_check was missing. It exited immediately to the prompt. I did not unplug it at any time.

I'm stumped on how to resolve this error so that I can run payloads again. Any ideas?

[dark_pyrro]

At least number 5 has been discussed recently on Discord and that behavior seems to be related to how the script is set up in the UPDATE_FIRMWARE file itself.

[dark_pyrro]

Have you tried to feed it with some other kind of power source? I'm not sure how power hungry the SJC is (and what that tablet is able to provide), but it could at least be worth trying. Just to verify if the reboot/halt is happening due to not getting enough juice at some given moment.

[SecurityVCat]

I can try to do that this evening. The only other device I have to connect with is a MacBook, which had a spotty feed for serial USB console prior to moving to the tablet. Could you share a path where I might find logs that could help to diagnose this issue, if I'm able to get a serial connection on the Mac?

[dark_pyrro]

One way (that you already seem to have tried) is to monitor the serial output as the Shark boots up and executes the payload. I guess dmesg won't tell that much info. It depends on the reason for the reboot. Not sure if there's some kernel panic involved, in that case there should be log info for that. Not sure if the SJC is like some other OpenWrt devices, the crashlog might be located in /sys/kernel/debug/

[SecurityVCat]

I get the same result by connecting the Shark Jack cable to the MacBook for console while plugging into the network jack in Attack mode. I poked through dmesg earlier with no luck in finding anything. I didn't see anything in /sys/kernel/debug that gave me an answer. I poked through the various folders and read through the files.

[SecurityVCat]

I believe that I found an answer to fix my problem. And I have a related question. I was able to get an Ethernet connector working for the Macbook, so I could do additional reconnaissance on the problem through SSH.

When I ran 'cat' command on the payload.sh in the root folder, I saw that it was the last payload that I activated successfully - /recon/netdiscover/netdiscover-active-payload. I copied the sample nmap scan to a new file and renamed it payload.sh. When I turned the shark jack on in attack mode, it successfully started the sample nmap scan and completed it without rebooting the shark jack / halting the system. I believe the issue was the payload script for the active net discover scan, although I don't know why yet.

Related question. When we activate a payload, does the shark jack script write over the payload.sh file with that new file, which becomes the default whenever we load ATTACK mode?

[dark_pyrro]

I'm not sure if I miss some information, but does this issue occur on some specific payload script or all of them that you try after this problem has started to show (apart from the nmap one that you seem to have successfully executed lately)? You are aware of the fact that the active netdiscover payload includes the halt command, right? Not sure how that looks when executed manually using serial (and if it is comparable to the output of the payload you have problems with).

10 hours ago, SecurityVCat said:

payload.sh in the root folder

Do you put your payloads in /root/ ? Why not in /root/payload/ ? And just one payload file in that directory, either "payload.txt", "payload.sh" or "payload.py" ("payload" only as well as it seems form the execute_payload script, the py variant executed with Python, all the other using bash, not sure Python is available by default in later versions of the firmware though, it at least was on 1.0.x so the py part might be something left behind since those times).

[SecurityVCat]

I used the UPDATE_PAYLOADS command to get the current payloads. I copied the sample nmap script back to the script that runs automatically last night. Other than that, everything is in the same place it was when the Shark Jack shipped. I may have misremembered where the default payload.sh script is located which runs automatically.

The payload that gave me trouble was the netdiscover payload. I didn’t realize that it was running automatically after activating it. I thought the nmap script was still running at ATTACK mode. So, it looks like ACTIVATE for payloads writes over the script that runs automatically. I did not try other payloads after successfully running the nmap script last night. I haven’t poked through the netdiscover script yet fully. The halt command in the script appears to stop operations on the Shark Jack. I didn’t get any results in the output file in /root/loot for that script. The text file was empty. It halted immediately after starting to launch the payload.