LSC Indoor IP Camera Firmware v7.6.32

[BreadJS]

Hey there!

I have bought this LSC Indoor IP Camera on the 30th of August 2022 and tried this method (combined with the Merkury720P method) with no success.

I have literally tried everything that was stated in the documentation. Also switching between SD cards. I also ready some other issues but nothing seems to help. I even tried the custom QR code that somebody in the issues stated but no lucky. I think they have patched out some things in this firmware version as this one is pretty high compared to all the other versions I saw wondering on Github.

The only ports that are open are:

• 80 (DoorBird video doorbell rtspd)
• 835
• 6668
• 8554 (DoorBird video doorbell rtspd)

Port 80 and 8554 showed "version" DoorBird video doorbell rtspd in nmap. I have no idea why it is also saying that on port 80 as that should be an HTTP server.

I also get no positive response from the HTTP requests I'm doing. I tried the admin:admin but also admin:056565099. They all returned ERR_CONNECTION_REFUSED. I checked the SD card but no new folders or files have been created.

It's a cheap camera with a pretty decent lens on it and would love to see this work in my setup. I do NOT want to build one my own (for cheap) or buy an expensive set.

If you have any idea what I can do, let me know! :)

[guino]

@OfficialDevvCat if the Merkury1080, Merkury720 and BazzDoorBell process didn't work with different SD cards then it may have a different address or not be linux OS. Usually ppsFactoryTool.txt allows the HTTP responses to work, but like you said, it is possible they closed some things or changed the user/password.

Until someone with the right tools can open it up and read the firmware (or connect to UART) we won't know -- I have the tools but no device, so I have no way of helping right now.

[BreadJS]

@OfficialDevvCat if the Merkury1080, Merkury720 and BazzDoorBell process didn't work with different SD cards then it may have a different address or not be linux OS. Usually ppsFactoryTool.txt allows the HTTP responses to work, but like you said, it is possible they closed some things or changed the user/password.

Until someone with the right tools can open it up and read the firmware (or connect to UART) we won't know -- I have the tools but no device, so I have no way of helping right now.

100% true! What do you exactly need to use the uart port? I have soldering skills, yet I have no idea what I need. Would a Raspberry Pi 4 work? Because I have that laying around. Let me know. Maybe you want to discuss this on discord? DevvCat#0880

[guino]

@OfficialDevvCat if you're willing to open your device and solder wires to it I can help trying to figure out if we can root it.

The first step would be to open your device and take some good pictures of the board so we can identify the UART pins.

The second step will be to solder some wires to the UART pins and connect GND, RX and TX to the GND, RX, TX of the pi board (GPIO15 and GPIO14 pins on the header). You may need to swap the RX/TX around as we won't know which is RX/TX by looking at the board.

Once you have it all connected you should see some messages on the pi terminal when you power on the device -- ideally you should be able to interrupt the boot of the device by pressing a key when the first messages show up and it will either give you a bootloader prompt or ask for a password. Whatever messages show up may help in figuring out if we can even do anything.

[BreadJS]

@OfficialDevvCat if you're willing to open your device and solder wires to it I can help trying to figure out if we can root it.

The first step would be to open your device and take some good pictures of the board so we can identify the UART pins.

The second step will be to solder some wires to the UART pins and connect GND, RX and TX to the GND, RX, TX of the pi board (GPIO15 and GPIO14 pins on the header). You may need to swap the RX/TX around as we won't know which is RX/TX by looking at the board.

Once you have it all connected you should see some messages on the pi terminal when you power on the device -- ideally you should be able to interrupt the boot of the device by pressing a key when the first messages show up and it will either give you a bootloader prompt or ask for a password. Whatever messages show up may help in figuring out if we can even do anything.

Okay! I'm 100% be willing to open up the device but currently I'm in the middle of a move so that have to wait until I've got all my stuff! I will let you know as soon as possible when I got everything and ready to the hacking! :)

[aleksandersmolowik]

I have the same issue and the same camera.

[guino]

Flash Chip is in marked in RED
UART pins are marked in BLUE

Either we need a copy of the firmware (using hardware programmer on the flash chip) OR we need someone to connect to the UART pins (TTL 3V) to capture an output log and/or see if there's any access to the bootloader.

[BreadJS]

Flash Chip is in marked in RED UART pins are marked in BLUE

Either we need a copy of the firmware (using hardware programmer on the flash chip) OR we need someone to connect to the UART pins (TTL 3V) to capture an output log and/or see if there's any access to the bootloader.

I ordered a SPI flasher and it will arrive in a few hours. When it is here I can dump the firmware and upload it so you guys can take a look at it! Give me a few hours and I will get back to you guys.

To be specific, this is the one I ordered: https://www.amazon.nl/gp/product/B08TVNPTQK/

[guino]

@OfficialDevvCat I have that flash programmer and you need to be aware of 2 things:
1-It says it is compatible with 3.3V chips but it outputs 5V on some pins -- you should check it before you fry your chip/board. There's a 'mod' you can do on it to make it output 3.3V on all pins (I did the mod on mine and it works correctly)
2-You most likely will need to remove the chip from the board (OR at least disconnect PIN 6 in my experience) before you can read/write the flash. If you don't have a heat gun it may be easier to cut the pin 6 (with needle cut pliers) and solder it back afterward than trying to remove the whole chip (trying to disconnect pin 6 with a soldering iron will likely damage the board) -- learned the hard way.

IF you're going to do any cut/solder work: I recommend practicing on any old/broken board laying around first

[BreadJS]

@OfficialDevvCat I have that flash programmer and you need to be aware of 2 things:
1-It says it is compatible with 3.3V chips but it outputs 5V on some pins -- you should check it before you fry your chip/board. There's a 'mod' you can do on it to make it output 3.3V on all pins (I did the mod on mine and it works correctly)
2-You most likely will need to remove the chip from the board (OR at least disconnect PIN 6 in my experience) before you can read/write the flash. If you don't have a heat gun it may be easier to cut the pin 6 (with needle cut pliers) and solder it back afterward than trying to remove the whole chip (trying to disconnect pin 6 with a soldering iron will likely damage the board) -- learned the hard way.

IF you're going to do any cut/solder work: I recommend practicing on any old/broken board laying around first

Okay so wait.
The camera needs to be turned on right? And then the clip needs to be attached before i turn it on. (If it outputs the same voltage) and then i need them both turned on and read the data? Or does rhe camera needs to be off and then attach the clip and read the data? Cause if the clip outputs 5v. I can make sure the clip does not output power and then connect the clip and turn on the camera to extract the data. Or is that not going to work? I do not have a heatgun or soldering station on hand.

[guino]

@OfficialDevvCat a flash programmer will read (and later write - if desired) the built in firmware on the device -- to be clear: it won't do anything with UART. For reading/writing the flash you don't turn on the device at all, you just plug the flash programmer on the chip and read (or write) its contents (like a USB drive). The issue is that (from experience) connecting the flash programmer to the chip without removing it from the board doesn't work (fails to read/write). As long as you verify the output is 3.3V (on all pins like VCC, RX, TX) then it should be safe to try and read the flash while connected to the board (but from experience it is likely going to fail, but who knows board design changes). If you plug the programmer to the chip while on board and you output 5V to any pin you may fry the device (fair warning).

The only type of connection we do with the board/device powered ON is when using the UART/TTL adapter where we connect it then power on the device to capture the boot output log. UART connections require a USB/TTL UART/SERIAL adapter (3.3V), which is a different thing than the flash programmer.

[BreadJS]

@OfficialDevvCat a flash programmer will read (and later write - if desired) the built in firmware on the device -- to be clear: it won't do anything with UART. For reading/writing the flash you don't turn on the device at all, you just plug the flash programmer on the chip and read (or write) its contents (like a USB drive). The issue is that (from experience) connecting the flash programmer to the chip without removing it from the board doesn't work (fails to read/write). As long as you verify the output is 3.3V (on all pins like VCC, RX, TX) then it should be safe to try and read the flash while connected to the board (but from experience it is likely going to fail, but who knows board design changes). If you plug the programmer to the chip while on board and you output 5V to any pin you may fry the device (fair warning).

The only type of connection we do with the board/device powered ON is when using the UART/TTL adapter where we connect it then power on the device to capture the boot output log. UART connections require a USB/TTL UART/SERIAL adapter (3.3V), which is a different thing than the flash programmer.

Okay that is clear. Could you take a look at the picture and tell me what the best solution could be? It has a jumper for maybe possible ttls fu functinality?

https://imgur.com/a/I0ZPCF0

[guino]

@OfficialDevvCat the chip should connect on the ‘25’ section, but like I said: this programmer has a 3.3V/5V jumper but when you set it to 3.3V it still outputs 5V on some pins ( RX/TX pins I think ). If you connect it without the mod to fix the voltage you may damage the board/chip (you have been warned).

[BreadJS]

Okay, I will find online if there a different way to do that. What about the TTL functionality? Does that also output 5v? Or is it just a reading pin?

[guino]

@OfficialDevvCat that flash programmer only has TTL functionality - in 3.3V or 5V selected by jumper switch, but this is only for flash chip read/write. The UART pins require a UART TTL (3.3V) adapter which is mostly available as a USB adapter. There’s no way (that I know) to use a flash programmer on the UART TTL pins, and there’s no way (that I know) to use the he UART TTL adapter on the flash chip.

[BreadJS]

@OfficialDevvCat that flash programmer only has TTL functionality - in 3.3V or 5V selected by jumper switch, but this is only for flash chip read/write. The UART pins require a UART TTL (3.3V) adapter which is mostly available as a USB adapter. There’s no way (that I know) to use a flash programmer on the UART TTL pins, and there’s no way (that I know) to use the he UART TTL adapter on the flash chip.

I just check the datasheet of a old 25xx chip from a dead GPU and it was a 3.6 max volt chip. And it i got to read the chip without issues and even got to write to it. I also looked up and this is an improved revision of the board with the 3.3v fix. Should I now extract the data from the camera?

[guino]

@OfficialDevvCat sounds good if you say it’s a fixed version you can try - again, from my experience it may not work while the chip is soldered on the board. I would avoid keeping the flash programmer hooked up for a long period just in case the voltage is wrong, so hook it up, try to read, remove it if fails, wait a bit hook up, try reading again, etc

[BreadJS]

@guino I just dumped the chip, I did that exactly. Read, verified and disconnected. You can download the dumped bin file from here https://www.mediafire.com/file/31ms1k4kgqxxlh6/Smart_Indoor_IP_Camera.bin/file
Let me know what I can do or what you're planning to do.

[guino]

@OfficialDevvCat well, assuming your camera still works normally, I would try this first:

Follow the steps from:
https://github.com/guino/Merkury1080P#conclusion USING THE ATTACHED 3 files: 7632.zip -- that is, instead of what's posted on the link (I changed the address changed to A0008000 on env and ppsMmcTool.txt files). Assuming the internals didn't change a lot this may allow you to root device.

Binwalk didn't give me a lot of information to work with, so let's hope this works.

[BreadJS]

@guino Just one more question. Do I have to flash the chip afterwards to make it work?? Cause the issue is that the SPI Flasher does not work anymore for some reason?! The Red power light is on and so is the Yellow RUN led. And it is not found by windows anymore?! I don't hear a USB Connected sound. Very very strange. So I'm going to return it tomorrow and ask for a new one which will take a few days... Unless you know what I can do about it?

[guino]

@OfficialDevvCat If you tried A0008000 and it didn't work I'll have to try and dig out more from this firmware file.

Is the camera still working ? (boots up, etc) ? if not you may have damaged it somehow. It may just need a power cycle of your machine to reset the USB bus (if it used too much power).

[BreadJS]

@OfficialDevvCat If you tried A0008000 and it didn't work I'll have to try and dig out more from this firmware file.

Is the camera still working ? (boots up, etc) ? if not you may have damaged it somehow. It may just need a power cycle of your machine to reset the USB bus (if it used too much power).

Camera works perfectly fine! I can try rebooting my PC but I don't think it's really going to work as it was plugged in a powered hub. Tried a different pc and used my powerbank. Yellow light stays solid and not connected.

[BreadJS]

But again, Do I need to flash stuff again onto the chip? Cause I can't read anywhere what to do after the edit. I assume it has to

[guino]

@OfficialDevvCat the 'Read' process doesn't change anything in the chip, so to work 'normally' you won't have to flash anything back. If I can unpack the firmware we may be able to find something to change to root the device (I haven't been able to do it yet) -- in that case you would need to be able to write the changes with the programmer (meaning it would need to work again).

[BreadJS]

I tried to find some variables from the link you sent me but it can't even find the "Loadable segment". Maybe you could take a look at it if you've got the time for it? Would appreciate it!

[BreadJS]

@guino Let me know if I can do anything as I'm a programmer and know my way around some of this stuff! Would be very cool to get this thing streaming a signal outside the app. :) Have a great weekend in advance and lets hope for some good results on this thing

[guino]

@OfficialDevvCat I will try to see if I can get anything out of it - may need to try a different tool.

[guino]

@OfficialDevvCat I downloaded a different tool and then I noticed there's an issue with your flash file -- it's only 2Mb when it should be at least 8Mb (some devices have 16Mb) -- this is likely the reason why I could not extract anything out of it. This may have been something like selecting the wrong size of chip when you did the 'read' or perhaps an issue identifying the chip size (or even just an upload issue), Do you happen to have the /proc/cmdline for this device ? thay may help me extract the bootloader from the section you provided (so I can try to double check the load address).

[BreadJS]

@OfficialDevvCat I downloaded a different tool and then I noticed there's an issue with your flash file -- it's only 2Mb when it should be at least 8Mb (some devices have 16Mb) -- this is likely the reason why I could not extract anything out of it. This may have been something like selecting the wrong size of chip when you did the 'read' or perhaps an issue identifying the chip size (or even just an upload issue), Do you happen to have the /proc/cmdline for this device ? thay may help me extract the bootloader from the section you provided (so I can try to double check the load address).

I did not have any success with that sadly. The http server is sadly disabled to get any kind of useful info from it.

U have to wait until sunday until I got my new reader to try it out once again.

[BreadJS]

@guino I just received my new SPI flasher. I will dump the whole chip (8MB) in an hour or so. I will lookup the chip model number and see what settings I need.

[BreadJS]

@guino I just noticed the TX/RX rail is on 4.5V. I will have to wait until Wednesday till I got my soldering station.

[guino]

@keerttttt the reason it only works with the SD card is because the startup scripts (written by the manufacturer) basically copies that file when the device boots (from the SD card).

Technically it is possible to NOT run dgiot (at all) and instead run a custom written application to read the video+audio data and create the RTSP server for it. With the OS sources and right SDK this would not be so hard but without those it would take a long time to write anything since it has to match the right hardware and specific sensors. Trying to write something to run along with dgiot (in parallel) would have different challenges such as memory/cpu limitations as well as trying to synchronizing reading the video/audio buffers between the two applications.

[BreadJS]

Okay quick update on how my experience went for the last couple of months. It was good at first! Audio with rtsp stream in AgentDVR with Scrypted. And video trough local video rtsp stream. But later on there became a HUGE delay on the audio. I have no clue why this happened. Still trying to figure it out. Having a huge delay on the audio is not something what I want while I'm recording my camera's. I'm going for a new approach which will be creating an application that runs on the camera to stream the audio. I will be using ChatGPT as I have 0 experience in C/CPP or doing any of this on such hardware. I will let you guys know if I succeed or fail.

[BreadJS]

@guino I have a question. I was able to solder back the flash chip (very sketchy) on my LSC Rotateable camera and I flashed the wrong firmware on it. I do get lots of data (see file) Boot.txt. I also cannot find the firmware that I backed up from that chip... I also cannot remove the chip cause there is a 90% chance I will break it again and maybe not even able to get it working again.

I would mean the world to me if you could help me out with this one

Update:
When I put a old flash on the sd card I will get this result, maybe something you could use?

reading ht_recover_fw.conf
8388608 bytes read

magic#2a4c4232
type#1145192783
uboot size#1
kernel size#1
rootfs size#1
usrfs size#384
flash size#2857719210
version#4294967295.0.0.0
Image bad MAGIC
fw header not valid
KERNEL: size:0x00180000, offset:0x00040000

SF: 1572864 bytes @ 0x40000 Read: OK
## Booting kernel from Legacy Image at 80008000 ...
   Image Name:   Linux-4.4.192V2.1
   Image Type:   ARM Linux Kernel Image (uncompressed)
   Data Size:    1569256 Bytes = 1.5 MiB
   Load Address: 80008000
   Entry Point:  80008040
   Verifying Checksum ... OK
   XIP Kernel Image ... OK
   kernel loaded at 0x80008000, end = 0x801871e8
using: FDT

Starting kernel ...

[guino]

@BreadJS your boot log indicates the flash firmware is either corrupt or the boot settings are incorrect, currently you have this:
console=ttySAK0,115200n8 root=/dev/mtdblock5 rootfstype=squashfs init=/sbin/init mtdparts=spi0.0:200K@0x0(UBOOT),4K@0x32000(ENV),4K@0x33000(ENVBK),48K@0x34000(DTB),1536K@0x40000(KERNEL),1024K@0x1C0000(ROOTFS),256K@0x2C0000(CONFIG),5120K@0x300000(APP) mem=64M memsize=64M

This is what I have:
console=ttySAK0,115200n8 root=/dev/mtdblock5 rootfstype=squashfs init=/sbin/init mtdparts=spi0.0:200K@0x0(UBOOT),4K@0x32000(ENV),4K@0x33000(ENVBK),48K@0x34000(DTB),1536K@0x40000(KERNEL),1024K@0x1C0000(ROOTFS),256K@0x2C0000(CONFIG),5120K@0x300000(APP) mem=64M memsize=64M

Since it looks exactly the same, the only conclusion is that your rootfs is corrupted.

There's a publicly available rootfs for this device as posted here and usually just saving the .bin file to the SD card and booting it up causes the firmware to automatically update from the file -- problem is: this requires the device to be operational (yours isn't). I haven't taken the device apart myself to see if you can get into o the bootloader from the serial console, but if you're able to pause the boot and go into bootloader prompt you may be able to flash it from there (manually), otherwise you'd have to re-flash the chip with a programmer (which you said may damage the device permanently).

On devices that have an interactive bootloader you can usually just press a key during the boot (before kernel loads) and it will either display the boot loader prompt or ask for a password -- if you can get either of these send me an email and I can give you some pointers.

On reflashing using a programmer, if it's any easier to just disconnect pin 6 (CLK) you may be able to use the hardware programmer without removing the chip completely from the board (hopefully without causing permanent damage).

Your boot loader and kernel seem to be ok, it's just the rootfs that seems to be corrupted, so if you can just get that section flashed you should be ok at least to completely boot the device and use if offline. For using it with the Tuya cloud your data partition with cloud certificates would have to be ok -- getting it from another device would basically mean the two devices would never be allowed to be online at the same time, so it's not something that can be shared.

[guino]

@BreadJS one additional note: The update .bin file is actually a .tar file with 1024 bytes added to the end with a few pieces of information -- so I recommend using binwalk to extract the rootfs from it as you can't just copy the file into the flash as-is.

[BreadJS]

@guino Thank you very much for replying. Is there maybe a way to flash with the sd card? On boot (beginning) you can see this

mmc/sd share pin!
mmc_start_init: init OK!
cdh:sd card, mmc->capacity_user:0x1e0000000 blocks!
cdh:mmc->capacity:0x1e0000000 !
cdh:test_part_dos read ok!
cdh:test_part_dos DOS_PART_MAGIC_OFFSET ok!
cdh:test_part_dos DOS_MBR ok!
reading ht_recover_fw.conf
** Unable to read file ht_recover_fw.conf **
ht_recover_fw.conf not found
KERNEL: size:0x00180000, offset:0x00040000

I tried copying that file and replace the name with ht_recovery_fw.conf and then I got this ouput:

mmc/sd share pin!
mmc_start_init: init OK!
cdh:sd card, mmc->capacity_user:0x1e0000000 blocks!
cdh:mmc->capacity:0x1e0000000 !
cdh:test_part_dos read ok!
cdh:test_part_dos DOS_PART_MAGIC_OFFSET ok!
cdh:test_part_dos DOS_MBR ok!
reading ht_recover_fw.conf
4363264 bytes read

magic#2e727375
type#1752396147
uboot size#52
kernel size#0
rootfs size#0
usrfs size#0
flash size#0
version#0.0.0.0
Image bad MAGIC
fw header not valid
KERNEL: size:0x00180000, offset:0x00040000

SF: 1572864 bytes @ 0x40000 Read: OK

And then it reboots: LOG HERE: Maybe it is different??
boot2.txt

[BreadJS]

I also want to let you know that this camera has a different CPU compared to the cpu tried to hack in this official topic. i also tried CTRL+C and pressing any key while booting, no results.... I will send you a picture of how terrible the soldering job is. My email is [email protected] in case you want to contact me about more info or something! :)

[BreadJS]

[guino]

@BreadJS I have not reviewed the bootloader code in that camera. Likely it is looking parameters inside the ht_recovery_fw.conf file about a possible firmware update file -- the question is figuring out the format it is expecting. It could be as simple as just being the filename in the SD card that has the firmware update (the one I posted in the link) or it could require specific data like update=filename.bin, etc. It could even be as simple as just leaving the original .bin file in the SD card with an empty ht_recovery_fw.conf file just to 'signal' that you want it to do a firmware update. It takes a fair amount of time to review the bootloader code in ghidra because it's basically a guessing game for the load address.

On a quick string search it may be looking for a parameter: ht_fw_version=0x%02u%02u%02u%02u to compare versions so it decides to update or not. It may also be looking for the file named 'flash.bin' -- these are all guesses. There are probably many checks in place so I doubt it will do anything unless all the parameters are correct (and you should be able to check on the serial output).

[BreadJS]

I asked chat GPT and this is what I got. Possibly a solution. But it is asking for a boot.bin file and a firmware.bin file? or am I wrong here?

[guino]

@BreadJS I don't have any chip documentation from hisilicon, but seems like ChatGPT may have scanned some of it already and knows some details about it. You could probably try asking more questions like 'how to calculate the magic' number on the file and how is the format of firmware.bin. It sounds like you should be able to restore the rootfs using the link to the bin file I sent earlier along with the 'correc't magic/version values (assuming you can skip the boot size/file and not mess with it). Chances are it will only work if you get it right as it will probably do a lot of checks before trying to flash anything.

[BreadJS]

I cannot get it to work at all and it is driving me crazy... I'm tempted to buy another camera and returning this broken one in the newly bought box.

[guino]

@BreadJS there's hardly any way they'd be able to tell it was your fault that the device isn't working (unless you physically modified it) -- I have in fact had devices go bad without doing any modifications to them. If it's right/wrong is a different story, but these mass produced devices are usually priced knowing that a % will fail and have to be replaced for free, so chances are that device will just be tossed into the garbage after a return.

[BreadJS]

Yeah I think so too! So thank you at least and you've made me learn a lot of information about these cameras and infrastructures! lets hope that getting RTSP working on the next camera will be more easy now that there is more information available!

[mehmetahsen]

@mehmetahsen we played a little with the station settings initially too, but these only work if the wifi is in 'station' mode which is not default when we were trying to use some of the other settings/files.

I'm sure there's a way to flash the device using their tools (when I tried it without their tools I corrupted my flash). On the outdoor/rotating camera all it takes is copying a .bin file to the root of the SD card and booting it up (the .bin was provided by them but I'm sure it can be customized). It's just a matter of spending time to define the method/file structure, etc.

Due to the lack of audio in the RTSP code of this device, it is not really high in my priority list. The WebRTC<->RTSP conversion is what would be more interesting for this device since it requires no hacking or SD card to work (and has audio). I do agree that flashing something like OpenIPC would be perfect for it (if supported).

Thanks for sharing the full product.cof file format -- I assume some people may want to use some of the settings in there.

Do you have that .bin file?

[guino]

@mehmetahsen I have no 'update' firmware bin file for this device, but I do have the modified flash dump I tried to flash (and corrupted my firmware).

[mehmetahsen]

Is that the one you tried over telnet?
I think we could find a way to boot the device from sdcard, likely there is a way from uboot. It does look for a linux.bin, and that would allow us to iterate fast without the fear of bricking, alas uboot sectors are fine. I'm thinking of checking the android app, maybe we could get the firmware update by tricking it to think camera is running an older version.

[guino]

@mehmetahsen I think someone tried to get access to u-boot without success on this device, so you'd have to flash it just to get some sort of bootloader control.

I have been able to get the firmware update download link from some devices by adjusting the version of the firmware in the main application of the device (ppsapp) -- since this device can be rooted (https://github.com/guino/LSC1080P) you could try to do the same in the dgiot application -- I personally have never tried it. You would most definitely have to be monitoring the application log to have any chance of seeing the link.

There's probably a way to 'simulate' the communication with the tuya servers (using secret keys, etc) and get a download link but those approaches take way too much time and don't always pan out.

[BreadJS]

@guino I swapped the 360 rotating camera and have a NEW WORKING one. all though the only port open is 6668 and no 80 or rtsp port. What should I do about this? Do I have to dump the firmware once again? Cause I REALLY DO NOT WANT TO DO THAT AGAIN LOL

[mehmetahsen]

@guino I swapped the 360 rotating camera and have a NEW WORKING one. all though the only port open is 6668 and no 80 or rtsp port. What should I do about this? Do I have to dump the firmware once again? Cause I REALLY DO NOT WANT TO DO THAT AGAIN LOL

You can dump /dev/mtdblock* to sdcard via telnet using dd. It's soft, safe and you get the images already partitioned!
I found the possible magic for the firmware bin, it is 0x55AA55AA. HW platform identifier is FUHAN8626

[guino]

@BreadJS for the rotating camera you just have to follow https://github.com/guino/LSCOutdoor1080P there is no risk as there’s no firmware changes required to root it.

[BreadJS]

@guino And this works on firmware 3.10.56? Cause so far telnet is notr working
Even tried the product.cof file. Is there a way to downgrade the camera? (rotating)

[guino]

@BreadJS all cameras I have seen with 3.x firmware do NOT run linux so there’s nothing we can do with then). I thought you got a rotating camera as posted in that link (2.10.x firmware).

[BreadJS]

@BreadJS all cameras I have seen with 3.x firmware do NOT run linux so there’s nothing we can do with then). I thought you got a rotating camera as posted in that link (2.10.x firmware).

That was the old camera. I bought a new one and returned the old one. I could open up the new one to see the board and see the tx data. And my normal cameras are running 7.6.32 (the one discussed here).

[BreadJS]

@guino ^^^

[guino]

@BreadJS someone just confirmed that 3.10.57 worked with option 3 (just running 2.10.36 ppsapp without modifying the flash), I would think it’s worth a try it on your 3.10.56 firmware.

[ThomasRi333]

There is no need for flashing this device (V7 firmware), just put all the files (your 7632 files, the modified ppsFactory and busybox in the root of the SD-Card ... rtsp://ip:8554/main works like a charm !
THANKS A LOT!

[BreadJS]

There is no need for flashing this device (V7 firmware), just put all the files (your 7632 files, the modified ppsFactory and busybox in the root of the SD-Card ... rtsp://ip:8554/main works like a charm !
THANKS A LOT!

What files are you talking about? And quick question. Does your audio work on the RTSP stream?

[ThomasRi333]

ppsFactoryTool.txt
7632.zip
and busybox

[ThomasRi333]

Its without audio, but i dont need it ...