23.x.x.x firmware
Closed this issue · 29 comments
Hi
There is a new firmware 23.00.00.01. obtainable from http://upg.cloudlinks.cn/upg/23/00/npcupg_23.00.00.01.bin.
Could anyone explain how you extract DES KEY?
Usually you can get the DES key by inspecting the npc file in the JFFS partition. So you need to
- download the new firmware
- extract the JFFS partition and mount it (use this tool and adjust the signatur check to not fail the script completely - maybe an option would be helpful here to skip the signature check before extracting)
- open the
npcfile using a hex editor - search for some prefix of other DES keys (like
9c ae) - check the found results if the signature calculation works with on of the search results
I did this for the new version. So it is already supported in the version I provided in my PR. I guess you can close this issue now.
And I hope @zzerrg will merge all the new stuff soon. But looking at the other issues, there's nothing happening so far.
Thank you @ohinckel for sharing the knowledge and the for update. Happy new year!
Unfortunately it’s not working due to sig verification fails, also tried with the key ending with 00.
Oh, you're right. I thought it was working, but maybe I forgot to remove my debug stuff which indicated everything is OK. I have look into it - but for the moment all keys I tried failed.
They must've changed something in the way DES is implemented. Tried to read @zzerrg forum entries regarding asm in https://4pda.ru/forum/index.php?showtopic=681058&st=1300 without any luck
I tried to downgrade to 22....16 with through DNS poision and my own webserver however it refuses to accept anything below 23. I'll try to do the same through SD-card method I'll get back to you.
The comments in the forum doesn't get me further (seems to be discussions about the old implementations and I'm not really able to understand this language - Google translate helped a bit, but still confusing).
This all seems to be a little bit more complicated. I think decompiling the npc binary could help here, but I don't have the tools for this. Maybe @zzerrg can decompile the code into something more readable (like code in C). Because I don't have an account in the mentioned forum I can't ask him for assistance. Maybe you can ask there to decompile the program?
Unfortunely I do not have an account either, can try to obtain one however its been 4 months since last time @zzerrg was online there.
Would something (snippet) help you further? https://pastebin.com/4zqN4597
Did you decompile/disassemble the program completely? You snippet contains only one method, and there is nothing about a DES key. Do you have also the code from the other sub_XXXX()?
Thanks. Hopefully this is the new version (23.x.x.x) and not an old one. And it's really large, but the program does not only install updates so 90% of the file is not really interesting.
I'll have a look at this! Thanks so far!
Yes, I think he reverse engineered this. But I don't really know.
Did you tried to flash an old version using SD card? In my setup I can just put the firmware file (bin) into the root of the SD card with name npcupg_gk.bin . After a starting up the flash progress started. After it completes, turn it down, remove the SD card again (to avoid flashing again), and startup the device.
Hi @ohinckel I've tried the method you described, It's not accepting it according to RS232
== BEGIN LOG ==
fgStartCheckUpdatePack start!
fgStartCheckUpdatePack: dwFoundPackOption = 0
timecnt over!vLEDCtlThStop Exit!
NPC UPG END
********** finish *********
please power on again
== END LOG ==
I've gained root through RS232 and modified boot.sh to contain (Note no password is just temporary and not recommended :))
/bin/busybox telnetd
/bin/busybox passwd -d root
So now I can do some more digging.
@ohinckel - Can you try with 9C AE 6A 5A E1 FC B0 EB as key? Found it in startup binary
./gm_app_fw.py -f npcupg_23.00.00.01.bin -v
fw_ver : 23.00.00.01
jffs sz: 2362036
exec sz: 6343
csum : c193e6ad044a660f0997e1463517bee3
sig ok : True
- ./gm_app_fw.py -f npcupg_23.00.00.01.bin -u
- ./gm_app_fw.py -f npcupg_23.00.00.01.bin -m
- modifying boot.sh with /bin/busybox telnetd and /bin/busybox passwd -d root
- mkfs.jffs2 -r /mnt/fw_app/ -o npcupg_23.00.00.01.jffs2
- ./gm_app_fw.py -f npcupg_23.00.00.02.bin -p -j npcupg_23.00.00.01.jffs2 -e upg_23.00.00.01.elf -V 23.00.00.02
Pack npcupg_23.00.00.01.jffs2 + upg_23.00.00.01.elf into FW image ...
Build FW version 23.0.0.2
Calculated fw_sig: bc23a479e7cd54b81cf22cd4b323cd91
Trying to update firmware will get back. - Worked like a charm.
@ohinckel Let's hope that @zzerrg will add Pull req for 23.xx
Thank you @ohinckel for the help and support also want to give a shout out to this fantastic whitepaper
@vilasevic, yes this is the right key:
$ ./gm_app_fw.py -f npcupg_23.00.00.01.bin -v -d
fw_ver : 23.00.00.01
jffs sz: 2362036
exec sz: 6343
csum : c193e6ad044a660f0997e1463517bee3
sig ok : True
$
Must check the binary again to find the correct position. Sorry, for not finding it at the first try. But I'll update my PR to include support for this version, too.
Ah exec_sz? Let's keep this issue open until we agreed upon 100% solution.
Just updated my PR to include the new DES key. About exec_sz I think it's still the same, isnt it? At least the header in the firmware indicates 6343/18c7 bytes.
Btw. I can't find the key in the npc binary. Did you looked at another file? What do you mean by startup binary?
I connected with RS232 to the camera and I found a file in /patch/bin/ called startup - this file is not included in the update firmware file - I think this file is in full firmware file which is 8MB there is a 16M full file I cannot find it but lots of forums mentions it. I can show pictures tomorrow and which RS232 I used. I can share the file with you also full dump from mtd0-5. if you have telnet enabled just go to cd /patch/bin copy startup to /mnt/disc1 and check in your pc
Thank you very much for your information. You don't need to provide the data, I'm also able to telnet into my camera and check myself. But thanks for your offer!
Do you think we have more topics open to close this issue? The exec_sz value?
@ohinckel - I want to close this since everything is working now, I've unpacked, modified firmware, repacked and updated with the modified one and It's no issues so far. Please let me know if you agree in a final comment.
Also I want to give special thanks to Security Research Labs (Balthasar Martin and Fabian Bräunlein) for the white paper regarding Next-Gen Mirai and thier expertise.
From my point of view all issues are fixed. So feel free to close it whenever you think.
Only one thing I'm interested in, but has not really to do with this issue, is: how do you lock out all cloud things?
You can do a few things, however there is no simple way of doing it.
- You could NULL route cloud traffic
- Drop all outgoing traffic from LAN
- Patch with NOP on functions in NPC-file
I will try to fix something that works generally for everyone, If I manage to fix it as I've intended I'll get back to you.
I have a new cam with a new firmware 23.00.00.07:
# cat version.txt
23.00.00.07
P4_platform = 5987
P4_public = 5990
Release - Thu Dec 7 01:07:50 UTC 2017
#
Maybe one of you know:
- why does it have now 23.xx.xx.xx instead of 22.xx.xx.xx (like my other older cams have) - obviously it seems to be a different camera having another wifi connector (cable to the front case with IR LEDs)
- where can I get the original firmware since I'm only able to fetch an older one 23.00.00.01
@ohinckel - All my cameras that I ordered 2018 have this version, however just make a new firmware and enable telnet repack with same key and there will be difference.
Thank you all for supporting and further development of this small tool :)
@vilasevic Yes, I tried to use qemu-arm just to debug compiled code:
#!/bin/sh
ROOT=/var/lib/lxd/containers/buildroot/rootfs
qemu-system-arm -M versatilepb \
-m 64M -nographic \
-kernel output/images/zImage \
-chardev stdio,mux=on,id=char0 \
-mon chardev=char0,mode=readline,default \
-serial chardev:char0 \
-drive file=output/images/rootfs.ext2,if=scsi,format=raw \
-net nic,model=smc91c111 -net user,tftp=${ROOT}/home/dev/buildroot/foobar \
-append "root=/dev/sda console=ttyAMA0,115200" \
-drive if=sd,index=1,media=disk,format=raw,file=./sdcard-1g.bin \
$@
Hello,
I know that it's quite old but if it can help, this was my situation and how i've flashed the firmware.
My camera is a Floureon, uboot blocked (cannot flash from it). I tried several things to flash the firmware from sdcard, but it don't work. So i found a workaround.
### WARNING : if you have no other way to flash the firmware (like me), you can brick your camera if the flashing process fail, use at your own risks !! #####
Error i got when trying to update from sdcard :
== BEGIN LOG ==
fgStartCheckUpdatePack start!
fgStartCheckUpdatePack: dwFoundPackOption = 0
timecnt over!vLEDCtlThStop Exit!
You need a working serial acces to camera (i used a FT232 USB to serial adapter)
- Download the firmware. For me it was : http://sratest201905.2cu.co/upg/21/00/npcupg_21.00.01.35.bin
- ./gm_app_fw.py -f ./npcupg_21.00.01.35.bin -u (you get app_21.00.01.35.jffs and upg_21.00.01.35.elf)
- Using jefferson jffs2 extract tool (https://github.com/sviehb/jefferson) : ./jefferson app_21.00.01.35.jffs -d outdir
- Edit what you want in the filesystem. I suggest to add telnetd in dhcp.script, i've also added a custom script just in case
#!/bin/sh
# udhcpc script edited by Tim Riker <Tim@Rikers.org>
[ -z "$1" ] && echo "Error: should be called from udhcpc" && exit 1
# CUSTOM
/usr/sbin/telnetd &
/rom/custom_script.sh &
- Rebuild the image : mkfs.jffs2 -r outdir -o app_21.00.01.35_PATCHED.jffs
- Copy the image on a micro sdcard, put it in the camera slot
- Connect using serial, mount the sdcard if it's not already mounted : mount /dev/mmcblk0p1 /mnt/disc1
- Flash the firmware directly in mtd4 : # /gm/tools/flashcp /mnt/disc1/app_21.00.01.35_PATCHED.jffs /dev/mtd4 -v
- Reboot and enjoy