187 replies to this topic

[Oxofrimbl]

Move the script to github:

 

please search for my username there, dont want to violate this board rules

Edited by Oxofrimbl, 17 January 2024 - 11:49 AM.

[mconsidine]

FWIW, this works  in python with the SS on a local network (doesn't need the jailbreak):

import socket
import json

HOST = 'YOUR.SS.IP.ADDRESS' 
PORT = 4700

def send_message(data):
    with socket.socket(socket.AF_INET, socket.SOCK_STREAM) as s:
        s.connect((HOST, PORT))
        s.sendall(data.encode())
        data = s.recv(1024)

    print('Received', repr(data))

def json_message(id, instruction):
    data = {"id":id, "method":instruction}
    json_data = json.dumps(data)
    print("Sending %s" % json_data)

    send_message(json_data + "\r\n")

    return json_data

cmdid = 0
json_message(cmdid, "pi_is_verified")
cmdid += 1
json_message(cmdid, "scope_get_equ_coord")
cmdid += 1
json_message(cmdid, "get_device_state")
cmdid += 1
json_message(cmdid, "pi_shutdown")

Edited by mconsidine, 17 January 2024 - 11:49 AM.

[mconsidine]

Sample exchange:

 

Sending {"id": 0, "method": "pi_is_verified"}
Received b'{"jsonrpc":"2.0","Timestamp":"5676.768787520","method":"pi_is_verified","result":true,"code":0,"id":0}\r\n'
Sending {"id": 1, "method": "scope_get_equ_coord"}
Received b'{"jsonrpc":"2.0","Timestamp":"5676.781728714","method":"scope_get_equ_coord","result":{"ra":15.446944,"dec":-43.850278},"code":0,"id":1}\r\n'

[kaicyung]

Awesome! Are these the full set of commands ss recognizes?

[Oxofrimbl]

You can use wireshark to logg all the messages alternativly a simple string search in the binary revealed:

 

pi@asiair:/boot/Image/patch $ strings ~/ASIAIR/bin/zwoair_imager  | grep method\"
[{"method": "get_connected_cameras","id": 261},{"method":"open_camera","params":["%s"],"id":248}]
[{"method": "get_connected_wheels","id": 261},{"method":"open_wheel","id":248}]
[{"method": "get_connected_focuser","id": 261},{"method":"open_focuser","id":248}]
[{"method": "set_page", "params":["%s"], "id": 261},{"id":262,"method":"clear_autosave_err"%s},{"method": "start_exposure","params":{"keep_autosave_dev":true},"id": 263}]
{"method":"close_camera","id":385}
{"method":"stop_capture","id":3439}
{"method": "guide", "params": [{"pixels": %g, "time": %d, "timeout": %d},%s], "id": 134}
{"method":"scope_get_cap","id":2442}
{"method":"get_app_state","id":652}
{"method":"loop","id":124}
{"method":"find_star","id":1413}
{"method":"flip_calibration","id":250}
{"method":"get_connected","id":458}
{"method":"scope_park","id":3691}
{"method":"scope_goto","params":[%g,%g],"id":37}
{"method":"scope_abort_slew","id":53}
{"method":"get_setting","params":["dither_raonly"],"id":1322}
{"method":"set_setting","params":[{"dither_raonly":%d}],"id":1308}
{"method":"scope_set_track_state","params":[%s],"id":1228}
{"method":"scope_set_target_pierside","params":["%s"],"id":1367}
{"method":"scope_move_left_by_angle","params":[%d],"id":3691}
{"method":"scope_move", "params":["none"],"id": 13}
{"method":"get_flip_calibration","id":273}
{"method":"scope_get_ra_dec","id":14}
{"method": "dither", "params": [%d, {"pixels": %g, "time": %d, "timeout": %d}], "id": 155}
{"method":"scope_get_location","id":914}
{"method":"scope_get_pierside","id":1192}
{"method":"scope_get_track_state","id":273}
{"method":"scope_get_target_pierside","id":1336}
{"method":"scope_sync","params":[%g,%g],"id":20}
{"method":"get_connected","id":832}
{"method":"get_setting","params":["guide_log_name"],"id":1322}
{"method":"scope_is_moving","id":526}
{"method":"close_wheel","id":408}
{"method":"scan_am5", "id": 13}
"method":"scan_am5"

Additional likly commands:

get_connected_cameras
get_camera_state
get_app_state
set_page
open_camera
close_camera
start_exposure
stop_exposure
set_sequence
get_sequence_number
get_sequence
delete_sequence
clear_sequence
reset_sequence_progress
set_sequence_setting
get_sequence_setting
get_target_sequences
set_plan
import_plan
get_plan
get_enabled_plan
list_plan
delete_plan
reset_plan
clear_plan
get_controls
set_control_value
get_control_value
get_camera_info
set_camera_bin
get_camera_bin
set_camera_exp_and_bin
get_camera_exp_and_bin
set_subframe
get_subframe
save_image
set_camera_16bit
get_camera_16bit
get_img_file_page_number
get_img_file_page_name
get_focal_length
set_focal_length
get_gain_segment
start_solve
stop_solve
get_solve_result
get_last_solve_result
get_connected_wheels
open_wheel
set_wheel_unidirection
get_wheel_state
get_wheel_slot_name
set_wheel_slot_name
get_wheel_setting
set_wheel_setting
get_wheel_position
set_wheel_position
calibrate_wheel
close_wheel
get_disk_volume
delete_image
test_connection
stop_send
pi_set_time
pi_get_time
pi_get_info
pi_is_verified
pi_vl805_version
pi_encrypt
pi_get_ap
pi_shutdown
pi_reboot
pi_station_scan
pi_station_set
pi_station_state
pi_station_select
pi_station_list
pi_station_remove
pi_station_auto_connect
pi_station_open
pi_station_close
pi_eth0_state
pi_set_eth0
get_dither
set_dither
add_list
add_obj
del_list
del_obj
rename_list
get_list
get_obj
set_img_name_field
get_img_name_field
can_liveview
set_pixel_size
can_abort_expose
get_connected_focuser
open_focuser
get_focuser_state
get_focuser_caps
get_focuser_value
set_focuser_value
move_focuser
get_focuser_position
stop_focuser
close_focuser
get_focuser_setting
set_focuser_setting
start_auto_focuse
stop_auto_focuse
set_polar_align_image
rm_polar_align_image
get_polar_align_image
start_polar_align
pause_polar_align
stop_polar_align
get_polar_axis
get_3p_pa_setting
set_3p_pa_setting
get_3p_pa_state
get_solve_obj
start_auto_goto
start_auto_goto_pixel
stop_auto_goto
set_app_setting
get_app_setting
pi_output_set
pi_output_get
pi_output_set2
pi_output_get2
get_power_supply
list_mass_storage
set_stack_type
start_stack
stop_stack
set_calib_frame
get_calib_frame
clear_stack
save_stack
get_stack_info
set_calib_param
get_calib_param
get_stack_setting
set_stack_setting
set_image_save_path
set_image_save_usb_disk
get_image_save_path
eject_disk
get_img_file_info
set_img_file_info
start_export_image
stop_export_image
get_merid_delta
set_merid_setting
get_merid_setting
get_constellations
get_comet_position
start_annotate
stop_annotate
get_annotate_result
is_img_file_annotated
start_find_star
stop_find_star
get_find_star_result
get_rtmp_config
set_rtmp_config
start_record_avi
stop_record_avi
start_avi_rtmp
stop_avi_rtmp
start_planet_stack
stop_planet_stack
clear_planet_stack
start_batch_stack
stop_batch_stack
clear_batch_stack
get_batch_stack_setting
set_batch_stack_setting
del_batch_stack_file
get_planet_position
clear_autosave_err
set_test_setting
get_test_setting
file_rename
can_format_emmc
is_downgraded
clear_downgrade
get_setting
set_setting
update_comet_txt
need_reboot
StreamingThread
get_auto_focus_img
get_stacked_img
get_current_img
my_write_canstop

[mconsidine]

Oh, no.  There are plenty more. e.g.

 

{"id":4,"method":"scope_get_equ_coord"}
{"id":5,"method":"scope_get_track_state"}
{"id":6,"method":"get_view_state"}
{"id":7,"method":"get_device_state"}
{"id":8,"method":"get_setting"}
{"id":9,"method":"get_stack_setting"}

{"id":22,"method":"iscope_start_view","params":{"mode":"star","target_ra_dec":[5.607780666420481,-5.376215526618665],"target_name":"M 42","lp_filter":true}}
{"id":23,"method":"get_focuser_position","params":{"ret_obj":true}}

 

(The id # is just the sequence the command was sent in.  As far as I can tell it can be anything)

 

I think writing an opensource program to control this is pretty straight forward.  The brute force way of getting the dictionary is to have a a tcp packet sniffers/logger and then for different activities e.g. a gazing session, a lunar session, a planetary session, a solar session .. work backwards from the logs.  Doesn't mean you'd find all of its capabilities but you wouldn't need to hack any software.  And if you happened to do this with a version of the app that had the hidden menu still running, you could probably figure out how to a) replicate it and b) figure out if the underlying capability is still in the code.

mconsidine

[mconsidine]

Or, do what Oxofrimbl just did.  The trick there is figuring out which can take parameters, as in the example I just posted.

mconsidine

[mconsidine]

FYI, that first list posted above for the asiair is a bit different from the equivalent "strings" output run on the Seestar

[billndotnet]

Oh, no.  There are plenty more. e.g.

 

{"id":4,"method":"scope_get_equ_coord"}
{"id":5,"method":"scope_get_track_state"}
{"id":6,"method":"get_view_state"}
{"id":7,"method":"get_device_state"}
{"id":8,"method":"get_setting"}
{"id":9,"method":"get_stack_setting"}

{"id":22,"method":"iscope_start_view","params":{"mode":"star","target_ra_dec":[5.607780666420481,-5.376215526618665],"target_name":"M 42","lp_filter":true}}
{"id":23,"method":"get_focuser_position","params":{"ret_obj":true}}

 

(The id # is just the sequence the command was sent in.  As far as I can tell it can be anything)

 

I think writing an opensource program to control this is pretty straight forward.  The brute force way of getting the dictionary is to have a a tcp packet sniffers/logger and then for different activities e.g. a gazing session, a lunar session, a planetary session, a solar session .. work backwards from the logs.  Doesn't mean you'd find all of its capabilities but you wouldn't need to hack any software.  And if you happened to do this with a version of the app that had the hidden menu still running, you could probably figure out how to a) replicate it and b) figure out if the underlying capability is still in the code.

mconsidine

 

Oh, no.  There are plenty more. e.g.

 

{"id":4,"method":"scope_get_equ_coord"}
{"id":5,"method":"scope_get_track_state"}
{"id":6,"method":"get_view_state"}
{"id":7,"method":"get_device_state"}
{"id":8,"method":"get_setting"}
{"id":9,"method":"get_stack_setting"}

{"id":22,"method":"iscope_start_view","params":{"mode":"star","target_ra_dec":[5.607780666420481,-5.376215526618665],"target_name":"M 42","lp_filter":true}}
{"id":23,"method":"get_focuser_position","params":{"ret_obj":true}}

 

(The id # is just the sequence the command was sent in.  As far as I can tell it can be anything)

 

I think writing an opensource program to control this is pretty straight forward.  The brute force way of getting the dictionary is to have a a tcp packet sniffers/logger and then for different activities e.g. a gazing session, a lunar session, a planetary session, a solar session .. work backwards from the logs.  Doesn't mean you'd find all of its capabilities but you wouldn't need to hack any software.  And if you happened to do this with a version of the app that had the hidden menu still running, you could probably figure out how to a) replicate it and b) figure out if the underlying capability is still in the code.

mconsidine

Correct, id number is arbitrary, it's fed back to the client in the response so the client knows what request is being responded to, so asyncronous functions can be managed.

[mconsidine]

While we're at it...

if you log into the seestar and then switch to /usr/bin

the following command

./indiserver indi_v4l2_ccd indi_lx200generic

 

will start an indi port on 7624 (found via nmap) that Kstars/Ekos recognizes.  I neglected to put in a scope definition, but its a nice start ...

 

This was on a linux box

 

mconsidine

[Oxofrimbl]

I think @mconsidine is working in a slightly different direction than I was.

However my side-journey is finished, basically you should be able to deploy the SW to a different arm based linux. See the GitHub project for some scripts i just uploaded there.

 

However if you need help getting into the RPCs let me know.

[kaicyung]

I have a reliable source with the upcoming firmware that access via ASI Air and AM5 ascom will be blocked. Be aware.

[Oxofrimbl]

Usual game between jailbreakers and manufactureres i guess. @kaiczung, what you mean in detail by the access via ASI Air, the complete device is the ASIAIR do you men the patch-backdoor/update will be patched?

 

ASCOM is typically the mount/equiptment protocol?

 

...guess we will see.

[kaicyung]

Yes, the backdoor is probably patched. I don't have the new firmware in hand so I can't confirm. ZWO has a AM5 ascom driver that is typically used to control the AM5 mount. We were able to use the same driver to control Seestar axis motor movement.

 

We will see how ZWO play the cat and mouse game. If this is indeed true, then they are aware of external effort to access Seestar. Hope they just rotate the comm ports and not anything more drastic.

[MikeCMP]

Since have access now, is it possible to install a start up scrip that cannot be overwritten to just grant ssh access on boot? If it can survive a firmware update we would be set regardless.

[billndotnet]

Output of ls ...

Hey, do me a favor? Can I see the output of 'ls -al /usr/bin/' ? I'm curious what the base install includes there, I can only see what's in the firmware updates.

[pupak]

https://www.facebook...comment_mention

 

From the post, if App AA bypasses SN CPU and FW detection, it can connect directly to AP SS50 in station mode and control all its devices. It would be interesting to investigate this phenomenon more closely and try to find an easier way to connect than described in the post.

[kaicyung]

Any update on whether the new Seestar app/firmware that was just released play nicely with the jailbreak script?

[billndotnet]

Since have access now, is it possible to install a start up scrip that cannot be overwritten to just grant ssh access on boot? If it can survive a firmware update we would be set regardless.

It's hard to speculate on what the upcoming patch is going to do, but there's any number of steps you can take to guarantee future access. Once you have shell access, you can add additional users and sudo access for yourself, as the simplest step. Adding your own ssh key to the pi user's .ssh/authorized_keys is another thing you can do.

It's going to be hard for them to deny access to any device that can be reverted to an older version of the OS. It's going to be impossible on the Pro, since the SD card is directly accessible.

[billndotnet]

Any update on whether the new Seestar app/firmware that was just released play nicely with the jailbreak script?

Well, let's crack it open and take a look.

For those that want to follow along at home, I'm using Windows Subsystem for Linux for these teardowns. (ZWO tried to accuse me of cracking the AAP password, perhaps not understanding exactly how little security there is in what they're doing.) I'm using Ubuntu, so you'll need the apktool package installed to get started. I'll include other needed packages below.

 

$ apt install apktool bzip2 binutils xz-utils
$ apktool d Seestar_1.14.0.apk
I: Using Apktool 2.3.4-dirty on Seestar_1.14.0.apk
I: Loading resource table...
I: Decoding AndroidManifest.xml with resources...
I: Loading resource table from file: /home/billn/.local/share/apktool/framework/1.apk
I: Regular manifest package...
I: Decoding file-resources...
I: Decoding values */* XMLs...
I: Baksmaling classes.dex...
I: Baksmaling classes2.dex...
I: Baksmaling classes3.dex...
I: Baksmaling classes4.dex...
I: Baksmaling classes5.dex...
I: Baksmaling classes6.dex...
I: Copying assets and libs...
I: Copying unknown files...
I: Copying original files...

This unpacks the APK in a sane manner so we can root through it. This process also works for the AAP apks. It will create a directory named for the APK we unpacked, so..

 

$ cd Seestar_1.14.0
$ ls
AndroidManifest.xml  assets  lib       res    smali_classes2  smali_classes4  smali_classes6
apktool.yml          kotlin  original  smali  smali_classes3  smali_classes5  unknown

$ cd assets
$ file iscope
iscope: bzip2 compressed data, block size = 900k

This is the compressed update that will be transferred to the Seestar. For the AAP, this will be called pi3_air or pi4_air. It might be in a slightly different location, but everything after this should be the same process for unpacking.

$ bunzip iscope
$ ls -al iscope*
-rwxrwxrwx 1 billn billn 33116160 Jan 27 18:58 iscope.out

$ file iscope.out
iscope.out: POSIX tar archive (GNU)

$ tar -xvf iscope.out
update_package.sh
deb/
deb/asiair_armhf.deb
deb/rsyslog_8.1901.0-1+deb10u2_armhf.deb
others/
others/npu/
others/npu/to_sync/
others/npu/to_sync/usr/
others/npu/to_sync/usr/bin/
others/npu/to_sync/usr/bin/rknn_server
others/npu/to_sync/usr/bin/query_npu_usage
others/npu/to_sync/usr/bin/start_usb.sh
others/npu/to_sync/usr/bin/start_rknn.sh
others/npu/to_sync/usr/lib/
others/npu/to_sync/usr/lib/libOpenVX.so.1.2
others/npu/to_sync/usr/lib/npu/
others/npu/to_sync/usr/lib/npu/rknn/
others/npu/to_sync/usr/lib/npu/rknn/plugins/
others/npu/to_sync/usr/lib/npu/rknn/plugins/libann_plugin.so
others/npu/to_sync/usr/lib/npu/rknn/memory_profile
others/npu/to_sync/usr/lib/libGAL.so
others/npu/to_sync/usr/lib/librknn_runtime.so
others/npu/to_sync/etc/
others/npu/to_sync/etc/init.d/
others/npu/to_sync/etc/init.d/S05NPU_init
others/npu/to_sync/etc/init.d/S60NPU_init
others/dnsmasq.conf
others/flash_power_led
others/imx462_CMK-OT1234-FV0_M00-2MP-F00.xml
others/nginx.conf
others/main_S50_1.6.5.bin
others/eaf.ko
others/imx462.ko
others/pwrled_gpio.ko

main_s50_1.6.5.bin is the binary that gets pushed to the mount controller using espressIf/esp32. This gets called by the imager process once it's started:
'python3 /etc/zwo/esptool/esptool.py -p /dev/ttyS5 -c esp32s3 write_flash 0x0000 /etc/zwo/esptool/espfirmware/bootloader.bin 0x8000 /etc/zwo/esptool/espfirmware/partition-table.bin 0xd000 /etc/zwo/esptool/espfirmware/ota_data_initial.bin 0x10000'


update_package.sh is the script that gets called to manage the update, it does a lot of different things. Since it's been ported forward from the AAP -> AM3/AM5 -> Seestar, it's.. a mess. 

We're going to crack open the asiair_armhf.deb package and take a look around.
 

$ cd deb
$ ar x asiair_armhf.deb
$ ls -al
total 42320
drwxrwxrwx 1 billn billn     4096 Jan 27 19:13 .
drwxrwxrwx 1 billn billn     4096 Jan 27 19:05 ..
-rwxrwxrwx 1 billn billn 21356160 Jan 25 23:18 asiair_armhf.deb
-rwxrwxrwx 1 billn billn     1548 Jan 27 19:13 control.tar.xz
-rwxrwxrwx 1 billn billn 21354420 Jan 27 19:13 data.tar.xz
-rwxrwxrwx 1 billn billn        4 Jan 27 19:13 debian-binary
-rwxrwxrwx 1 billn billn   615996 Dec  6 19:32 rsyslog_8.1901.0-1+deb10u2_armhf.deb

The 'ar' tool is part of the binutils package, referenced above.

'control.tar.xz' is something of a header file for the package, containing meta details.
'data.tar.xz' will have the meat of the package in it.

All debian packages contain at least these two files, so if you're unpacking other things (like the *-y packages on the AAP), they'll overwrite each other. Caveat utilitor. The .xz compression tools are in the xz-utils package, listed above.

 

$ unxz data.tar.xz
$ tar -xvf data.tar

./
./home/
./home/pi/
./home/pi/ASIAIR/
./home/pi/ASIAIR/asiair.sh
./home/pi/ASIAIR/bin/
./home/pi/ASIAIR/bin/AM_Test
./home/pi/ASIAIR/bin/Soft03Cmt.txt
./home/pi/ASIAIR/bin/air_ble
./home/pi/ASIAIR/bin/auto_shutdown.sh
./home/pi/ASIAIR/bin/bluetooth.sh
./home/pi/ASIAIR/bin/bsa_server
./home/pi/ASIAIR/bin/comets.py
./home/pi/ASIAIR/bin/common.sh
./home/pi/ASIAIR/bin/network.sh
./home/pi/ASIAIR/bin/old_log_mv.sh
./home/pi/ASIAIR/bin/planet.py
./home/pi/ASIAIR/bin/read_power_cm4.sh
./home/pi/ASIAIR/bin/read_power_mini.sh
./home/pi/ASIAIR/bin/read_power_rk.sh
./home/pi/ASIAIR/bin/run_update_pack.sh
./home/pi/ASIAIR/bin/searchSSIDIndex.py
./home/pi/ASIAIR/bin/set_timezone.sh
./home/pi/ASIAIR/bin/shutdownsvr.sh
./home/pi/ASIAIR/bin/start_INDI.sh
./home/pi/ASIAIR/bin/write_wpa_conf.sh
./home/pi/ASIAIR/bin/zwoair_daemon.sh
./home/pi/ASIAIR/bin/zwoair_guider
./home/pi/ASIAIR/bin/zwoair_imager
./home/pi/ASIAIR/bin/zwoair_updater
./home/pi/ASIAIR/config
./home/pi/ASIAIR/lib/
./home/pi/ASIAIR/lib/libyuv.so
./home/pi/ASIAIR/model/
./home/pi/ASIAIR/model/nanotrack_backbone_127_pre.rknn
./home/pi/ASIAIR/model/nanotrack_backbone_255_pre.rknn
./home/pi/ASIAIR/model/nanotrack_head_pre.rknn
./home/pi/ASIAIR/model/yolov5s_small.rknn
./home/pi/ASIAIR/sound/
./home/pi/ASIAIR/sound/en1.wav

Everything on the units runs as the 'pi' user. If you are tinkering, expect anything in this directory to be overwritten on each update.

The asiair.sh script is the parent startup process for all things ZWO. It will setup wireless bits, do some house keeping, and start the imager binary, which is the active heart of the whole kit and kaboodle.
AM_Test is likely for AM3/AM5 mount related testing of some kind. I'm assuming the base motor control design for the Seestar is a scaled down version of what was designed for those mount models.

Soft03Cmt.txt is a CSV formatted set of comet coordinates, if you want to make your own updates outside of ZWO's update cycle. I believe it's sourced from the minor planet center: https://www.minorpla...s/Soft03Cmt.txt

# From MPC106342
C/1995 O1 (Hale-Bopp),e,89.2742,282.7613,130.4139,177.1269,0.0004181,0.99497162,0.0000,03/29.6467/1997,2000,g -2.0,4.0
# From NK 1615
P/1996 R2 (Lagerkvist),e,2.6009,40.0092,333.3845,3.774642,0.1343973,0.31455159,173.1335,08/24.0/2022,2000,g 11.5,4.0

air_ble, bluetooth.sh, and bsa_server appear to be bluetooth specific, for talking to phones and tablets outside of a wifi context.
 

comets.py and planet.py are pyephem-based scripts for doing coordinate calculations. 

 

common.sh contains a bunch of shell functions that are loaded by other scripts in this directory. If you're looking for how the wifi is managed, the base functions are here and in network.sh, which also calls the searchSSIDindex.py script, because maybe someone doesn't know how to use 'read' in bash.

read_power_* are self-explanatory, these are voltage monitoring scripts for the various components. Keep in mind this is all forwarded from the AAP and AM3/AM5, so which one is specific to the Seestar needs some investigation.

run_update_pack.sh is the script called to execute the update_package.sh script that's used in ZWO's software updater, as well as the jailbreak method. It doesn't appear to be modified with anything resembling security updates.

settimezone.sh and shutdownsvr.sh are pretty obvious.

 

start_INDI.sh is vestigial, on the AAP it starts the INDI server. This is the script you'd want to modify if you want to try sideloading things that might be useful to you, but expect to be sad when cameras and focusers don't work. Ideally, this would be where interoperability with your other gear would take place, but I've beaten that dead horse enough, I feel.

write_wpa_conf.sh does what it says it does, and is also a giant security hole, an exercise I leave to the reader.

zwoair_daemon.sh gets called from the directory above, via the asiair.sh script, and starts up the binaries:
zwoair_guider is a stripped down PHD2, which handles guiding.
zwoair_imager is the core process that calls everything else, and handles mount control, camera control, stacking, etc.
zwoair_updater is what hosts the listening socket for receiving the update package.

Here's the major change for this version:

my_public.pem
-----BEGIN PUBLIC KEY-----
MIGfMA0GCSqGSIb3DQEBAQUAA4GNADCBiQKBgQDtEuy6oWJ30D9r57O7GRPLOH1f
0CU79bmrEP9L8YLmwXQgfRPTeegfmmUsVH9zPJFOxdGPqZgjb/U/cwcwu37uOEiW
DIANiICTqxnumsS8k68ZmFF6bIAuhyupXxwlCxSji6x19FkviCoJvteLx5wO/tyH
NyyMyvzq8hpLaYL14QIDAQAB
-----END PUBLIC KEY-----
write publickey fail
openssl dgst -sha1 -verify %s -signature %s %s
Verified OK
verify fail
verify_fail: sign
%srun_update_pack.sh "%s"
popen update script done

So it looks like they're adding package signing/signature verification of some sort, using openssl. This wasn't present in the 1.11 build. I'd hazard a guess that the tablet/phone client is sending along a signature for the update package, either generated before the app is shipped, with a private key kept back at headquarters, or embedded in the app somewhere.


Since the Plus, Mini, and Seestar are running Rockchip processors that include neural net processing chops, these are relevant to that feature set:
./home/pi/ASIAIR/lib/libyuv.so

./home/pi/ASIAIR/model/
./home/pi/ASIAIR/model/nanotrack_backbone_127_pre.rknn
./home/pi/ASIAIR/model/nanotrack_backbone_255_pre.rknn
./home/pi/ASIAIR/model/nanotrack_head_pre.rknn
./home/pi/ASIAIR/model/yolov5s_small.rknn

Libyuv.so is for scaling raw camera output.
The nanotrack rknn models seem to be for image analysis for comparing similar images and finding overlap, so these might be leveraging the NN chipset for managing mosaic alignment. Not my area of expertise, so I could be wrong, but it makes sense for the application.

Edited by billndotnet, 27 January 2024 - 11:44 PM.

[mconsidine]

FWIW, my access seems to remain the same.  Eg the python code I showed earlier still works.

mconsidine

[Oxofrimbl]

@billndotnet: the openssl certification was in place on the asiair before, it did run a SSL check against the licence file. I wouldnt be surprised if they now extent this for further usecases like verifing the update file. I am still waiting for an update of the AA they would need to change the binary. so any chance only goes in affect after the update was installed.

 

one more hint, i guess the .deb from ZWO are doing some postinstall iirc the re-pacakgeing from installed OSes dont capture this (like addint the asiair.sh to boot in rc.local )

[billndotnet]

@billndotnet: the openssl certification was in place on the asiair before, it did run a SSL check against the licence file. I wouldnt be surprised if they now extent this for further usecases like verifing the update file. I am still waiting for an update of the AA they would need to change the binary. so any chance only goes in affect after the update was installed.

 

one more hint, i guess the .deb from ZWO are doing some postinstall iirc the re-pacakgeing from installed OSes dont capture this (like addint the asiair.sh to boot in rc.local )

 

We're both correct, here:

# Currently unpacked apks
billn@Hadriel:/mnt/z/ZWO/APKs$ find . -name zwoair_updater
./ASIAIR_2.1.2/assets/patch/deb/home/pi/ASIAIR/bin/zwoair_updater
./Seestar_1.11.0/assets/deb/home/pi/ASIAIR/bin/zwoair_updater
./Seestar_1.14.0/assets/deb/home/pi/ASIAIR/bin/zwoair_updater

# Of the three, only the recent Seestar update has the openssl bits added
billn@Hadriel:/mnt/z/ZWO/APKs$ find . -name zwoair_updater | xargs grep openssl
Binary file ./Seestar_1.14.0/assets/deb/home/pi/ASIAIR/bin/zwoair_updater matches

# The imager has had it, as you mention, for license checks.
billn@Hadriel:/mnt/z/ZWO/APKs$ find . -name zwoair_imager | xargs grep openssl
Binary file ./ASIAIR_2.1.2/assets/patch/deb/home/pi/ASIAIR/bin/zwoair_imager matches
Binary file ./Seestar_1.11.0/assets/deb/home/pi/ASIAIR/bin/zwoair_imager matches
Binary file ./Seestar_1.14.0/assets/deb/home/pi/ASIAIR/bin/zwoair_imager matches

[Artimon]

 

We're both correct, here:

# Currently unpacked apks
billn@Hadriel:/mnt/z/ZWO/APKs$ find . -name zwoair_updater
./ASIAIR_2.1.2/assets/patch/deb/home/pi/ASIAIR/bin/zwoair_updater
./Seestar_1.11.0/assets/deb/home/pi/ASIAIR/bin/zwoair_updater
./Seestar_1.14.0/assets/deb/home/pi/ASIAIR/bin/zwoair_updater

# Of the three, only the recent Seestar update has the openssl bits added
billn@Hadriel:/mnt/z/ZWO/APKs$ find . -name zwoair_updater | xargs grep openssl
Binary file ./Seestar_1.14.0/assets/deb/home/pi/ASIAIR/bin/zwoair_updater matches

# The imager has had it, as you mention, for license checks.
billn@Hadriel:/mnt/z/ZWO/APKs$ find . -name zwoair_imager | xargs grep openssl
Binary file ./ASIAIR_2.1.2/assets/patch/deb/home/pi/ASIAIR/bin/zwoair_imager matches
Binary file ./Seestar_1.11.0/assets/deb/home/pi/ASIAIR/bin/zwoair_imager matches
Binary file ./Seestar_1.14.0/assets/deb/home/pi/ASIAIR/bin/zwoair_imager matches

So, I guess you recommand NOT to upgrade the firmware? Nether to go to the new app version 1.14.0, as it ask to upgrade the SS when running. 

Did sompeone yet try to add a new pi-user and do the firmware upgrade? So, is it still possible to SSH the SS as other-usr@pi ?

Thanks all for your job here !!!

Stéphane.

[Artimon]

Could someone yet do a dd dump of the Seestar to PC (Linux or Windows)?... and how?

I could SSH & copy all the directory structure & files, but would like to create "seestar.img" to test it on a raspberry Pi if the Seestar software is exploitable on a Pi ??

Tkx.