Hitronhub CVE-30360 (Kabel Deutschland) WLAN Hack?

I am almost certain that the download (of new software) is done by a program /usr/sbin/sw_dl. There are all kind of strings talking of images OK or not, CRC checks and tftp and such. This program is called once at boot and is not a daemon. I suppose it ends when there is nothing to download (no new image to install?) or when a new image is installed.

So maybe, when you never boot, you won't get a new image?
Or when you boot and immediately kill sw_dl , when it runs, you keep your current image? Not a nice method but ...
That is interesting. Especially sw_dl being run once at boot. How do you know that ?
Maybe we could make a firmware where sw_dl is not called at boot?
 
I have an idea of what may have caused the problems of mrproxy.

At one time I made a file in the directory /nvram/0. When I deleted this file a moment later I noticed some strange behaviour i.e. a file changed its name in a name "1". I am not sure if this happened instantaneously or after a reboot. After that I decided to stay away from these numbered files. Later I saw that these files may be some sort of a database system. Creation of files may interfere with this database. You can read this database with the nvread program.

It is possibly better to just stay in the /nvram directory and not to make files in these numbered directories.

In my opinion it is also better to make changes as late as possible in the chain of initialisation scripts. The sys_strartup.sh script is clearly meant as the place to make changes. At the end of this script means the least danger. The only thing a bit dangerous is the direct changes you have to make to the database (the full name of the sys_startup.sh script with the cli program) but there are some safeguards in the rcS script in case this file is empty or non executable. The danger is in the fact that you can put statements not at the end of this file (notably before runall for example).

So, if it is possible to just reflash the nvram part of the chips I would do that. Or maybe there is a way to reflash all the memory by holding buttons when powering up??
 
Redarding the sw_dl program:

I did not find any call to this program at the usual places:
/usr/bin /usr/sbin /usr/lib /bin /sbin /lib.

It is found only in the /etc/scripts/docsis.pcd file. These pcd files (in the script directory) are read by the pcd program which is started by the runall script (in /etc/scripts/sys_startup.sh or your own in /nvram). PCD is some sort of a rc program that starts all scripts and commands problably most as background nice programs and some waiting for completion of other programs.

A bit strange is that it is started with no parameters and in the program an error message is found about several parameters. I think that it finds its own parameters when started at startup.

It would be interesting to decompile/deassemble this program (but the strings in it suggest software download with all kinds of checks).

Because everything is in read-only memory, I don't see how we could disable this program.

If you could reflash the rootfs the obvious place to change would be this docsis.pcd file. One comment char "#" would be enough, I think.

I would prefer some software method though...

Added: I am sure sw_dl does the actual download at boot. It calls ti_tftp. I disassembled this program (sw_dl) but I don't know much about assembler, C or the used memory maps. I would very much like to know with what parameters ti_tftp is called. If it uses the default tftp port we could block that in the OUTPUT chain in iptables. I think that that should be done right after the runall command and that may even be to late. But before this command would have no effect because somewhere I saw that all rules are flushed. So may be somebody with knowledge of (ARM) assembler and C???
 
Zuletzt bearbeitet:
@mrproxy: I am very sad to here that, hope you get/got your box working again. No idea what went wrong. Maybe typo inside a script so the shell aborts with error before startup was complete. Maybe roald's variant is less error-prone.
During tests I had backup instructions in place to rename the startup file always as first (-> default startup after reboot in case later something went wrong).

I was digging inside of cli a bit and I found a lot of interessting stuff there. And finally I got my WiFi back and that was so easy as our previous WiFi enable tricks. So here is how to do it:

1. Login via ssh (see previous instructions how to do it)
2. Start command line interpreter: cli
3. switch to main/rg menu by entering: rg
4. enable wireless by entering (note first letter is uppercase): Wls 1

This will look like
Code:
~ # cli
help Display menu commands
debug:ssh logstr:SSH login from ::ffff:192.168.0.10


>>>
Console, CLI version 1.0.0.5
Type 'help' for list of commands

RootMenu> rg
MAIN> Wls 1
Enable wireless module!
MAIN> quit
CLI Bye Bye
~ #
This will enable WiFi with previous configuration settings. So if your WiFi was configured already you got it back as it was in past. If you need to change WiFi settings this is possible in cli as well (use help in rg menu for possible commands).

The only drawback is that WiFi is disabled after reboot again. So you have to enable it again. I don't know how to automate these interaction with cli, stuff like expect is not present on the box. But maybe someone else has an idea how to do that. If this would work, we could include that to our custom startup process as well and then WiFi will enabled even after reboot.
 
Btw. could anyone find the sources for the kernel modules htwls.ko, htsw.ko, htwpsbt.ko? I mean license information shows they are all GPL licensed.
Code:
hackerpeter@debian-armel:~/hitron$ /sbin/modinfo htwls.ko
filename:       /home/hackerpeter/hitron/htwls.ko
description:    Ralink iNIC 802.11n WLAN MII driver
author:         XiKun Wu <xikun_wu@ralinktech.com.tw>
license:        GPL
depends:        
vermagic:       2.6.18_pro500 preempt mod_unload ARMv6 gcc-4.2
parm:           root:RT3352iNIC: firmware and profile path offset (charp)
parm:           debug:RT3352iNIC: bitmapped message enable number (int)
parm:           mode:RT3352iNIC: iNIC operation mode: AP(default) or STA (charp)
parm:           mac:RT3352iNIC: iNIC mac addr (charp)
parm:           firmware:rt3052: iNIC firmware path (charp)
parm:           profile:rt3052: iNIC profile path (charp)
parm:           max_fw_upload:RT3352iNIC: Max Firmware upload attempt (int)
parm:           bridge:RT3352iNIC: on/off iNIC built-in bridge engine (int)
parm:           csumoff:RT3352iNIC: on/off checksum offloading over IPv4 <TCP, UDP> (int)
parm:           miimaster:RT3352iNIC: MII master device name (charp)
parm:           syncmiimac:RT3352iNIC: sync MAC with MII master (int)

hackerpeter@debian-armel:~/hitron$ /sbin/modinfo htsw.ko
filename:       /home/hackerpeter/hitron/htsw.ko
author:         Michael Zhu,HitronTech
version:        1.8.2
description:    AR8316 Driver
license:        GPL
srcversion:     76B5E32F18503E5B31EB36B
depends:        
vermagic:       2.6.18_pro500 preempt mod_unload ARMv6 gcc-4.2
parm:           irqdisable:Disable IRQ Hook for AR8316 (int)
parm:           rmon:Disable rmon timer for AR8316 (int)

hackerpeter@debian-armel:~/hitron$ /sbin/modinfo htwpsbt.ko
filename:       /home/hackerpeter/hitron/htwpsbt.ko
description:    WPS Button Driver
author:         Michael Zhu, HitronTech
license:        GPL
depends:        
vermagic:       2.6.18_pro500 preempt mod_unload ARMv6 gcc-4.2
 
Just checked KD website searching for possible downloads. This is more than crazy. Current online order benefit is free WiFi modem (50Mbit+ package). :rolleyes:

Maybe they will rethink current policy and will remove this WiFi disable crap from current firmware images again. (I have a dream...)
 
Tatsache, die bieten allen Neukunden von "Internet & Telefon 25, 50, 100" für die Vertragsdauer die WLAN Option kostenlos an.

Das nenne ich mal Kundenservice. Bloß nicht mal die Bestandskunden upgraden X(
 
According to KD, a new hitron piece of crap is 150 to 200 eur. Just the hitron, no on-site service. Unbelievable. Be careful not to brick it.
 
Habe mal ein kleines Werkzeug für Windows gestrickt damit auch Laien ihr WLAN aktivieren können. Hier eine kurze Beschreibung:

1. Tool herunterladen und entpacken
2. In Ordner hitron wechseln
3. Router neustarten mittels Schalter
4. hitron.exe ausführen
5. Abwarten bis es fertig ist ("Could not connect"- Ausgaben sind normal)


Code:
> hitron.exe --help

Usage: hitron.exe [options]

Options:
  -h, --help            show this help message and exit
  -r ROUTER, --router=ROUTER
                        ip of router
  -u USERNAME, --username=USERNAME
                        username
  -p PASSWORD, --password=PASSWORD
                        password
  -l LOG, --log=LOG     logging of responses
  -s SSH, --ssh=SSH     open ssh port

Quelltext ist hier.

Linuxer können das in Python geschriebene Programm auch nutzen. Installiert werden muss nur das Python-Paket paramiko. Zu finden mittels easy_install/pip.

Das Programm nutzt die von hackerpeter entdeckte Methode(cli->rg->Wls).
 
@flipflop: thx for automation of the necessary work from PC / "client" side

Btw. I am still trying to automate the stuff directly on the box itself, to solve the last drawback with restarts of the box. My first attempts failed to do that. But now I think I found a possible way. 8)

Problem is, I don't have much time for playing here. Real task to enable wireless again is solved, so everything else is fun/luxury on top. ;)

What I am trying is to build a cross compiler toolchain for this specific ARM architecture (ARMv6b). I want to compile this very small but FUCKING awesome tool called "empty".
empty - run processes and applications under pseudo-terminal (PTY) sessions (replace TCL/Expect with shell)
or see it in action on Youtube
Hak5 - Automate Interactive Processes in Linux without TCL/Expect, Hak5 1107.1 - YouTube
Basically it is a pure C alternative for the very known expect tool. The cool thing here is, that it is working on a file base so you could work with all our usual shell friends like grep, sed, awk ... check out the Youtube video ;)

If someone already has a working toolchain (linux-gnueabi-gcc, uclibc, binutils) it would be very kind to share the empty-binary file.
 
Zuletzt bearbeitet:
If someone already has a working toolchain (linux-gnueabi-gcc, uclibc, binutils) it would be very kind to share the empty-binary file.
I am interested in that too. Will try to build that thing soon.

The next thing I plan on doing is making a new firmware with nice additions(like python installed) and the update/block ssh port stuff removed.
 
Hi Flipflop, have you any ideas on installing firmware whithout a hardware reflash? I, at least, haven't got the equipment to do that and I prefer a 'software' method.

Have you ideas on blocking a software update for the time being (where we still can't reflash the Hitron ourself)?
 
Hi Flipflop, have you any ideas on installing firmware whithout a hardware reflash? I, at least, haven't got the equipment to do that and I prefer a 'software' method.

You can use cli->rg->dload command. Parameters are:
Code:
dload $1 $2 $3
    $1 - A.B.C.D   TFTP server IP address
    $2 - STRING   filename of CM software
    $3 -
           0     download via LAN interface
           1     download via RF interface
           2     download via CPE interface

So basically all you have to do is install a tftp server, do something like
Code:
dload x.x.x.x uberfirmware-v1.0 0
and it should place the new firmware in sector 2 (check with cli->rg->dir).
Then do
Code:
bootfrom 2 (is that correct?)
and it should be booting from sector 2.

For modification of current firmwares use firmware-mod-kit. It allows to unpack and repack the firmware files.
So what you do is you unpack the thing, do your modification and repack it.

If you want to put new binary programs onto the router you need to build the build toolchain for it.
For this you can use crosstool-ng. I don't know the exact configuration you need. Currently trying
"armeb-unknown-linux-uclibcgnueabi".

Hints regarding arch/libs/config:
Code:
> file firmwares/3.1.1.29/bin/ls
ELF 32-bit MSB executable, ARM, version 1 (SYSV), dynamically linked (uses shared libs), stripped

Code:
> objdump -p firmwares/3.1.1.29/bin/ls
(...)
Dynamic Section:
  NEEDED               libHtxShareUtils.so
  NEEDED               libm.so.0
  NEEDED               libpam.so.0
  NEEDED               libpam_misc.so.0
  NEEDED               libc.so.0
(...)

Code:
> uname -a
Linux CVE-30360 2.6.18_pro500 #1 PREEMPT Thu Sep 5 11:45:11 GMT 2013 armv6b GNU/Linux

-> linux kernel 2.6.18
-> arch is ARM
-> MSB / big endian
-> uses uClibc version 0.9.29

Have you ideas on blocking a software update for the time being (where we still can't reflash the Hitron ourself)?
sw_dl is the tool to flash the firmware onto the device. So removing it will stop update.
I will build a firmware where sw_dl is backup'd and replaced with a program that does nothing. That way programs accessing it do not fail.
 
Zuletzt bearbeitet:
Thanks for your quick answer.

I am afraid I can't help you with your toolchain; you are obviously more knowledgable in C an crosscompiling.

I think your right about how you could do an update yourself from your own ftp server. In my question I also meant that so long we can't do it the way you describe, we are vulnarable to a new software installation (alas only when you have to reboot, if I am correct). I think that blocking the tftp OUTPUT port just after the runall statement is not enough. What do you think. (but it can't do any harm too).

I just noticed something stange in my Hitron:

- I once did a dir (cli>rg>dir) and this was the reply:
MAIN> dir

Filename in sector 1->CVE-30360-3.1.1.29-IMS-KDG-131106.sbn
Filename in sector 2->CVE-30360-3.1.1.22-IMS-KDG-130528.sbn
Selected sector is 1

- today I did it again:

Filename in sector 1->CVE-30360-3.1.1.29-IMS-KDG-131106.sbn
Filename in sector 2->EMPTY IMAGE
Selected sector is 1

I think this is a result of a dload or sw_dl command I may have given and terminated. So this suggests that a new dload comes in sector2. Bootfrom 2 would boot from the new installed software. But what would happen if this boot doesn't succeed. Would it then boot next time from sector 1?
 
I am afraid I can't help you with your toolchain; you are obviously more knowledgable in C an crosscompiling.
Actually this is the first time I do stuff like this :)

I think that blocking the tftp OUTPUT port just after the runall statement is not enough. What do you think. (but it can't do any harm too).
If the output port is always the same go for it.

I think this is a result of a dload or sw_dl command I may have given and terminated.
Yes it is. Sector 2 gets nuked before the tftp download. You fed it no firmware so the sector stays empty. Also dload calls sw_dl with some more parameters set.

So this suggests that a new dload comes in sector2. Bootfrom 2 would boot from the new installed software. But what would happen if this boot doesn't succeed. Would it then boot next time from sector 1?
That's a good question. Better to not try it :)
 
So, it may be wise to tftp the normal image .29 from your own ftp server with no changes and see if the upload is succesfull. After that you can make changes in the image and hope everything goes well too.

That is how I would do it, anyway (for what it's worth).

Hopefully you would never have to find out if you can boot from the old image if the new image won't start. But you might still wonder ...
 
armeb-unknown-linux-uclibcgnueabi is the correct toolchain.
I just compiled a simple program and it works on the router.

Here the listing of commands:
Code:
sudo apt-get install build-essential libncurses5-dev
sudo apt-get install automake libtool bison flex texinfo
sudo apt-get install libexpat1-dev python-dev
wget http://crosstool-ng.org/download/crosstool-ng/crosstool-ng-1.19.0.tar.bz2
tar -xf crosstool-ng-1.19.0.tar.bz2
cd crosstool-ng-1.19.0
./configure
make
sudo make install
cd ..
mkdir toolchain
cd toolchain
ct-ng armeb-unknown-linux-uclibcgnueabi
ct-ng build

The last command will take very long. On my machine it took like 45 minutes.

You can build a program using:
Code:
~/x-tools/armeb-unknown-linux-uclibcgnueabi/bin/armeb-unknown-linux-uclibcgnueabi-gcc -o hello hello.c
 
flip please dont forget to use the corrected version 29 binary that someone sent to you via private message on the 4th of january for any testing or device recovery. uploading the wrong binary of version 29 to the hitron (which is currently on git and currently missing some (65536 bytes) of its head) may cause major problems. you probably know that, i just wanted to make sure, because you did not answer said person. ;)

i dont know if anyone else has got the wrong version, because i honstely dont know if and how you can download it from github.com.
the correct version i extracted of both flashs and joined together has 11013120 bytes. the smaller one (10947584 bytes) is the incomplete one, which noone should use (except for filesystemextraction, which works with both).
 
@flipflop
Awesome to see you are doing same I do/try.. my ct-ng build faild with some segfaults (don't know why yet). So I skipped building the cross compiler toolchain and uploaded your empty binary to my box. At least it is executable, a simple ./empty -h works. But I wasn't able to get it further doing something, my output is always empty.
After looking into empty.c I think I found the reason.
Code:
    106 #define tmpdir "/tmp"
Could you please change that line to /var/tmp and recompile it again? This assumption about /tmp existing on nearly all Linux systems isn't true for our box :D
 
Zurück
Oben