Jump to content

Shark Jack Cable wont Update Payloads or Firmware


parabellum1010

Recommended Posts

Just received the shark jack cable.  Connects fine via serial using my phone.  I am able to get an IP using NETMODE DCHP_CLIENT.  I am able to ping google etc.  When I do an UPDATE PAYLOADS I get the following error:

tar: can't open `/tmp/payloads-sync.tar.gz` : No such file or directory

cp: can't stat `/tmp/payloads-sync/sharkjack=-payloads-master/payloads/

 

When I attempt an UPDATE FIRMWARE (on version 1.2.0 currently) it tells me there is an update available, counts down from 10 and then I get the error:

Firmware update file is missing. Exiting.

 

Any help with this would be appreciated.  Thanks.

Link to comment
Share on other sites

2 hours ago, parabellum1010 said:

Any help with this would be appreciated

Regarding UPDATE PAYLOADS; can you run the following commands in an ssh session logged in to the Shark?
MASTER_URL="https://github.com/hak5/sharkjack-payloads/archive/refs/heads/master.tar.gz"
curl -sL $MASTER_URL -o /tmp/payloads-sync.tar.gz

 

Regarding UPDATE_FIRMWARE there seems to be some stuff that isn't working properly. The text below is from when I recently tried to help a user on Discord with similar problems.

_______

I don't have the SJC but from what I can see in the version of the UPDATE_FIRMWARE file that I have access to, it seems as if wget can't successfully download the information needed to create the /tmp/firmware_check file (in the "check_for_upgrade" function). This makes it impossible to cat the file (as the error message shows). This then ruins the if statement that follows since the remote_version variable will be set to nothing and when comparing that with the local_version variable, a diff occurs which makes it return "true" and then says "There is an update available!" even if there's actually no new version available. This continues to execute and kicks off the "execute_upgrade" function, and here's the next thing (if following the UPDATE_FIRMWARE file that I have access to, might not be the same as on the released SJC, keep that in mind). Before the "execute_upgrade" function is called, there's a download being made. This is not properly linked though if the device is a SJC. It sources the firmware file (using curl this time) from https://downloads.hak5.org/api/devices/sharkjack/firmwares/, but..... the SJC firmware file is located at https://downloads.hak5.org/api/devices/sharkjack-cable/firmwares/ which might be the reason to why the "execute_upgrade" function shows the "Firmware update file is missing. Exiting." message. Perhaps this is changed in some newer version of the UPDATE_FIRMWARE file that is shipped with the device.

You can also verify if this is the case (my attempt to find a reason for it all) by viewing the UPDATE_FIRMWARE file on your SJC. Not sure about the exact location, but it's probably somewhere in /usr (I'm guessing /usr/bin )

The if statement that is used in the beginning of the "check_for_upgrade" function also needs to be used further down in the same function when the actual firmware file is to be downloaded (or just use the if statement once in the beginning of the function and set some kind of "SJC flag" that can be re-used). I would also add some check that the "remote_version" variable is populated and not empty and/or check if the file /tmp/firmware_check actually exists. If not, throw an error and exit. (Speculating a bit here since I'm doing all of these assumptions "black box").

_______

ok, then it should know to use the proper info to download to determine the available SJC firmware version
run the following manually from the terminal and verify that the /tmp/firmware_check file is created
URL="https://downloads.hak5.org/api/devices/sharkjack-cable/firmwares"
wget $URL -qO /tmp/firmware_check

_______

This is the "workaround" that the Discord user used to make it work temporarily:
I just manually added a file and named it firmware_check.
in the file I wrote the content of your URL above

Link to comment
Share on other sites

18 hours ago, dark_pyrro said:

Regarding UPDATE PAYLOADS; can you run the following commands in an ssh session logged in to the Shark?
MASTER_URL="https://github.com/hak5/sharkjack-payloads/archive/refs/heads/master.tar.gz"
curl -sL $MASTER_URL -o /tmp/payloads-sync.tar.gz

So I SSH in, I enter both commands and I get no output message, just back to a prompt, no curl downloading indication.  I checked the tmp directory and the tar.gz is not there so it seems it is not pulling the file.

Link to comment
Share on other sites

Ok this has been resolved =).  I downloaded the tar.gz file based off the github link you provided and renamed it to payloads-sync.tar.gz. I found, however, that after copying the tar.gz over using SCP and running UPDATE_PAYLOADS the tmp folder was getting cleaned first, deleting the tar.gz that I uploaded.    SO I then SSHed into the sharkjack and I found the UPDATE_PAYLOADS script under /usr/bin.  In the script it was wiping the tmp directory so I commented out those lines, and I also commented out the line where it attempted to download the file from github.  I saw on another post that someone else was having this same problem and they believed it had something to do with github security certificate.  He stated he added the -k flag but this did not seem to help me.  So I copied over the tar.gz file again and re-ran the script and it worked this time.  

So all in all, I am posting this for anyone else having problems.

Link to comment
Share on other sites

I encountered this error as well today. I didn't know about this forum unill now so I posted an issue on github; https://github.com/hak5/sharkjack-payloads/issues/53

The problem seems to be that wget are unable to verify the ssl certificate from 'downloads.hak5.org'. After some more testing I also saw that wget was unable to verify many more certificates, such as wikipedia, google, etc;

root@shark:~# wget https://wikipedia.org -O /tmp/wikipedia
Downloading 'https://wikipedia.org'
Connecting to 91.198.174.192:443
Connection error: Invalid SSL certificate
root@shark:~# wget https://google.com -O /tmp/google
Downloading 'https://google.com'
Connecting to 142.250.74.78:443
Connection error: Invalid SSL certificate

My guess is that shark jack either has really old CA repository or wget are unable to verify against the CA repository on the shark jack.

Link to comment
Share on other sites

This is getting really annoying. pip is also affected by this (maybe because it also uses wget):

root@shark:~# pip3 install netifaces
Collecting netifaces
  Retrying (Retry(total=4, connect=None, read=None, redirect=None, status=None)) after connection broken by 'SSLError(SSLError(1, '[SSL: CERTIFICATE_VERIFY_FAILED] unknown error (_ssl.c:852)'),)': /simple/netifaces/
[...]
Could not fetch URL https://pypi.org/simple/pip/: There was a problem confirming the ssl certificate: HTTPSConnectionPool(host='pypi.org', port=443): Max retries exceeded with url: /simple/pip/ (Caused by SSLError(SSLError(1, '[SSL: CERTIFICATE_VERIFY_FAILED] unknown error (_ssl.c:852)'),)) - skipping

 

The /etc/ssl/certs/ directory does exist with many certificates. The /etc/ssl/cert.pem points to /etc/ssl/certs/ca-certificates.crt which also exists.

I believe that there's either an old ca-certificates.crt or wget are not using the /etc/ssl/* correctly.

Please look into this.

Link to comment
Share on other sites

Got an update from Darren. The problem seems to be with the date and not the CA database 😄

Here's an easy fix for it:

root@shark:/# curl https://downloads.hak5.org
curl: (51) Error
root@shark:/# date
Mon Aug 23 23:37:01 UTC 2021
root@shark:/# ntpd -q -p 1.openwrt.pool.ntp.org
root@shark:/# date
Tue Mar 29 07:46:03 UTC 2022
root@shark:/# curl https://downloads.hak5.org
<!doctype html>
[...]

 

Link to comment
Share on other sites

  • 2 months later...
On 3/29/2022 at 4:33 PM, idarlund said:

Got an update from Darren. The problem seems to be with the date and not the CA database 😄

Here's an easy fix for it:

root@shark:/# curl https://downloads.hak5.org
curl: (51) Error
root@shark:/# date
Mon Aug 23 23:37:01 UTC 2021
root@shark:/# ntpd -q -p 1.openwrt.pool.ntp.org
root@shark:/# date
Tue Mar 29 07:46:03 UTC 2022
root@shark:/# curl https://downloads.hak5.org
<!doctype html>
[...]

 

it worked when i did the update initially , but alot of the packages didnt actually update it seems 

Link to comment
Share on other sites

  • 2 months later...

Here is a solution I came up with to sync the date over SSH when in ARMING mode and no Internet connectivity is present:

 

ssh root@172.16.24.1 "date -s '$(date '+%Y-%m-%d %H:%M:%S')'"

 

It simply takes the date from the host and sets it using busybox date.

I also installed chrony, which is far superior for synchronizing time on devices that are frequently switched off.

Link to comment
Share on other sites

  • 3 weeks later...

Just sync the clock&date.

I used ntpd -q -p 1.openwrt.pool.ntp.org and after that all woks just fine.

 

See the terminal output below(notice the "Signature check failed" message in line nr 5):

root@shark:/# opkg update
Downloading http://downloads.hak5.org/packages/shark/1907//Packages.gz
Updated list of available packages in /var/opkg-lists/1907_shark
Downloading http://downloads.hak5.org/packages/shark/1907//Packages.sig
Signature check failed.
Remove wrong Signature file.
Downloading http://downloads.openwrt.org/releases/18.06-SNAPSHOT/targets/ramips/mt76x8/packages/Packages.gz
Updated list of available packages in /var/opkg-lists/openwrt_core
Downloading http://downloads.openwrt.org/releases/18.06-SNAPSHOT/targets/ramips/mt76x8/packages/Packages.sig
Signature check passed.
Downloading http://downloads.openwrt.org/releases/18.06-SNAPSHOT/packages/mipsel_24kc/base/Packages.gz
Updated list of available packages in /var/opkg-lists/openwrt_base
Downloading http://downloads.openwrt.org/releases/18.06-SNAPSHOT/packages/mipsel_24kc/base/Packages.sig
Signature check passed.
Downloading http://downloads.openwrt.org/releases/18.06-SNAPSHOT/packages/mipsel_24kc/luci/Packages.gz
Updated list of available packages in /var/opkg-lists/openwrt_luci
Downloading http://downloads.openwrt.org/releases/18.06-SNAPSHOT/packages/mipsel_24kc/luci/Packages.sig
Signature check passed.
Downloading http://downloads.openwrt.org/releases/18.06-SNAPSHOT/packages/mipsel_24kc/packages/Packages.gz
Updated list of available packages in /var/opkg-lists/openwrt_packages
Downloading http://downloads.openwrt.org/releases/18.06-SNAPSHOT/packages/mipsel_24kc/packages/Packages.sig
Signature check passed.
Downloading http://downloads.openwrt.org/releases/18.06-SNAPSHOT/packages/mipsel_24kc/routing/Packages.gz
Updated list of available packages in /var/opkg-lists/openwrt_routing
Downloading http://downloads.openwrt.org/releases/18.06-SNAPSHOT/packages/mipsel_24kc/routing/Packages.sig
Signature check passed.
Downloading http://downloads.openwrt.org/releases/18.06-SNAPSHOT/packages/mipsel_24kc/telephony/Packages.gz
Updated list of available packages in /var/opkg-lists/openwrt_telephony
Downloading http://downloads.openwrt.org/releases/18.06-SNAPSHOT/packages/mipsel_24kc/telephony/Packages.sig
Signature check passed.

 

Link to comment
Share on other sites

  • 7 months later...

Im really stuck atm , i have the same problem but all thata been posted here as a solution doesnt work for me ? Or im probably doing something wrong ? 

 

root@shark:/# 
root@shark:/# ntpd -q -p 1.openwrt.pool.ntp.org
ntpd -q -p 1.openwrt.pool.ntp.org
root@shark:/# 
root@shark:/# date
date
Mon Aug 23 19:31:27 UTC 2021
root@shark:/# 
root@shark:/# [  127.122755] random: crng init done
ntpd -q -p 1.openwrt.pool.ntp.org
ntpd -q -p 1.openwrt.pool.ntp.org
root@shark:/# 
root@shark:/# date
date
Mon Aug 23 19:32:51 UTC 2021

Link to comment
Share on other sites

It does have internet connected when i plug it in and turn connectivity on but it just dont wanna change the time when i tried the updates it deleted everything even the out of the box nmap scan payload lol

Link to comment
Share on other sites

12 minutes ago, eYe said:

It does have internet connected when i plug it in and turn connectivity on

In what way do you "turn connectivity on"?

What's the output when you run

ping www.google.com

on the Shark?

13 minutes ago, eYe said:

when i tried the updates it deleted everything even the out of the box nmap scan payload

Not sure how this is related to the issue. What updates did you try? And when you say "it deleted everything"; what is "everything"?

Link to comment
Share on other sites

On 3/23/2022 at 9:51 PM, Fyzzlefry said:

I ran into this issue today.  To fix the UPDATE_PAYLOADS I went into /usr/bin and edited UPDATE_PAYLOADS.

I changed the curl line to: curl -k -L $MASTER_URL -o /tmp/payloads-sync.tar.gz

Saved it and it worked after that. 

I wanna try to change the curl line to try if that does work,  but it wont let me edit in the usb terminal 

Link to comment
Share on other sites

7 minutes ago, dark_pyrro said:

In what way do you "turn connectivity on"?

What's the output when you run

ping www.google.com

on the Shark?

Not sure how this is related to the issue. What updates did you try? And when you say "it deleted everything"; what is "everything"?

NETMODE DCHP_CLIENT
NETMODE DCHP_CLIENT
Usage: /usr/bin/NETMODE [DHCP_CLIENT|DHCP_SERVER|AUTO]

root@shark:/# 
root@shark:/# ping www.google.com
ping www.google.com
ping: bad address 'www.google.com'
root@shark:/# 
root@shark:/# 

Link to comment
Share on other sites

I didnt delete anything but when i tried to update payloads it just clears the rest but it doesnt update any so nothing new comes on it i dont delete anything just made a backup of the payloads in the usr/bin to edit the curl line only in the usb terminal it dont let me edit 

Link to comment
Share on other sites

Google ping.

64 bytes from 172.217.23.196: seq=282 ttl=119 time=10.925 ms
64 bytes from 172.217.23.196: seq=283 ttl=119 time=11.319 ms
64 bytes from 172.217.23.196: seq=284 ttl=119 time=11.592 ms
64 bytes from 172.217.23.196: seq=285 ttl=119 time=12.428 ms
64 bytes from 172.217.23.196: seq=286 ttl=119 time=11.216 ms
64 bytes from 172.217.23.196: seq=287 ttl=119 time=11.086 ms

 

pin 1.1.

 

64 bytes from 1.1.1.1: seq=31 ttl=59 time=11.481 ms
64 bytes from 1.1.1.1: seq=32 ttl=59 time=11.219 ms
64 bytes from 1.1.1.1: seq=33 ttl=59 time=11.239 ms
64 bytes from 1.1.1.1: seq=34 ttl=59 time=11.280 ms
64 bytes from 1.1.1.1: seq=35 ttl=59 time=10.755 ms
64 bytes from 1.1.1.1: seq=36 ttl=59 time=11.270 ms
64 bytes from 1.1.1.1: seq=37 ttl=59 time=11.530 ms

Link to comment
Share on other sites

Archived

This topic is now archived and is closed to further replies.

  • Recently Browsing   0 members

    • No registered users viewing this page.
×
×
  • Create New...