I bought a cheap IP Camera more than a decade ago and it had a simple http interface with a cgi-bin that would stream MJPEG (concatenated JPEGs). And it finally died and I decided to buy another one so I bought a pair of EseeCloud IP Cameras on Temu, thinking they would be just as open. They are not. But I hacked them.
Long story short, if you insert an SD card with the files debug.ini (empty) and anyka_ipc_nostrip on it, then it will execute anyka_ipc_nostrip in place of its big closed daemon. This allows you to hack it in essentially the same way as existing hacks that used a file "Factory/config.sh" for the same purpose.
I am standing on the shoulders of giants. These resources were very handy to me:
These cameras use an app called EseeCloud, which sucks. They don't expose any ports I was able to make sense of. They have an http interface that seems to support /snapshot.jpg interface, but I don't know the password or magic sauce to make it work.
The branding is indecipherable as well. Apart from the string "EseeCloud" on the installation pamphlet, they have "HOTBEATH" printed on the plastic housing. The app identifies it as "C2L-Y-A6".
I took one of them apart and found its 3-pin serial port. Oscilloscope shows 3.3V 115200bps. I used pico-uart-bridge and it worked on the first try. It shows u-boot (but can't be interrupted), but it doesn't show anything after the kernel is loaded. I later found out that the kernel is convinced it's accessing the serial port (/dev/ttySAK0) and there's even getty on it, but it doesn't actually work for unknown reasons.
Unfortunately, getting it back together is tricky and I sacrificed the altitude (tilt) motor.
The only clue I got from the serial port is that the camera chipset is called Anyka. It's a generic ipcam platform that was put together in about 2013 that all of these cameras are still using today.
I set it up with the EseeCloud app and used tcpdump to watch all of its network activity. I found a "password" sent in plaintext (a long hex string), but I haven't run into a use for it. The useful clue was that it is mostly talking to different hosts at dvr163.com. Which led me to helpen.dvr163.com! On there I found a firmware image "C2L_A_20211108_3_6_46_577013.rom". Taking that apart, I found /usr/sbin/anyka_ipc.sh, which redirects to the SD card anyka_ipc_nostrip for debugging.
Still with no serial console, it was a tedious process of constantly moving the SD card back and forth between my laptop and the camera, redirecting output of my commands to the SD card so I can see their output. I configured the wifi with wpa_supplicant / wpa_cli. I used mount --bind to replace /etc/passwd with one where I replaced the root password (using "openssl passwd -1 -salt 12345678 newpasword"). So now it's running ftpd and telnetd (from busybox) and I can access it over wifi.
I could probably use the RTSP server that Muhammed Kalkan shared, but I want an MJPEG server and I also ultimately want to do some processing on the device to minimize wifi traffic (to only send frames that show motion), and to work with my existing bespoke software. So that is a little bit of development work.
Unfortunately, even though it supports video4linux (v4l2 /dev/video0), it is all a big dumb hack. The extremely low quality of the kernel drivers and the interface to them reminds me of Raspberry Pi VCHIQ. Just absolutely braindead design from people who are not cool enough to be kernel hackers. v4l is actually awesome and provides an interface flexible enough for all of the ISP features they want to expose. They just didn't use it!
I used a decompiled IPC daemon to find out that /dev/isp_char has to be open (initializing the Image Signal Processor, aka DSP) or opening /dev/video0 will crash the kernel driver. Then I found that you can't actually read image data without initializing ISP IRQs or something?? I'm now using OpenIPC/ak3918ev200/src/apps/video/dump.c as a guide to all the magic that has to be done to get /dev/video0 to work.