Rotatable Camera Dual-Band not booting after patch (V3.2863.94)

[Ancientkingg]

I'm on firmware version V3.2863.94 for the dual-band rotatable camera. I followed Option 3 of the README guide.

After following the guide it seems like the camera does not want to start anymore. It does not connect to WIFI. It also does not perform the startup ritual of turning either anymore. It still gives a single thud sound though that's normally part of the startup ritual, but that's the only thing it does. The blue light in the front just stays on.

It seems like when I put the anyka_ipc_rtsp file on the SD card, these issues occur. Up until step 12 (Option 1, but following Option 3), the camera boots fine (doing the startup ritual).

I have attached the contents of my SD card here after following all the steps of Option 3 of the README. Could it be that V3.2863.94 changed some settings, preventing this patch from working? Or could I be doing something wrong?

[Ancientkingg]

So before putting the anyka_ipc_rtsp file on the SD card and using the anyka_ipc extracted from binwalk, the app still reports the firmware to be V3.2863.94

Is that supposed to be the case?

[Ancientkingg]

It seems like the camera briefly connects to WIFI if I boot it without SD card and then boot it WITH the SD card.

[Ancientkingg]

So before putting the anyka_ipc_rtsp file on the SD card and using the anyka_ipc extracted from binwalk, the app still reports the firmware to be V3.2863.94

Is that supposed to be the case?

It seems like the modified anyka_ipc is still doing something however. When I run a port scan without SD card the device reports 1 port open (6668), but with an SD card containing the extracted anyka_ipc from binwalk ports 23, 24, 6668 and 8080 are open.

[Ancientkingg]

It seems like the webserver and telnet work completely fine as well. It's only when I add the anyka_ipc_rtsp file the camera breaks.

[Ancientkingg]

It also seems like the motor functions don't work.

[Ancientkingg]

It seems like the same problem occurs on V3.2863.93

[Ancientkingg]

Telnet gives the following:

~ # cd /usr/share
/usr/share # cat VERSION
3.2863.93.1317
/usr/share # cat BUNDLE
HT_IPC286KSD3M_TUYA_AK3918EV330

[vladislabv]

@Ancientkingg Same problem to me. It breaks on line "mount --bind /tmp/anyka_ipc_rtsp /usr/bin/anyka_ipc". Seems that the options 3 doesn't work for the patch.

[Ancientkingg]

@vladislabv How did you figure out on what line it breaks?

[Ancientkingg]

@vladislabv How did you figure out on what line it breaks?

Are you having the exact same issues as me or slightly different?

[vladislabv]

@vladislabv How did you figure out on what line it breaks?

I tried to comment out lines in the "hack.sh" file, so that I figured out the line :)

[vladislabv]

Are you having the exact same issues as me or slightly different? Yep, exactly the same.

[Ancientkingg]

@Ancientkingg Same problem to me. It breaks on line "mount --bind /tmp/anyka_ipc_rtsp /usr/bin/anyka_ipc". Seems that the options 3 doesn't work for the patch.

From this line it seems like something in the patch breaks the ROM. At this point (from my own POV) I don't think there's any saving other than writing a new patch for this version, as I think the suspected reason for this happening is simply that too much has changed between the current firmware version and the one we're trying to use from V2.

I'll see if I can look at what exactly @guino did to actually patch the original ROM, since he did leave some clues on how he did it (using Ghidra and some existing RTSP functionality left in the ROM), but at this point it's looking very bleak.

[Ancientkingg]

After some further exploring, it seems like it's purely related to the firmware version simply being too new (differing too much). I tried loading the anyka_ipc file without the patch and that seems to also brick the camera.

[Ancientkingg]

So I am in the middle of reverse engineering both guino's patch, as well as the new V3 firmware. A lot of the leg work has already been laid out for me by (I assume) guino. This allowed me to easily dump the firmware, which I could decompile using Ghidra.

I did this for both the original V2, the patched version V2, as well as the new V3. After initial analysis on the decompiled code, although somewhat similar, it seems like V3 definitely differs quite a lot from V2 and that is probably also the root cause of the camera bricking when trying the patched firmware.

From what I could understand by comparing the patched version to the original unpatched version is that all of the RTSP functionality is already implemented, just not activated. This is locked behind some factory test mode (using a flag). I believe the patched version slightly modifies the main function of the firmware to simply ignore if the flag is set or not and performs a slightly modified factory mode procedure. See below for the relevant decompiled code, truncated for clarity.

// Original unpatched V2 
local_15c = 0;
ht_config_get_int(1,"net_mode",&local_15c,0);
ht_system_ctrl_init();
ht_montion_detect_init();
ht_pir_detect_init();
ht_night_mode_init();
ht_system_set_reset_cb(ht_system_reset);
if (local_c == 1) {
  ht_audio_codec_start_encode(1,4);
  ht_network_init(0);
  ht_audio_codec_play_audio_file("/usr/share/8k16_cn_factory_enter_factory_mode.mp3"); // Plays chinese voice prompt
  ht_factory_test_enter(); // Actually starts the rtsp session
  ht_factory_test_set_check_id_cb(ht_check_id_valid_cb);
  do {
    if (DAT_0043427c == '\0') goto LAB_0008b358;
    iVar2 = ht_network_get_connect_state();
  } while (iVar2 == 0);
  ht_audio_codec_play_audio_file("/usr/share/hutong_sound2.mp3"); // Plays pleasant 3 beeps/chimes
  ht_sync_utc_time();
  ht_set_timezone(0x7080);
  local_55c = 0x6c637768;
  uStack1368 = 0x206b636f;
  local_554 = 0x772d;
  local_552 = 0;
  SystemCall_msg(&local_55c,0);
} else if (local_c == 2) {
  ht_rtsp_start(0);
}

The LOC that actually seems to start the rtsp session is actually not ht_rtsp_start(0); (I think for now at least). From what I could tell the actual LOC that is responsible for that is ht_factory_test_enter(); which when viewed, contains the following:

// ...
create_rtsp_session(*(undefined4 *)(iStack16 + 0x104),"/main_ch",0x4004,1)
// ...

Keep in mind the value of local_c is determined as follows in pseudocode:

if not factory_test_mode and not file_exists(_ht_ap_mode.conf) return 0;
if factory_test_mode return 1;
if factory_test_mode and file_exists(_ht_ap_mode.conf) return 2;

This seems somewhat familiar with what I could get from the README, which mentions you can access the RTSP server under rtsp://ip/main_ch.

What the patched version does is the following:

// Patched V2
local_15c = 0;
ht_config_get_int(1,"net_mode",&local_15c,0);
ht_system_ctrl_init();
ht_montion_detect_init();
ht_pir_detect_init();
ht_night_mode_init();
ht_system_set_reset_cb(ht_system_reset);
ht_audio_codec_start_encode(1,4);
ht_network_init(local_15c);
ht_audio_codec_play_audio_file("/usr/share/8k16_cn_factory_enter_factory_mode.mpp"); // Last letter is explicitly changed to prevent this from playing (maybe?)
ht_factory_test_enter();
ht_factory_test_set_check_id_cb(ht_check_id_valid_cb);
if (local_c == 2) {
    ht_rtsp_start(0);
}

It repurposes the factory test code section to launch in some sort of hybrid mode, enabling rtsp but not enabling everything from the original factory test mode.

The only thing I don't understand is why the patched version is using/repurposing ht_factory_test() to start the rtsp session as oppose to using ht_rtsp_start(0).

I believe it is possible to develop a patched version for V3, since the relevant code mostly seems similar enough:

// V3

if (local_c == 1) {
  ht_audio_codec_start_encode(1,4);
  if ((local_15c == 1) || (local_15c == 3)) {
    ht_network_init(1);
  }
  else {
    ht_network_init(0);
  }
  ht_audio_codec_play_audio_file("/usr/share/8k16_cn_factory_enter_factory_mode.mp3"); // Chinese voice prompt
  ht_factory_test_enter();
  uVar1 = ak_ipc_get_version();
  ht_factory_test_set_sys_version(uVar1);
  ht_factory_test_set_check_id_cb(ht_check_id_valid_cb);
  do {
    if (DAT_0051bf98 == '\0') goto LAB_000a9188;
    iVar2 = ht_network_get_connect_state();
  } while (iVar2 == 0);
  ht_audio_codec_play_audio_file("/usr/share/hutong_sound2.mp3"); // Plays 3 quick pleasant beeps/chimes
  ht_sync_utc_time();
  ht_set_timezone(0x7080);
  local_568 = 0x6c637768;
  uStack1380 = 0x206b636f;
  local_560 = 0x772d;
  local_55e = 0;
  SystemCall_msg(&local_568,0);
}
else if (local_c == 2) {
  ht_rtsp_start(0);
}

If everything is largely unchanged (and all goes well 🤞) then the only thing I would need to do is try to patch the code to ignore the condition for local_c == 1 and to slightly change some function call parameters.

[Ancientkingg]

This is all of the current progress I have right now, but I will continue to see if it is possible to develop a new patched version for V3 and keep this thread updated with my new findings.

[Ancientkingg]

Looking at the (patched) code it also explains why there are issues like #26, which can be explained by the ht_audio_codec_play_audio_file("/usr/share/8k16_cn_factory_enter_factory_mode.mp3"); // Plays chinese voice prompt LOC.

[Ancientkingg]

The only thing I don't understand is why the patched version is using/repurposing ht_factory_test() to start the rtsp session as oppose to using ht_rtsp_start(0).

I believe there is one key difference between the two functions, which relates to audio being sent over. The ht_factory_test callstack contains one key line:

// ht_factory_test
// ...
ht_audio_codec_set_get_aenc_cb(1,send_audio_frame_aac);
// ...

This line sets the audio encoding callback, which is named send_audio_frame_aac. Looking into this function it seems to boil down to sending audio over rtsp. This line is not present in the rtsp_start callstack, so I believe guino purposefully repurposed the ht_factory_test callstack to enable rtsp since it also enables audio over rtsp.

[Ancientkingg]

I initially tried to get rid of the if statement, but that seemed to not actually start the RTSP server. I verified if my patch was working by inserting a line that played some custom audio and upon startup the camera actually did play my audio (although very poorly). Nonetheless this means that the patch must be doing something else apart from just this simple change.

So to figure out exactly what the patch was doing differently I ran a diff in Ghidra between the original V2 and the patched V2 and it turns out there's more difference than I initially thought. It's doing quite a lot actually!

This function in particular has changed quite a lot (see picture below) and at the moment I genuinely have no clue what the patched version is actually doing. All I know is that the original assembly (right side of picture) makes a call to wirte_log, which simply writes something to the log. What all these weird offsets with r11 mean, I have absolutely no clue.

This is what the original function is doing:

void UndefinedFunction_00081474
               (undefined4 param_1,undefined4 param_2,undefined4 param_3,undefined4 param_4,
               uint param_5,int param_6)

{
  if (g_ht_factory_test._260_4_ == 0) {
    wirte_log(2,3,0,"/home/hutong/work/anyka_330/SDK_V1.02_ht/platform/ipcam/src/ht_factory_test.c" ,
              0x3ca,"type:%d, timestamp:%lld",param_3);
  }
  else {
    rtsp_sever_tx_video(g_ht_factory_test._260_4_,g_ht_factory_test._264_4_,param_1,param_2,
                        (int)((ulonglong)param_5 * 1000),
                        param_6 * 1000 + (int)((ulonglong)param_5 * 1000 >> 0x20));
  }
  return;
}

and this is what the patch transforms it to:

void UndefinedFunction_00081474
               (undefined4 param_1,undefined4 param_2,undefined4 param_3,undefined4 param_4,
               uint param_5,int param_6)

{
  if (g_ht_factory_test._260_4_ != 0) {
    rtsp_sever_tx_video(g_ht_factory_test._260_4_,g_ht_factory_test._264_4_,param_1,param_2,
                        (int)((ulonglong)param_5 * 1000),
                        param_6 * 1000 + (int)((ulonglong)param_5 * 1000 >> 0x20));
  }
  FUN_000883c0(param_1,param_2,param_3,param_4,param_5,param_6);
  return;
}

It mostly looks the same, but something very interesting to look into is FUN_000883c0. So to give a bit more context, initially the original firmware called a function that would run TUYA_APP_Put_Frame. I believe what the patch is doing is hooking into a different function which sends video over rtsp. Now to still allow the original TUYA app to work, which is what TUYA_APP_Put_Frame is responsible for I think, the wirte_log call gets repurposed into FUN_000883c0, of which the contents make a call to TUYA_APP_Put_Frame.

I haven't really figured out what everything does yet and I think the most important thing to understand here is what actually the parameters are. Once I figure that out and that instruction mess pictured above, I think it should be doable to port to V3.

[Ancientkingg]

After further thought I think it's actually not that complicated. I think what the patch is trying to achieve is by hooking into this function to perform extra functionality, without changing existing functionality, in other words, sending video over rtsp without compromising sending video frames to TUYA. To achieve this it modifies the function mentioned above to send the rtsp and then all it does is forward all of the original parameters to the original function that took care of sending the video frames to TUYA.

[Ancientkingg]

Okay so after implementing all of the same patches in V3 that the original patch does, the RTSP still seems missing. I checked using nmap and 554 remains closed. Is it supposed to be the case that when the rtsp server starts that that port opens?

[vladislabv]

Okay so after implementing all of the same patches in V3 that the original patch does, the RTSP still seems missing. I checked using nmap and 554 remains closed. Is it supposed to be the case that when the rtsp server starts that that port opens?

I think yes, bc the default port the classic apps using (like VLC) is 554.

[vladislabv]

Okay so after implementing all of the same patches in V3 that the original patch does

Could you please share your work (patch and/or patched v3 version) in the thread? Thank you!

[Ancientkingg]

Okay so after implementing all of the same patches in V3 that the original patch does

Could you please share your work (patch and/or patched v3 version) in the thread? Thank you!

Here is the patched V3 firmware anyka_ipc_v3_patched.zip. Make sure to unzip it and rename it to anyka_ipc_rtsp. If the patch runs it should play some chinese message (indicating it's going into factory test mode), but keep in mind it doesn't start the rtsp server.

I suspect the code has significantly changed in V3, such that starting the rtsp session requires some more effort. I plan on looking in V3 where the socket is created for the rtsp server and then just following the callstack. Let me know if you need anything more from me.

[Ancientkingg]

The patched V3 version implements exactly the same hooks as the patched V2 version. For better or for worse...

[vladislabv]

Okay so after implementing all of the same patches in V3 that the original patch does

Could you please share your work (patch and/or patched v3 version) in the thread? Thank you!

Here is the patched V3 firmware anyka_ipc_v3_patched.zip. Make sure to unzip it and rename it to anyka_ipc_rtsp. If the patch runs it should play some chinese message (indicating it's going into factory test mode), but keep in mind it doesn't start the rtsp server.

I suspect the code has significantly changed in V3, such that starting the rtsp session requires some more effort. I plan on looking in V3 where the socket is created for the rtsp server and then just following the callstack. Let me know if you need anything more from me.

Are you sure it should produce playing message? I copied your patch under the right name and camera booted normally (as it would have no patch provided). I checked the mounts then per telnet, and the hack.sh script ran thru

[Ancientkingg]

Okay so after implementing all of the same patches in V3 that the original patch does

Could you please share your work (patch and/or patched v3 version) in the thread? Thank you!

Here is the patched V3 firmware anyka_ipc_v3_patched.zip. Make sure to unzip it and rename it to anyka_ipc_rtsp. If the patch runs it should play some chinese message (indicating it's going into factory test mode), but keep in mind it doesn't start the rtsp server. I suspect the code has significantly changed in V3, such that starting the rtsp session requires some more effort. I plan on looking in V3 where the socket is created for the rtsp server and then just following the callstack. Let me know if you need anything more from me.

Are you sure it should produce playing message? I copied your patch under the right name and camera booted normally (as it would have no patch provided). I checked the mounts then per telnet, and the hack.sh script ran thru

After looking carefully at the file that I actually sent, it turns out I sent a different patch. This patch tries to start the rtsp and run a custom sound file:

To play the sound file please put an mp3 file (8kb bitrate) in your SD card called a.mp3. It should play that sound file upon startup.

[Ancientkingg]

I have a different patch as well: anyka_ipc_v3_patched (2).zip. This one should run some extra sound (I think like 3 beeps/chimes) upon startup.

[Ancientkingg]

Or at least it should:

I am playing a sound in the function that is responsible for actually creating the rtsp session. I haven't had the chance to test it yet, as I am not home.

So there are 2 conclusions depending on the outcome (if the sound is played or not).

If the sound is not played, then that means the function is not running and not actually creating the rtsp session, which should be easily fixable. If the sound however does play, then that means the function actually runs, which means it should create an rtsp session, but for some other unknown reason is not.

[bramnauta]

I have a different patch as well: anyka_ipc_v3_patched (2).zip. This one should run some extra sound (I think like 3 beeps/chimes) upon startup.

I just tried this file on the rotatable camera on firmware V3.2863.93; the sound is not playing for me and netstat doesn't show the RTSP port:

~ # netstat -lapn
Active Internet connections (servers and established)
Proto Recv-Q Send-Q Local Address           Foreign Address         State       PID/Program name
tcp        0      0 0.0.0.0:23              0.0.0.0:*               LISTEN      450/telnetd
tcp        0      0 0.0.0.0:24              0.0.0.0:*               LISTEN      528/telnetd
tcp        0      0 0.0.0.0:6668            0.0.0.0:*               LISTEN      543/anyka_ipc_rtsp
tcp        0      0 0.0.0.0:8080            0.0.0.0:*               LISTEN      545/busybox
tcp        0      0 10.116.80.3:47406       35.156.44.172:8883      ESTABLISHED 543/anyka_ipc_rtsp
tcp        0    157 10.116.80.3:24          10.108.253.169:57921    ESTABLISHED 528/telnetd
tcp        0      0 10.116.80.3:38753       3.74.204.42:1443        CLOSE_WAIT  543/anyka_ipc_rtsp
udp        0      0 127.0.0.1:36380         0.0.0.0:*                           543/anyka_ipc_rtsp
udp        0      0 0.0.0.0:37946           0.0.0.0:*                           543/anyka_ipc_rtsp
udp        0      0 10.116.80.3:37186       0.0.0.0:*                           543/anyka_ipc_rtsp
udp        0      0 0.0.0.0:40631           0.0.0.0:*                           543/anyka_ipc_rtsp
udp        0      0 0.0.0.0:56777           0.0.0.0:*                           543/anyka_ipc_rtsp

I can't help with actually writing code as my C is very rusty and I haven't worked on firmware before, but let me know if there's anything I can do to help test.

EDIT: Actually, my firmware version might be 3.10.79; before I put anyka_ipc_rtsp on the SD card, this was the firmware version reported by the app. After putting the file on the SD card, that changed to 3.2863.93, but /usr/share/VERSION still shows 3.10.79.1272, so I'm not sure. If needed, I'm willing to remove the SD card and try updating from the app to 3.2863.93.

[Ancientkingg]

I have a different patch as well: anyka_ipc_v3_patched (2).zip. This one should run some extra sound (I think like 3 beeps/chimes) upon startup.

I just tried this file on the rotatable camera on firmware V3.2863.93; the sound is not playing for me and netstat doesn't show the RTSP port:

~ # netstat -lapn
Active Internet connections (servers and established)
Proto Recv-Q Send-Q Local Address           Foreign Address         State       PID/Program name
tcp        0      0 0.0.0.0:23              0.0.0.0:*               LISTEN      450/telnetd
tcp        0      0 0.0.0.0:24              0.0.0.0:*               LISTEN      528/telnetd
tcp        0      0 0.0.0.0:6668            0.0.0.0:*               LISTEN      543/anyka_ipc_rtsp
tcp        0      0 0.0.0.0:8080            0.0.0.0:*               LISTEN      545/busybox
tcp        0      0 10.116.80.3:47406       35.156.44.172:8883      ESTABLISHED 543/anyka_ipc_rtsp
tcp        0    157 10.116.80.3:24          10.108.253.169:57921    ESTABLISHED 528/telnetd
tcp        0      0 10.116.80.3:38753       3.74.204.42:1443        CLOSE_WAIT  543/anyka_ipc_rtsp
udp        0      0 127.0.0.1:36380         0.0.0.0:*                           543/anyka_ipc_rtsp
udp        0      0 0.0.0.0:37946           0.0.0.0:*                           543/anyka_ipc_rtsp
udp        0      0 10.116.80.3:37186       0.0.0.0:*                           543/anyka_ipc_rtsp
udp        0      0 0.0.0.0:40631           0.0.0.0:*                           543/anyka_ipc_rtsp
udp        0      0 0.0.0.0:56777           0.0.0.0:*                           543/anyka_ipc_rtsp

I can't help with actually writing code as my C is very rusty and I haven't worked on firmware before, but let me know if there's anything I can do to help test.

EDIT: Actually, my firmware version might be 3.10.79; before I put anyka_ipc_rtsp on the SD card, this was the firmware version reported by the app. After putting the file on the SD card, that changed to 3.2863.93, but /usr/share/VERSION still shows 3.10.79.1272, so I'm not sure. If needed, I'm willing to remove the SD card and try updating from the app to 3.2863.93.

Thank you for offering to help @bramnauta! I actually managed to get some significant progress. I succeeded in getting rtsp working for both video and audio. The only caveats being that the app stopped working, specifically it's showing an incorrect video stream and no audio. This is something fixable I believe so fingers crossed.

Since you mentioned specifically that your camera is on a different firmware version, could you try the patched version I linked below? If everything goes well the camera should give 3 grouped loud beeps twice (so 6 in total). If that's the case you should be able to access your camera through the original way specified in the readme, i.e. using any rtsp viewer you can visit rtsp://<ip>/main_ch.

Here is the patched version: anyka_ipc_v3_patched_test_3.zip

Make sure to rename it accordingly back to anyka_ipc_rtsp.

[Ancientkingg]

My next plans are to explore some more functionality that the camera has for rtsp. It's currently repurposing the factory_test mode to enable rtsp, but there is actually some functionality in the firmware for a dedicated rtsp mode.

I hope to also fix the app not working anymore with this patch too, as well as getting motor functions working.

[Ancientkingg]

If possible could you also try the new patched version with the instructions provided and let me know if you encounter any issues @vladislabv?

[bramnauta]

It is beeping six times now and the RTSP stream is working!

[vladislabv]

If possible could you also try the new patched version with the instructions provided and let me know if you encounter any issues @vladislabv?

Works also on 3.2863.94. There is some delay between real-time and rtsp stream, about 1 or 2 seconds. Also it sometimes slows down at moment and jumps over (like syncing maybe?). I tried playing the stream on VLC. Don't know if the problem happens only to me...

[Ancientkingg]

If possible could you also try the new patched version with the instructions provided and let me know if you encounter any issues @vladislabv?

Works also on 3.2863.94. There is some delay between real-time and rtsp stream, about 1 or 2 seconds. Also it sometimes slows down at moment and jumps over (like syncing maybe?). I tried playing the stream on VLC. Don't know if the problem happens only to me...

This might be something VLC related. Try using an RTSP client such as happytime for example: https://happytimesoft.com/

I use happytime personally and the response is much more real-time.

[vladislabv]

@Ancientkingg I wanted to ask if you have the original anyka_ipc file, which decompiles with ghydra? I tried using the file, which is copied by the hack.sh but ghidra shows some bad memory error by decompiling and cann't map functions at the end.

[Ancientkingg]

@Ancientkingg I wanted to ask if you have the original anyka_ipc file, which decompiles with ghydra? I tried using the file, which is copied by the hack.sh but ghidra shows some bad memory error by decompiling and cann't map functions at the end.

Are you completely sure that's the case? I used the original anyka_ipc file to make this patch. What version of ghidra do you use?

[vladislabv]

@Ancientkingg 11.2.1_Public

[Ancientkingg]

@Ancientkingg 11.2.1_Public

Could you send a screenshot of the error that you're getting? Or maybe even a video of how you start up ghidra with the file? I have had no issues so far as arm is supported quite well.

[vladislabv]

@Ancientkingg Sure. Here is the output when trying to import the file into a project:

` There were too many messages to display. 6250 messages have been truncated.

Loading file:///home/vstasenko/Projects/Smarthome/lsc-rotatable-camera/ghidra/anyka_ipc?MD5=62594cda7658b9ef08c175935670ac5e... Skipping section [SECTION0] with invalid file offset 0x749af32 Skipping section [SECTION1] with invalid file offset 0xea0013d1 Skipping section [SECTION2] with invalid file offset 0xf0084b51 Skipping section [SECTION3] with invalid file offset 0x84e3474d ... Unable to place symbol due to non-loaded section: uv_cond_signal - value=0x266844, section=SECTION11 Unable to place symbol due to non-loaded section: _ZN8CRingBuf16SetConsumerStateEjh - value=0x636d4, section=SECTION11 Unable to place symbol due to non-loaded section: p_8000_mono_short - value=0x3a91dc, section=SECTION14 Unable to place symbol due to non-loaded section: ht_tuya_av_capture_start - value=0xa7474, section=SECTION11 Unable to place symbol due to non-loaded section: AL_Rc_Vbr_Reset - value=0x1b03a8, section=SECTION11 Unable to place symbol due to non-loaded section: mbedtls_arc4_free - value=0x2f1050, section=SECTION11 Unable to place symbol due to non-loaded section: raac_kbdWindow - value=0x3a6514, section=SECTION14 Unable to place symbol due to non-loaded section: AL_Encoder_Destroy - value=0x1ae2d8, section=SECTION11 Unable to place symbol due to non-loaded section: tuya_ipc_reconnect_wifi - value=0x1cba28, section=SECTION11 Unable to place symbol due to non-loaded section: libiconvctl - value=0x311800, section=SECTION11 Unable to place symbol due to non-loaded section: vi_dev_open - value=0xe0904, section=SECTION11 Unable to place symbol due to non-loaded section: srtp_protect_mki - value=0x286c3c, section=SECTION11 Unable to place symbol due to non-loaded section: ak_osd_set_canvas_enable - value=0xd2bac, section=SECTION11 Unable to place symbol due to non-loaded section: mt_rect_optimization - value=0x78b58, section=SECTION11 Unable to place symbol due to non-loaded section: mqc_log_notify - value=0x272fd8, section=SECTION11 Unable to place symbol due to non-loaded section: _SD_PcmBuf_login - value=0x139df8, section=SECTION11 Unable to place symbol due to non-loaded section: ls_hal_close_rsvd_part - value=0x355218, section=SECTION11 Unable to place symbol due to non-loaded section: huff_ltab3_4 - value=0x3aa354, section=SECTION14 Unable to place symbol due to non-loaded section: data_start - value=0x5089d0, section=SECTION24 Unable to place symbol due to non-loaded section: AVIMuxer_Init - value=0x10d7b0, section=SECTION11 Unable to place symbol due to non-loaded section: p_32000_mono_short - value=0x3a911c, section=SECTION14 Unable to place symbol due to non-loaded section: srtp_sha1_core - value=0x2b1940, section=SECTION11 Unable to place symbol due to non-loaded section: AVIDemuxer_GetNextBlockInfo - value=0x10c340, section=SECTION11 Unable to place symbol due to non-loaded section: _ZN8CRingBuf16RequestReadFrameEPiPj9__FRAME_E - value=0x65168, section=SECTION11 Unable to place symbol due to non-loaded section: ak_thread_get_version - value=0x122080, section=SECTION11 Unable to place symbol due to non-loaded section: MemDesc_AllocNamed - value=0x1bbb9c, section=SECTION11 Unable to place symbol due to non-loaded section: user_ai_nr_attr_cry - value=0x510854, section=SECTION24 Unable to place symbol due to non-loaded section: ls_osa_sem_create - value=0x3555cc, section=SECTION11 Unable to place symbol due to non-loaded section: quicktime_mdia_init_audio - value=0x11ddb0, section=SECTION11 Unable to place symbol due to non-loaded section: AK_ISP_get_nr1_attr - value=0xe3cf4, section=SECTION11 Unable to place symbol due to non-loaded section: AK_ISP_get_3d_nr_attr - value=0xe3d54, section=SECTION11 Unable to place symbol due to non-loaded section: AVIOutput_Finalize - value=0x10fbac, section=SECTION11 Unable to place symbol due to non-loaded section: _zbar_qr_create - value=0x2f9e9c, section=SECTION11 Unable to place symbol due to non-loaded section: ikcp_setlogmask - value=0x2409c4, section=SECTION11 Unable to place symbol due to non-loaded section: ak_md_get_fps - value=0xc1764, section=SECTION11 Unable to place symbol due to non-loaded section: _SD_Echo_GetNearJitterBufParam - value=0x12e678, section=SECTION11 Unable to place symbol due to non-loaded section: ak_vpss_close_wdr - value=0xd5610, section=SECTION11 Unable to place symbol due to non-loaded section: get_gw_ext_stat - value=0x2358bc, section=SECTION11 Unable to place symbol due to non-loaded section: ht_night_mode_get_fillled_state - value=0x88fe8, section=SECTION11 Unable to place symbol due to non-loaded section: akamrenc_cod_amr_reset - value=0x1760bc, section=SECTION11 Unable to place symbol due to non-loaded section: mrd_expand - value=0x1c3acc, section=SECTION11 Unable to place symbol due to non-loaded section: quicktime_write_stbl_soun - value=0x11e918, section=SECTION11 Unable to place symbol due to non-loaded section: akamrenc_cl_ltp_exit - value=0x176fa4, section=SECTION11 Unable to place symbol due to non-loaded section: AL_EncCore_ReadStatusRegsJpeg - value=0x1a3704, section=SECTION11 Unable to place symbol due to non-loaded section: tuya_ipc_pack_h265_rtp_pack - value=0x29824c, section=SECTION11 ... `

Here are configs I m trying to read the file

[Ancientkingg]

Does this also happen with the patched version I sent you, if you try to load that into ghidra? @vladislabv

[vladislabv]

Does this also happen with the patched version I sent you, if you try to load that into ghidra? @vladislabv

Nope, your patch is read correctly and can be fully analyzed by ghidra

[Ancientkingg]

This should be the original firmware: anyka_ipc.zip

[vladislabv]

@Ancientkingg Thank you, already decompiled by ghidra. Strange that my own anyka_ipc is somehow corrupted to ghidra

[Ancientkingg]

I managed to get rtsp working WITHOUT breaking the app:

anyka_ipc_v3_patched_test.zip

It goes without saying but before you try please rename it appropriately to anyka_ipc_rtsp.

My next steps are trying to get more functions working without having to use the app; the main thing being able to rotate the camera.

[Ancientkingg]

I managed to get PTZ control working again as well!

To get PTZ to work again please update motor.cgi in the cgi-bin folder on the SD card, using the contents of the ZIP below: motor.zip

You should be able to control the camera now if you visit the ptz page as specified in the readme. For default credentials this would mean: http://user:password@<ip>:8080/ptz.html

[Ancientkingg]

I have sort of come to a point where all of the features that I personally need are fixed, but do you have any suggestions for anything else to look into possibly?

[vladislabv]

@Ancientkingg Incredible work! I was thinking about integrating toggles as in the tuya app. The most usable would be the sleep mode I think.

Also I was asking why is there mosquitto_pub in the files we dropping on the sd card, but there is no config to establish mqtt messages delivery in a local network...

[vladislabv]

@Ancientkingg Incredible work! I was thinking about integrating toggles as in the tuya app. The most usable would be the sleep mode I think.

Also I was asking why is there mosquitto_pub in the files we dropping on the sd card, but there is no config to establish mqtt messages delivery in a local network...

I see there is a functionality putting messages (notifications) on the localhost. Do you think it is possible to integrate sending it on a dedicated local ip adress? (Like Homeassistant)