Uncompressed, corrupted .bin exported from Camera?
JayGoldberg opened this issue · 38 comments
Hi there! Thanks for your work on this. I've got a 2MP PTZ Dome with this "ipcam.xin" firmware
Device Type: C6F0SgZ0N0PhL2
Software Version: V18.1.31.11.18-20210421
Webware Version: V3.0.7.1
Stripping the first 512 bytes gives me an uncompressed .tar that extracts with errors:
$ tar -xif backup.tar
tar: Skipping to next header
tar: Skipping to next header
tar: Skipping to next header
tar: Skipping to next header
tar: Skipping to next header
tar: Exiting with failure status due to previous errors
Though the extracted files in mnt/ look fine.
I've tried just amending unpack.sh and build.sh to remove -z options, to generate a new_config.bin but get 400 Bad request on restore to the camera--clearly this doesn't work. The new packed config is within 1KB size of the original, so I definitely think there is no compression involved here.
So I tried to instead inject commands into wifi.html SSID field. However, as you discovered, there is escaping done before writing to wifi.conf, and it's not done in the JS of the UI unfortunately. The result is SSID"|/usr/sbin/telnetd -l /bin/sh -p 24" --> WifiSsid="SSID\"|/usr/sbin/telnetd -l /bin/sh -p 24\"". The chars I've found that are not escaped are (, ), |, /, . !, ~, [, ], {, }. It's possible you could source a file from the SD card using . but you are trapped between the quotes. Open to ideas on this.
I would continue to try and patch your code to work on this uncompressed file, but the .tar extract errors make me think there's something else going on here.
As an aside, is it possible to get a recursive directory listing (sanitized if necessary) for the whole / of your camera? Can't find that on the Internet so far.
I am traveling until sep 6th but I can get you a full copy of my / (without any auth keys) when I get back home. I also replied your email.
Thanks, did a reset and took a clean backup
config_backup.zip
@JayGoldberg it looks like you are on the right track to hack the camera but since your backup is not 'gzip' compressed all you really need to do is locate the tenlet setting in the tar file and modify it from 0 to 1 without having to 'rebuild' the file. That said I am pretty sure you'll need to rebuild the md5sum to match the change (or the web interface will continue to refuse it) and here's where it gets complicated: the md5sum on your backup doesn't seem to be calculated the same way as mine was (payload + "IPCAM") so we really need to figure out how to get to the original md5sum (from the data available) so that we can make the change and update the md5sum in the backup file. This is kind of a guessing game unless we get a hold of a firmware dump or a firmware update which we could review to determine exactly how it checks it.
Attached is a full listing of my device except for the SD card mount -- I can provide actual files if you like but it looks like your device is somewhat different than mine (as in the backup format for example).
list.zip
Thanks for this! Indeed, changing tenable to 1 in the backup and attempting to restore gives Error 400: Bad Request. Even if it did work, I wouldn't know the root password, just as was encountered in your writeup.
I've instead tried to find other places for command injection through the web UI by getting my hands on whatever firmware I can find. The most promising one was Hi16EV200HX_V20.1.23.5.3-20190929(2M.8M).pkg which I think was from https://sv3c.com/fireware/, as these are referred to as the HX series and also in this firmware, you see it in the exported backup.
There are candidates like:
th3ddns.sh (though this appears to be in /mnt/mtd/ipc/ in this firmware vs /var/run/wpa_supplicant in your file list (I think you edited the file incorrectly at line 52204)
if [ $enable -eq 1 ]
then
/mnt/mtd/ipc/ddns_update $host $usernm $passwd $delay $srvtype $path &
fi
However, trying to inject the ping command into username field in the web UI for th3ddns causes the backup to show URL encoded chars (and inspection shows the POST form to be submitted as application/x-www-form-urlencoded). I don't know how to get around this.
[ddnscfg]
th3enable = "1 "
th3srvtype = "0 "
th3username = "%22%60ping+-c4+192.168.16.115%60%22"
th3password = "mypassword "
th3host = "mydomain.dyndns.org"
th3interval = "180 "
@JayGoldberg the listing on line 52204 is in fact from /mnt/mtd/ipc on my camera -- I didn't edit the list but I did a few 'ls' commands separately (under /mnt) so I could exclude the extensive listing of video recordings from my 'sd' mount.
It looks like whatever code they wrote for reading the th3username does not 'url-decode' the data as they probably don't accept special characters on that field. You may have better luck on the 'th3password' field if you haven't tried it yet (they may need to accept some special characters in that field so they may have added url-decoding) -- it's worth a shot.
Thanks for your help on this! Using the password field didn't seem to work, but I'm still testing. It occurs to me that everything is stored as URL-encoded to both not break the call of ddns_update and because the DynDNS API etc are POST-based and need that encoding anyway?
On my backup file, I noticed that in my case there is 1024 bits of gibberish inserted regularly (every 16kb) into the backup starting at 0x600. 0x4600 0x8600 0xC600 0x10600 and 0x14600 (before end of file). That is the "corruption" referred to in the Issue title. Each 1k block is different. I'll carve them out and try identifying the data.
Also, the a version of the uploaded restore file minus the 512b header and gibberish is stored by the camera at http://ipcam/log/config_restore.bin. I downloaded this file, and md5summed it, and put that sig back in the restore file and tried re-uploading, still no dice.
@JayGoldberg You should try building the md5sum from the tar file without the 'corruption' to see if it matches the md5 in the original config_backup.bin header. I had a quick try but it didn't work. My best guess is that this corruption is really just some garbage data left in a buffer and not anything meaningful for the tar file. I highly doubt the backup will ever restore without the correct md5sum in the header. Other than that we'd have to find an exploit the main application (assuming yours and mine are close enough) or go the programmer/UART route.
Here's the main application on mine if you want to do some digging with ghidra etc:
ipc_server.zip
Unfortunately, I was not able to match the md5 between the exported config (2cf37b34ea989deb816999d48c70dfb), and the http://ipcam/log/config_restore.bin file. I exported config_backup.bin and changed tenable to 1 in a hex editor then restored (expecting it to fail, but having http://ipcam/log/config_restore.bin created. Downloaded http://ipcam/log/config_restore.bin and changed tenable back to 0 and got md5sum 11cd6d6d7c0823c7498f520a925f51da.
ghidra is a bit beyond my expertise, so I'll hope for an open TTY, or other opportunities for injection that I thought of:
for binary in $(file * |grep ELF| cut -d':' -f1); do echo BINARY FILE: $binary; strings $binary|grep /sd/; done
for script in $(file * |grep shell| cut -d':' -f1); do echo SCRIPT FILE: $script; grep sd $script; done
for script in $(file * |grep shell|cut -d':' -f1); do echo SCRIPT FILE: $script; grep 'if' $script| grep '\$'|grep -v '\['; done # if statements without [ and var
for script in $(file * |grep shell| cut -d':' -f1); do echo SCRIPT FILE: $script; strings $script|grep [=\`*\$]; done # comparisons with var
for script in $(file * |grep shell| cut -d':' -f1); do echo SCRIPT FILE: $script; strings $script|grep -i key; done
for script in $(file * |grep shell| cut -d':' -f1); do echo SCRIPT FILE: $script; grep WIFIPATH; done
for script in $(file * |grep shell|cut -d':' -f1); do echo SCRIPT FILE: $script; grep -i \` ./${script} |grep '\$'; done # executed statements with var
for script in $(file * |grep shell|cut -d':' -f1); do echo SCRIPT FILE: $script; grep '\[' ./${script}|grep '\$'; done # # 'test' statements with var
for script in $(file * |grep shell|cut -d':' -f1); do echo SCRIPT FILE: $script; grep '\. ' ./${script}; done # sourced files
I'll get you a zip with the actual files so you can go thru them -- the 'file' command doesn't existi the device.
I have a set of files from a Hi16EV200HX_V20.1.23.5.3 firmware that I've already been running these commands on my own machine, so no .zip needed, though having more data would be nice :)
And to clarify I changed config_restore.bin tenable to 0 (not 1, that's what it was :) ) and got md5sum 11cd6d6d7c0823c7498f520a925f51da.
@JayGoldberg I assume you tried placing 11cd6d6d7c0823c7498f520a925f51da in the config_backup.bin and restoring (and I assume it failed) ?
without being able to inject a command with the backup, I would recommend going the UART/programmer route (opening the device, etc). I don't know if you have tools/familiarity for that -- I do but I don't have the device itself to work on.
Have you by any chance tried reaching out to the manufacturer to ask for a possible 'firmware update' ? sometimes these are very easy to modify and upload to the device (I'm sure they'll have checks but maybe easier to figure out).
EDIT: it is also possible that a firmware update may get you to a tar.gz version (like mine) for which the process is already defined/working. I found a similar brand/camera online where someone used the exact process from my camera and it worked.
Yes that's correct, placed 11cd6d6d7c0823c7498f520a925f51da back into my "bad" restore file, basically was letting the camera do the correct parsing of the known bad config to get a usable config to correctly compute an md5 to re-insert into the bad config making it good.
I do indeed have some experience with serial/UART I believe ESP8266 as a serial-to-WiFi bridge and I have a few Raspberry Pi in case that doesn't work.
What's the Device Type, Software Version, and Webware Version of yours?
@JayGoldberg I would expect the UART to be the 4 holes on the right edge of the board (pictured). I would expect your flash chip to be on the opposite side of the board.
Here's the info on my device:
Dev type: C6F0SnZ0N0PcL2
Soft Ver: V20.1.18.11.1-20200322
Webware ver: V3.0.7.0
In that photo the serial is 3.3v 115200 8,N,1 from bottom (near the two-pin white/green connector) to top 1-RX 2-GND 3-TX 4-untested.
Unfortunately there is a U-Boot password
U-Boot SPL 2013.07 (Mar 17 2021 - 19:40:03)
Timer init
CLK stop
PLL init
pll_init:399
pll_cfg.pdiv = 10, pll_cfg.h2div = 5, pll_cfg.h0div = 5, pll_cfg.cdiv = 1, pll_cfg.l2div = 2
fbdiv = 36 , refdiv = 1 , fdivq = 2 ,pllod = 1 range = 3
cppcr is 02300860
CPM_CPAPCR 0470484d
fbdiv = 50 , refdiv = 1 , fdivq = 2 ,pllod = 1 range = 3
cppcr is 03100860
CPM_CPMPCR 0950882d
fbdiv = 50 , refdiv = 1 , fdivq = 2 ,pllod = 1 range = 3
cppcr is 03100860
CPM_CPVPCR 0310086d
cppcr 0x9a7b5510
apll_freq 864000000
mpll_freq 1200000000
vpll_freq = 1200000000
ddr sel mpll, cpu sel apll
ddrfreq 400000000
cclk 864000000
l2clk 432000000
h0clk 240000000
h2clk 240000000
pclk 120000000
CLK init
SDRAM init
sdram init start
ddr_inno_phy_init ..!
phy reg = 0x00000007, CL = 0x00000007
ddr_inno_phy_init ..! 11: 00000004
ddr_inno_phy_init ..! 22: 00000006
ddr_inno_phy_init ..! 33: 00000006
REG_DDR_LMR: 00000210
REG_DDR_LMR: 00000310
REG_DDR_LMR: 00000110
REG_DDR_LMR, MR0: 00b73011
T30_0x5: 00000007
T30_0x15: 0000000c
T30_0x4: 00000000
T30_0x14: 00000002
INNO_TRAINING_CTRL 1: 00000000
INNO_TRAINING_CTRL 2: 000000a1
T30_cc: 00000003
INNO_TRAINING_CTRL 3: 000000a0
T30_118: 0000003c
T30_158: 0000003c
T30_190: 0000001f
T30_194: 0000001c
jz-04 : 0x00000051
jz-08 : 0x000000a0
jz-28 : 0x00000024
DDR PHY init OK
INNO_DQ_WIDTH :00000003
INNO_PLL_FBDIV :00000008
INNO_PLL_PDIV :00000002
INNO_MEM_CFG :00000051
INNO_PLL_CTRL :00000018
INNO_CHANNEL_EN :0000000d
INNO_CWL :00000006
INNO_CL :00000007
DDR Controller init
DDRC_STATUS 0x80000001
DDRC_CFG 0x0a688a40
DDRC_CTRL 0x0000891c
DDRC_LMR 0x00400008
DDRC_DLP 0x00000000
DDRC_TIMING1 0x040d0606
DDRC_TIMING2 0x02120607
DDRC_TIMING3 0x20060418
DDRC_TIMING4 0x14240031
DDRC_TIMING5 0xff060405
DDRC_TIMING6 0x32120505
DDRC_REFCNT 0x00c25b01
DDRC_MMAP0 0x000020fc
DDRC_MMAP1 0x00002400
DDRC_REMAP1 0x03020100
DDRC_REMAP2 0x07060504
DDRC_REMAP3 0x0b0a0908
DDRC_REMAP4 0x0f0e0d0c
DDRC_REMAP5 0x13121110
DDRC_AUTOSR_EN 0x00000000
sdram init finished
SDRAM init ok
board_init_r
image entry point: 0x80100000
U-Boot 2013.07 (Mar 17 2021 - 19:40:03)
Board: ISVP (Ingenic XBurst T21 SoC)
DRAM: 64 MiB
Top of RAM usable for U-Boot at: 84000000
Reserving 421k for U-Boot at: 83f94000
Reserving 32784k for malloc() at: 81f90000
Reserving 32 Bytes for Board Info at: 81f8ffe0
Reserving 124 Bytes for Global Data at: 81f8ff64
Reserving 128k for boot params() at: 81f6ff64
Stack Pointer at: 81f6ff48
Now running in RAM - U-Boot at: 83f94000
the manufacturer 52
SF: Detected NM25Q64EVB
In: serial
Out: serial
Err: serial
Net: cpm_mphyc_rst = 0x00000000 cpm_mphyc = 0x00000000
====>GMAC failed to reset!
Jz4775-9161
Hit any key to stop autoboot: 0
### Please input uboot password: ###
There is a login prompt it boots to: "IPCamera login:"
EDIT: Just after I posted I found the working U-Boot password! https://gist.github.com/gabonator/74cdd6ab4f733ff047356198c781f27d#gistcomment-3872769
isvp_t21# printenv
baudrate=115200
bootargs=console=ttyS1,115200n8 mem=44672K@0x0 rmem=20864K@0x2BA0000 init=/linuxrc rootfstype=squashfs root=/dev/mtdblock2 rw mtdparts=jz_sfc:256k(boot),1536k(kernel),2304k(root),3584k(ipc),512k(conf)
bootcmd=sf probe;sf read 0x80600000 0x40000 0x180000; bootm 0x80600000
bootdelay=1
ethact=Jz4775-9161
ethaddr=00:d0:d0:00:95:27
gatewayip=193.169.4.1
ipaddr=192.168.1.9
loads_echo=1
netmask=255.255.255.0
serverip=192.168.1.7
stderr=serial
stdin=serial
stdout=serial
Environment size: 512/16380 bytes
Looks like I've got it from here.
Awesome man! I was just about to say that I was going to dump my flash to find the password, but if you got it that’s awesome!
Let me know if you need anything else - if you post a copy of the ipc_server I may be able to find the right way to get the md5sum so you don’t have to open other cameras.
Thanks for the coffees too!
0367d55b458520ef4cfc52f7b6eead2f ipc_server size 1383136, timestamp Apr 21 01:57, 2021.
ipc_server.zip
@JayGoldberg I looked at the ipc_server in ghidra. It looks like the md5sum is calculated using the config_restore.bin with IPCAM added to the end of the file (just the 5 bytes without anything else. From the comments above seems like you tried getting the config_restore.bin's md5sum and placing in config_backup.bin but if you didn't add 'IPCAM' to the end of config_restore.bin it would not work. Would you be able to give that a try and let me know?
I did not add IPCAM to the end before calculating the md5sum, let me try that again and get back to you.
Yep, that worked!
@JayGoldberg thats awesome! So if you (or anyone else) gets a similar camera we should be able to enable telnet without opening the camera, possibly even doing the command injection with a custom wifi config file. Thanks for testing and letting me know!
Oh, I forgot to mention, on my camera, there is no telnetd either standalone or comiled into the onboard busybox, I had to add a line to /mnt/mtd/ipc/conf/run to copy a script from the TF card to /mnt/mtd/ipc/conf and had that script copy busybox-mipsel from TF to /mnt/mtd/ipc/conf/tmpfs, and execute it (the storage card is mounted noexec). And made some logging entries to /mnt/mtd/ipc/tmpfs/sd/log.txt so I could see them from the camera's web interface at http://ipcam/web/sd/
So in my case the injection would probably be to concatenate some commands to /mnt/mtd/ipc/conf/run or /mnt/mtd/ipc/conf/wifi.conf, as you suggested, to bootstrap telnet.
/mnt/mtd/ipc/conf/run:
...
$TARGET/ipc_server &
LOGFILEAUX=/mnt/mtd/ipc/tmpfs/sd/log.txt
while true; do
sleep 5
if [ -e /mnt/mtd/ipc/tmpfs/sd/.sd_flag ]; then
echo "ext.sh: Found SD card mounted" >> $LOGFILEAUX
echo "ext.sh: Copying $TARGET/tmpfs/sd/ext.sh to $TARGET/tmpfs/ext.sh" >> $LOGFILEAUX
cp $TARGET/tmpfs/sd/ext.sh $TARGET/tmpfs/ext.sh
echo "ext.sh: executing ext.sh" >> $LOGFILEAUX
$TARGET/tmpfs/ext.sh 2>> $LOGFILEAUX >> $LOGFILEAUX &
break
fi
done
@JayGoldberg did you check if your had the line . $WIFIPATH in /mnt/mtd/ipc/conf/run ? If you do what I would do without telnet in busybox/firmware is to copy a compatible busybox (with telnetd) and just use the wifi ssid setting to add a command like (sleep 60; /mnt/mtd/ipc/tmpfs/sd/init.sh) & so it would wait 60 seconds and execute the script on the SD card. The 60 seconds may need to be tweaked to make sure there's enough time for the SD card to be mounted before trying to execute the script. Then the script can copy busybox to tmpfs (ore remount with execute?) and run telnetd to start it (with -l /bin/sh or copying a /etc/passwd file first).
I'm just thinking of options to doing everything without using the UART but if you only have the 1 camera it really doesn't matter now.
There seems to be more to this. If I manipulate a single bit, and recalculate the checksum, it works because this doesn't affect the position of the 1024 bits of gibberish inserted regularly (every 16kb) into the backup starting at 0x600 then 0x4600 0x8600 0xC600 0x10600 and 0x14600 (before end of file). There seems to be a reason for this garbage in the file, and the camera checks for it.
When re-tarring the archive for upload, it does not contain this gibberish, no matter the options I specify for TAR format. I considered this is parity sets, but TAR has no such feature. I've tried:
$ tar --format=gnu -cf $wd/config.tar -C ./ mnt/mtd
$ tar --format=oldgnu -cf $wd/config.tar -C ./ mnt/mtd
$ tar --format=pax -cf $wd/config.tar -C ./ mnt/mtd
$ tar --format=posix -cf $wd/config.tar -C ./ mnt/mtd
$ tar --format=ustar -cf $wd/config.tar -C ./ mnt/mtd
$ tar --format=v7 -cf $wd/config.tar -C ./ mnt/mtd
I have 3 cameras that seem to work this way.
I'm unfortunately stuck with either UART access or injection via web UI/curl in order to root the cameras, and UART has been the only successful method so far.
@JayGoldberg What I would try is to make a long wifi SSID name or password, hopefully long enough to fit something like (sleep 60; /mnt/mtd/ipc/tmpfs/sd/b) & then save the backup and just change the bytes in the backup created by the device so that the escaping is removed and the command can actually be executed when the boot script loads it. Obviously you're going to need to do this using the wired network (assuming it's available) then you can just rebuild the md5sum using the config_restore.bin after a failed upload (without having to rebuild the whole tar file). If your device doesn't have wired connection then you can probably still do it by adjusting the ssid/password on the router temporarily but it will get a bit messy with editing the network name in the backup and such.
My /mnt/mtd/ipc/run file has these lines right up top:
TARGET="/mnt/mtd/ipc"
CONF="$TARGET/conf"
NETINFO=$CONF/config_net.ini
NETPRIV=$CONF/config_priv.ini
PLATFORM=$CONF/config_platform.ini
NETDEV=eth0
WIFIST=0
WIFIPATH="$CONF/wifi.conf"
. $WIFIPATH
Which means anything you can stick into /mnt/mtd/ipc/conf/wifi.conf gets executed -- if yours is similar then the above should hopefully work.
@JayGoldberg forgot to say the /mnt/mtd/ipc/tmpfs/sd/b file would be a script saved to the SD card with initial commands like copy passwd file to allow telnet access or just run telnet from busybox with -l /bin/sh - whatever you feel like trying.
@JayGoldberg another thing you can try is:
1-Edit the wifi.conf (with telnet) in the device that is ALREADY rooted to inject the commands desired
2-Save the backup with the command injections already in place
3-Restore the backup on the other devices (assuming they're the same type)
Those 3 are good ideas!
Also, I found on a forum some scripts to manipulate the backups, posted unpack.sh and pack.sh
Hello guys, first of thanks for the work on those exotic devices, searched hours to find something usefull!
I have also 3 of those cams
2x C6F0SoZ3N0PfL2 with software: V19.1.61.16.3-20210830 and webware: V3.0.7.1
1x C6F0SoZ3N0PcL2 with software: V19.1.64.16.65-20210304 and webware: V3.0.7.1
I tried to execute a script from the sd with this SSID password (sleep 60; /mnt/mtd/ipc/tmpfs/sd/init.sh) & but i dont know how i can remove the escaping or find it in the config backup, im not even sure if it is even stored in the backup config.
When i unpack the config_backup.bin i get those files:
config_alarm.ini config_image.ini config_recsnap.ini
config_com485.ini config_onvif.ini config_smartrack.ini
Could someone help me with this?
This cam should also have RS485 but im not sure how to use it or where the connector/header should be.
This all was tried on the C6F0SoZ3N0PfL2 cam.
I will take a look at your backup when I have a chance but if it doesn’t include wifi settings your options may be limited to hardware access (programmer and/or uart).
Also worth a shot: sometimes if you write the manufacturer asking for any firmware update available they will send you a file which can provide a lot of insight into the firmware without messing with the hardware (just tell them you’re having some minor software glitch that you’re hoping to be fixed on a newer firmware).
@HochleistungsChilla Your config backup seems to have about the right size but the config is not extracting correctly (there's an error processing the file). This could be a few different things:
1-There's corruption on the file you downloaded from the device -- you could try downloading it again and/or using a different browser
OR
2-There could be some specific setting causing problems to the backup process
OR
3-There could be some issue with the backup process in the device like old/corrupt tools and/or file system
I'd try 1 first and if it doesn't work I would suggest doing a full reset of the device using the 'factory reset' button in the same page you got the backup of the device.
If that doesn't help I would try downloading the backup and then restoring it (without changes) to see if it works and/or if it makes any difference on the issue.
Ok,
so i dont know why it is corrupt.
I now made a firmware downgrade to V19.1.61.15.3-20210111, made full resets, tried also different browsers but the config file is still the same what i can see. The restore of the backup works without errors and also the wifi settings are back.
I found a config file for the wifi in the firmware file:
┌──(kali㉿kali)-[~/…/mnt/mtd/ipc/conf]
└─$ cat hostapd8192_2g.conf
auth_algs=1
interface=wlan0
ctrl_interface=/var/run/hostapd
driver=rtl871xdrv
beacon_int=100
hw_mode=g
ieee80211n=0
wme_enabled=1
ht_capab=[SHORT-GI-20]
wpa=2
wpa_key_mgmt=WPA-PSK
wpa_pairwise=CCMP
wpa_passphrase=01234567
max_num_sta=3
wpa_group_rekey=86400
would it be possible to run a script from the sdcard through this config?
I will take a look at the boot scripts and see if there’s any chance that can be used, there’s however a minor risk of messing up your settings directory if they by any chance delete the files before restoring the backup.
@HochleistungsChilla does your device have Ethernet and Wifi or just wifi ? If it has ethernet you can try making a file wifi.conf in the mnt/mtd/ipc/conf directory with these contents:
WifiEnable=1
WifiType=Infra
WifiMode=WPA2PSK
WifiEnc=AES
WifiSsid="YOURSSID"
WifiKey="YOURWIFIPASSWORD"
/usr/sbin/telnetd -l /bin/sh
Then run the pack.sh script and try to restore the backup file.
Best case scenario: You'll have wifi and telnet enabled.
Worst case scenario: You'll have no wifi, no telnet and will need to access it using the ethernet.
Basically we're taking a guess that your firmware also uses wifi.conf file in the same way as mine, and as long as it restores the backup and places the new wifi.conf (with the telnet command in it) it should start telnet for you (with no password required).
I don't see anything in that hostapd*.conf file that can be used to run a command in the device, so I would not even try anything there.
NOTE: I would not try the above without ethernet or you may risk just bricking the device (you could still get lucky and be able to do a restore with a reset button if available).
Yeah it has ethernet, but no luck i only get Error 400: Bad Request Bad Request.
But i also get this error if i unpack and repack a original config backup and upload this.
@HochleistungsChilla likely your device is putting jibberish in the backup file like @JayGoldberg had and that's preventing the pack/unpack script from working as it should (possibly what is also causing the unpack not to retrieve all the files). If this is really the issue then the only options are either to go in thru the UART or try to get a new firmware from the manufacturer to see if that helps in any way. You could potentially ask @JayGoldberg to build you a config restore file with the command injected in it (as I described here) to see if that would work.
It may also be worth a shot trying to create a backup file with ONLY the wifi.conf file (in the /mnt/mtd/ipc/conf directory) as I described here -- it is possible that a config file small enough may not generate the giberish preventing the issue. I made this one that you can try (no wifi settings but telnet enabled) -- it's worth a shot:
config_backup-wifi-conf-only.zip