Quicksearch: Your search for b593 returned 33 results:
De-bricking a B593-s22
Tuesday, May 17. 2016
I finally did it!
The unit has been non-functional for over a year now. See details in my previous post. But I got it back.
First, I'd like to clarify the myth of "equipment mode". Yes, that does exist. You'll know that your box is bricked and the reason for that is because you're in equipment mode, as your RS-232 -console output will say following during boot-up:
now in wifi mfg
g_Equip_Mode_value = 1
What needs to be done, is getting that Equip_Mode
flag off. On "normal" mode bootup, two distinct differences appear at the output:
now in wifi release
normal mode, no need to load RF wifi
and
g_Equip_Mode_value = 0
My sincere thanks goes to Mr. Jevgenij for telling me a magical NVRAM-location to look at.
The brick
My bricked B592 s-22 (in equipment mode) looked like this on a boot sequence:
(Sorry about the signal LED glowing, that was my failure when lighting the box for video. I didn't realize that on my footage it looks like being lit, while in reality it isn't. A bricked box won't show any signal there.)
At power-on, the Power-LED gets lit all the others are off. Then the boot-sequence handles lot of hardware and gets a Linux to boot. They call it the "early init". There are no differences between modes at that point.
Next, what happens is the Linux-side taking control and starting to spin up services. One of the first things it does is kicking all the LEDs lit. When enough services are on, and Linux wants to fiddle with LTE-side all the LEDs go off. Now that the device is configured not to offer all hardware services to Linux-side, rest of the boot sequence goes haywire. There is no Wi-Fi, there is no Ethernet-bridge and lot of stuff fail during boot. Your best clue about this dreaded equipment mode is the Tel LED blinking on/off forever. Actually the box is not doing much at that point. It has given up all hope on getting a handle of the LTE-side or the Ethernet bridge.
Luckily, the box is sane enough to allow a SSH-login. In equipment mode, it will bypass the ATP Cli completely and land at the BusyBox-prompt. There your friend is lteat
-command. Go back to my older stuff, for details about that.
The fix
The prerequisite for the fix is, that you are logged into your B593 s-22 via SSH and are able to run lteat and get sensible response out of it. Example (the blank lines happen on my SSH, I don't know why):
# lteat
AT>ati
i
Model: B593s-22
Revision: V200R001B180D20SP05C260
IMEI: 860091028600910
+GCAP: +CGSM,+DS,+ES
OK
AT>
Then you're good to go.
First confirm, that you are in the equipment mode:
AT>at ^nvrd=52110
^NVRD: 12,31 00 00 00 00 00 00 00 00 00 00 00
OK
That's a ReaD-command for NVRAM address location 52110. To change the mode back to normal, a WRite needs to be issued:
AT>at ^nvwr=52110,1,0
OK
Confirm the result:
AT>at ^nvrd=52110
^NVRD: 12,00 00 00 00 00 00 00 00 00 00 00 00
OK
Notice how the hex value 0x31 is changed to 0x00. Btw. if you look at the ASCII-table, you may notice, that 0x31 stands for number 1. That's would be similar to the (1) in g_Equip_Mode_value = 1
.
Now all you have to do is power-off your box and kick it back on.
Finally
I don't have a clue why/how/when my box went into this "stupidity"-mode. I was fiddling with the LTE-side at lteat
-prompt when it happened. I did try dozens of different commands, any of those may have caused that.
Also, if you're unable to SSH into your box, you may need to read my or somebody else's articles. It's all explained there.
Huawei E5186 RS-232 pins explained
Saturday, January 23. 2016
For the 2nd time, I got an E5186 loaner (post about the 1st time here). This time with permission to take a closer look inside.
Since this one had already RS-232 wires soldered, I took them for closer inspection. Un-boxing is exactly like in B593, 3 PH-2 screws holding the cover in place. Two at the bottom of the unit (one covered with a warranty paper) and one screw at the back between LTE-antennas.
Layout
After popping the cork, the board's flipside looks like this:
In this unit, there is no need to pry open none of the 4 shiny ESD covers. All the good stuff is on the other side. Again, 4 PH-2 screws holding the board in place.
Board, right side up:
In this case, the obvious clue for me was the already soldered RS-232 wires. I'm also publishing another picture by KOSH, a LTEforum.at activist, describing some of the good parts an E5186 board has:
There are 2 of: LTE/UMTS antennas on top corners, 5 GHz WLAN antennas at the sides and 2,4 GHz WLAN antennas on the bottom corners. The picture doesn't point out the locations of RS-232 pins, only the ground and Vcc pins.
Linux
A closer look of the Linux side pins right next to the SIM-slot:
No surprises there, the signal levels of RS-232 were 1,8 volts. It means, that an expensive USB-RS232 adapter is rquired for access. Your run-of-the-mill cheap 3,3 volt adapters are completely useless for this.
The descripions of RX/TX are from the point of the router (DCE), not from your computer (that would be DTE). It means, that any output signal (TX or transmit) described in the picture should be connected to input of the computer (RX or receive).
A bootup output of that port would be:
Digital core power voltage set to 0.9375V
Decompressing...done
CFE version 6.37.14.34 (r415984) based on BBP 1.0.37 for BCM947XX (32bit,SP,)
Build Date: Sat Jun 13 09:28:20 CST 2015 (l00285057@MBB-V7R1-CPE)
Copyright (C) 2000-2008 Broadcom Corporation.
Init Arena,cfe repair version
Config GPIOs.
Init Devs.
Boot partition size = 262144(0x40000)
flash_init: bootsz = [0x80000]
add new online part !!!!!!!!
flash_init:flash_size:[0x8000000][0x2000000|33554432]
DDR Clock: 400 MHz
Info: DDR frequency set from clkfreq=800,*400*
et0: Broadcom BCM47XX 10/100/1000 Mbps Ethernet Controller 6.37.14.34 (r415984)
CPU type 0x0: 800MHz
Tot mem: 131072 KBytes
CFE mem: 0x00F00000 - 0x010AC8E4 (1755364)
Data: 0x00F646F0 - 0x00F65184 (2708)
BSS: 0x00F65190 - 0x00FAA8E4 (284500)
Heap: 0x00FAA8E4 - 0x010AA8E4 (1048576)
Stack: 0x010AA8E4 - 0x010AC8E4 (8192)
Text: 0x00F00000 - 0x00F55E40 (351808)
Device eth0: hwaddr 00-90-4C-0F-0F-00, ipaddr 192.168.1.1, mask 255.255.255.0
gateway not set, nameserver not set
not in router upgrade mode
Loader:raw Filesys:raw Dev:nflash0.os File: Options:(null)
Loading: ..... 5853216 bytes read
Entry at 0x00008000
Closing network.
Starting program at 0x00008000
[ 2.950000] console [ttyS0] enabled, bootconsole disabled
[ 2.950000] serial8250.0: ttyS1 at MMIO 0x18000400 (irq = 117) is a 16550
[ 2.960000] brd: module loaded
[ 2.970000] loop: module loaded
[ 2.970000] [CHIP_COMM] LINE:849: [client] socket send fail!
[ 2.980000] DRV_RHPC: Detect Modem fail with 0x1, run startup status detection thread!!
[ 2.990000] Platform Driver Remote Host Procedure Call init.
[ 2.990000] Enter ecall init
[ 3.000000] Finish ecall init
[ 3.000000] tsk:kthread_run is success!
[ 3.000000] SCSI Media Changer driver v0.25
[ 3.010000] pflash: found no supported devices
[ 3.020000] bcmsflash: found no supported devices
[ 3.070000] Boot partition size = 524288(0x80000)
[ 3.080000] lookup_nflash_rootfs_offset: offset = 0x200000
[ 3.080000] nflash: squash filesystem with lzma found at block 35
[ 3.090000] Creating 4 MTD partitions on "nflash":
[ 3.090000] 0x000000000000-0x000000080000 : "boot"
[ 3.100000] 0x000000080000-0x000000200000 : "nvram"
[ 3.110000] 0x000000200000-0x000002a00000 : "linux"
[ 3.110000] 0x0000004600f8-0x000002a00000 : "rootfs"
[ 3.120000] PPP generic driver version 2.4.2
[ 3.120000] PPP Deflate Compression module registered
[ 3.130000] PPP BSD Compression module registered
[ 3.130000] PPP MPPE Compression module registered
[ 3.140000] NET: Registered protocol family 24
[ 3.140000] SLIP: version 0.8.4-NET3.019-NEWTTY (dynamic channels, max=256).
[ 3.150000] usbmon: debugfs is not available
[ 3.150000] ehci_hcd: USB 2.0 'Enhanced' Host Controller (EHCI) Driver
[ 3.160000] ehci_hcd 0000:00:0b.1: EHCI Host Controller
[ 3.170000] ehci_hcd 0000:00:0b.1: new USB bus registered, assigned bus number 1
[ 3.210000] ehci_hcd 0000:00:0b.1: irq 111, io mem 0x18021000
[ 3.230000] ehci_hcd 0000:00:0b.1: USB 0.0 started, EHCI 1.00
[ 3.230000] hub 1-0:1.0: USB hub found
[ 3.240000] hub 1-0:1.0: 2 ports detected
[ 3.240000] ohci_hcd: USB 1.1 'Open' Host Controller (OHCI) Driver
[ 3.250000] ohci_hcd 0000:00:0b.0: OHCI Host Controller
[ 3.250000] ohci_hcd 0000:00:0b.0: new USB bus registered, assigned bus number 2
[ 3.260000] ohci_hcd 0000:00:0b.0: irq 111, io mem 0x18022000
[ 3.320000] hub 2-0:1.0: USB hub found
[ 3.320000] hub 2-0:1.0: 2 ports detected
[ 3.330000] xhci_hcd 0000:00:0c.0: xHCI Host Controller
[ 3.330000] xhci_hcd 0000:00:0c.0: new USB bus registered, assigned bus number 3
[ 3.340000] xhci_hcd 0000:00:0c.0: irq 112, io mem 0x18023000
[ 3.350000] xhci_hcd 0000:00:0c.0: Failed to enable MSI-X
[ 3.350000] xhci_hcd 0000:00:0c.0: failed to allocate MSI entry
[ 3.360000] usb usb3: No SuperSpeed endpoint companion for config 1 interface 0 altsetting 0 ep 129: using minimum values
[ 3.370000] xHCI xhci_add_endpoint called for root hub
[ 3.380000] xHCI xhci_check_bandwidth called for root hub
[ 3.380000] hub 3-0:1.0: USB hub found
[ 3.390000] hub 3-0:1.0: 1 port detected
[ 3.390000] usbcore: registered new interface driver cdc_acm
[ 3.400000] cdc_acm: v0.26:USB Abstract Control Model driver for USB modems and ISDN adapters
[ 3.410000] usbcore: registered new interface driver usblp
[ 3.410000] Initializing USB Mass Storage driver...
[ 3.420000] usbcore: registered new interface driver usb-storage
[ 3.420000] USB Mass Storage support registered.
[ 3.430000] usbcore: registered new interface driver usbserial
[ 3.430000] USB Serial support registered for generic
[ 3.440000] usbcore: registered new interface driver usbserial_generic
[ 3.450000] usbserial: USB Serial Driver core
[ 3.450000] USB Serial support registered for GSM modem (1-port)
[ 3.460000] usbcore: registered new interface driver option
[ 3.460000] option: v0.7.2:USB Driver for GSM modems
[ 3.470000] USB Serial support registered for pl2303
[ 3.470000] usbcore: registered new interface driver pl2303
[ 3.480000] pl2303: Prolific PL2303 USB to serial adaptor driver
[ 3.480000] u32 classifier
[ 3.490000] Performance counters on
[ 3.490000] Actions configured
[ 3.490000] Netfilter messages via NETLINK v0.30.
[ 3.500000] nf_conntrack version 0.5.0 (1935 buckets, 7740 max)
[ 3.510000] ctnetlink v0.93: registering with nfnetlink.
[ 3.510000] nf_conntrack_rtsp v0.6.21 loading
[ 3.520000] xt_time: kernel timezone is -0000
[ 3.520000] IPVS: Registered protocols ()
[ 3.520000] IPVS: Connection hash table configured (size=4096, memory=32Kbytes)
[ 3.530000] IPVS: ipvs loaded.
[ 3.530000] IPv4 over IPv4 tunneling driver
[ 3.540000] nf_nat_rtsp v0.6.21 loading
[ 3.540000] ip_tables: (C) 2000-2006 Netfilter Core Team
[ 3.550000] arp_tables: (C) 2002 David S. Miller
[ 3.550000] TCP cubic registered
[ 3.560000] NET: Registered protocol family 10
[ 3.560000] lo: Disabled Privacy Extensions
[ 3.570000] tunl0: Disabled Privacy Extensions
[ 3.570000] ip6_tables: (C) 2000-2006 Netfilter Core Team
[ 3.580000] IPv6 over IPv4 tunneling driver
[ 3.580000] sit0: Disabled Privacy Extensions
[ 3.590000] ip6tnl0: Disabled Privacy Extensions
[ 3.590000] NET: Registered protocol family 17
[ 3.600000] Bridge firewalling registered
[ 3.600000] Ebtables v2.0 registered
[ 3.600000] L2TP core driver, V2.0
[ 3.610000] PPPoL2TP kernel driver, V2.0
[ 3.610000] 802.1Q VLAN Support v1.8 Ben Greear
[ 3.620000] All bugs added by David S. Miller
[ 3.640000] Northstar brcmnand NAND Flash Controller driver, Version 0.1 (c) Broadcom Inc. 2012
[ 3.650000] NAND device: Manufacturer ID: 0x2c, Chip ID: 0xf1 (Micron NAND 128MiB 3,3V 8-bit)
[ 3.660000] Spare area=64 eccbytes 56, ecc bytes located at:
[ 3.660000] 2 3 4 5 6 7 8 9 10 11 12 13 14 15 18 19 20 21 22 23 24 25 26 27 28 29 30 31 34 35 36 37 38 39 40 41 42 43 44 45 46 47 50 51 52 53 54 55 56 57 58 59 60 61 62 63
[ 3.680000] Available 7 bytes at (off,len):
[ 3.680000] (1,1) (16,2) (32,2) (48,2) (0,0) (0,0) (0,0) (0,0)
[ 3.690000] Scanning device for bad blocks
[ 3.780000] Options: NO_AUTOINCR,NO_READRDY,BBT_SCAN2NDPAGE,
[ 3.790000] Creating 5 MTD partitions on "brcmnand":
[ 3.790000] 0x000002a00000-0x000003e00000 : "userdata"
[ 3.800000] 0x000003e00000-0x000005200000 : "app"
[ 3.800000] 0x000005200000-0x000005c00000 : "webui"
[ 3.810000] 0x000005c00000-0x000006000000 : "online"
[ 3.810000] 0x000006000000-0x000008000000 : "upg"
[ 3.830000] VFS: Mounted root (squashfs filesystem) readonly on device 31:3.
[ 3.840000] devtmpfs: mounted
[ 3.840000] Freeing init memory: 236K
/sbin/hotplug2: No such file or directory
insmod: ipv6.ko: no module by that name found
insmod: cannot insert '/lib/modules/2.6.36.4brcmarm+/kernel/drivers/net/igs/igs.ko': Operation not permitted (-1): Operation not permitted
hotplug detected product: 12d1/1443/1
hotplug detected product: 12d1/1443/1
insmod: bcm57xx.ko: no module by that name found
boardflags:100
That looks a lot like a B593-s22 booting. A 2.6.36 Linux there running on a 32-bit BCM947XX chip.
LTE
The other RS-232 port has following pins:
It outputs something like this on a boot:
onchip
NF boot!
UnSec_boo Wä123
sec disable
456
[0000005ms]
[0000005ms]
[0000005ms]*********************************************************
[0000006ms]FASTBOOT simple console, enter 'help' for commands help.
[0000006ms]*********************************************************
[0000006ms]balong_version_get_hw_version doesn't judge udp!
[0000007ms]balong_version_get_hw_version: HARDID = 0X00040000
[0000007ms]Hisilicon NANDC_V6.00 initialize...
[0000007ms]NAND device: Manufacturer ID: 0x000000ad, Chip ID: 0x000000ac (Hynix NAND 512MiB 1,8V 8-bit)
[0000008ms]Partition Table list(HEX):ptable 1.00HI6930_V7R2_MCPEm3boot
[0000008ms]NO. |offset |loadsize |capacity |loadaddr |entry |property |count |id |name |
[0000009ms]------------------------------------------------
[000000Ams]00000001: 00000000 ,00000000 ,00040000 ,00000000 ,00000000 ,00004000 ,00000000 ,00000101 ,m3boot
[000000Ams]00000002: 00040000 ,00000000 ,001c0000 ,4fe00000 ,4fe00000 ,00004000 ,00000000 ,00000102 ,fastboot
[000000Bms]00000003: 00200000 ,00000000 ,00200000 ,00000000 ,00000000 ,00004800 ,00000000 ,00000103 ,nvbacklte
[000000Cms]00000004: 00400000 ,00000000 ,00400000 ,00000000 ,00000000 ,00004000 ,00000000 ,00000104 ,nvimg
[000000Cms]00000005: 00800000 ,00000000 ,00400000 ,00000000 ,00000000 ,00004000 ,00000000 ,00000105 ,nvdload
[000000Dms]00000006: 00c00000 ,00000000 ,00200000 ,00000000 ,00000000 ,00004000 ,00000000 ,00000106 ,nvdefault
[000000Ems]00000007: 00e00000 ,00000000 ,00400000 ,00000000 ,00000000 ,00004000 ,00000000 ,0000010d ,oeminfo
[000000Ems]00000008: 01200000 ,00000000 ,0be00000 ,00000000 ,00000000 ,00004001 ,00000000 ,00000116 ,online
[000000Fms]00000009: 0d000000 ,00000000 ,00800000 ,4ffc0000 ,4ffc0000 ,00004000 ,00000000 ,00000107 ,kernel
[0000010ms]0000000a: 0d800000 ,00000000 ,00800000 ,4ffc0000 ,4ffc0000 ,00004000 ,00000000 ,00000108 ,kernelbk
[0000010ms]0000000b: 0e000000 ,00000000 ,00200000 ,00000000 ,00000000 ,00004000 ,00000000 ,00000109 ,m3image
[0000011ms]0000000c: 0e200000 ,00000000 ,00600000 ,00000000 ,00000000 ,00004000 ,00000000 ,0000010b ,dsp
[0000011ms]0000000d: 0e800000 ,00000000 ,00200000 ,00000000 ,00000000 ,00004000 ,00000000 ,0000011b ,misc
[0000012ms]0000000e: 0ea00000 ,00000000 ,02800000 ,50d10000 ,50d10000 ,00004000 ,00000000 ,0000010a ,vxworks
[0000013ms]0000000f: 11200000 ,00000000 ,00100000 ,00000000 ,00000000 ,00004000 ,00000000 ,00000112 ,wbdata
[0000013ms]00000010: 11300000 ,00000000 ,00100000 ,00000000 ,00000000 ,00004000 ,00000000 ,00000113 ,reserve2
[0000014ms]00000011: 11400000 ,00000000 ,00300000 ,00000000 ,00000000 ,00004001 ,00000000 ,00000114 ,reserve3
[0000015ms]00000012: 11700000 ,00000000 ,00c00000 ,00000000 ,00000000 ,00004001 ,00000000 ,0000010f ,om
[0000015ms]00000013: 12300000 ,00000000 ,0ad00000 ,00000000 ,00000000 ,00004001 ,00000000 ,0000010e ,system
[0000016ms]00000014: 1d000000 ,00000000 ,02d00000 ,00000000 ,00000000 ,00004001 ,00000000 ,00000117 ,cdromiso
[0000017ms]00000015: 1fd00000 ,00000000 ,00280000 ,00000000 ,00000000 ,00004000 ,00000000 ,00000118 ,cache
[0000017ms]00000016: 1ff80000 ,00000000 ,00040000 ,00000000 ,00000000 ,00004000 ,00000000 ,00000119 ,recovery-a
[0000018ms]00000017: 1ffc0000 ,00000000 ,00040000 ,00000000 ,00000000 ,00004000 ,00000000 ,0000011a ,recovery-b
[0000019ms]^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
[0000019ms]fastboot: nv dload cap is 0x00400000.
[000001Ams]fastboot: dload nv invlv_blk_num:7, total_blk_num:32!
[000001Ams]fastboot: dload nv skip total bad blk:0!
[000001Bms]warning: end page size not aligned :addr_logic:0x008e5000,blockleft:0x00000104
[0000025ms]nv boot init ok!
[0000026ms][tsensor]: tsensor init ok!
[0000026ms]board_init ok
[0000028ms]USB FastBoot: V0.9
[0000028ms]Machine ID: 3339 v0
[0000028ms]Build Date: Jun 13 2015, 09:54:53
[0000028ms]
[0000028ms]Serial Number: UNKNOWN
[0000028ms]
[0000028ms]Heap:0x5fd3c220 -- 0x5fd3c860, 1600
[0000029ms][pmu]: volt_id 35's voltage can not be set!
[0000029ms]
[0000029ms][pmu]: volt_id 39's voltage can not be set!
[000002Ams]
[000002Ams]Please distribute uart with command L/V/M...
[000002Ams] heap:0x5fd3c220 -- 0x5fd3c860, 1600
[000002Ams]OCR_AUTO_ENUM_FLAG_ADDR = 4fe1fff8 flag =eab35f51 !
[000002Bms]
[000002Bms] [ ON OFF ] Start up by Cold Reset!,reboot_cmd=0x90a7b368.
[000002Bms]balong_version_get_hw_version doesn't judge udp!
[000002Cms]balong_version_get_hw_version: HARDID = 0X00040000
[000002Cms]balong_version_get_hw_version doesn't judge udp!
[000002Cms]balong_version_get_hw_version: HARDID = 0X00040000
[000002Dms][fastboot]: boot_mode 1
[000002Dms]boot m3image from flash
[000002Dms]ptn:5fd36bbc , ptn->start = 0e000000 ptn->length = 00200000
[000002Dms]ptn:5fd36bbc , ptn->loadaddr = 00000000 ptn->entry = 00000000
[000002Ems]warning: end page size not aligned :addr_logic:0x0e00b000,blockleft:0x000003a8
[000002Fms]boot linux from flash
I don't think this side boots properly, so the output has only HiSilicon NAND-flash and Hynix DRAM mentioned.
Finally
I didn't manage to get any kind of console or prompt. There are couple of points where the Linux-side says "Press Enter to continue...", but event that didn't work. To me, it looks like the unit is not taking any input.
If you have any further information, please drop a comment below.
Huawei B593 s-22 more RS-232 pins
Tuesday, March 24. 2015
After poking a s-22 around with an oscilloscope I managed to find a serial signal out of it. However, Mr. Asiantuntijakaveri pointed out, that it isn't especially useful. To him that serial stuff looked like the mobile-side baseband. Couple of hours tinkering with VxWorks prompt didn't result much for me. So, back to the scope ...
This is what I found:
Another 1,8 volt serial signal. RS-232 parameters are alike the other one 115200 bps 8N1. I couldn't confirm the DCE RX-pin. There is one with suitable electrical characteristics, but it looks like the box doesn't offer any input capabilities, not at least with default configuration.
The data on boot time looks like this:
v?l?space?write magic succsse!%x
24680138%s start addr:0x%x size:0x%x
first step
second step
thred step
DDR exam right !!!!!!!!!!!!!!!!!!!!!!!
press space key to enter bootrom:
Start from: vxWorks Kernel.
>>loading: VxWorks ... success.
>>loading: FastBoot ... success.
hw main id:00000400, sub id:00000001activate_fastboot...0x3CD00000
Starting from entry: 0x30004000
[ 0.000000] Linux version 2.6.35.7 (q81003564@MBB-V7R1-CPE) (gcc version 4.5.1 (ctng-1.8.1-FA) ) #1 PREEMPT Mon Jun 3 13:50:16 CST 2013
[ 0.000000] CPU: ARMv7 Processor [413fc090] revision 0 (ARMv7), cr=18c53c7f
[ 0.000000] CPU: VIPT nonaliasing data cache, VIPT nonaliasing instruction cache
[ 0.000000] Machine: Hisilicon Balong
[ 0.000000] Ignoring unrecognised tag 0x4d534d70
[ 0.000000] Memory policy: ECC disabled, Data cache writeback
[000005940ms] Built 1 zonelists in Zone order, mobility grouping on. Total pages: 36576
[000005941ms] Kernel command line: root=/dev/ram0 rw console=ttyAMA0,115200 console=uw_tty0 rdinit=/init mem=144m
[000005941ms] PID hash table entries: 1024 (order: 0, 4096 bytes)
[000005941ms] Dentry cache hash table entries: 32768 (order: 5, 131072 bytes)
[000005942ms] Inode-cache hash table entries: 16384 (order: 4, 65536 bytes)
[000005957ms] Memory: 144MB = 144MB total
[000005957ms] Memory: 133780k/133780k available, 13676k reserved, 0K highmem
[000005957ms] Virtual kernel memory layout:
[000005957ms] vector : 0xffff0000 - 0xffff1000 ( 4 kB)
[000005957ms] fixmap : 0xfff00000 - 0xfffe0000 ( 896 kB)
[000005957ms] DMA : 0xff600000 - 0xffe00000 ( 8 MB)
[000005957ms] vmalloc : 0xc9800000 - 0xf0000000 ( 616 MB)
[000005957ms] lowmem : 0xc0000000 - 0xc9000000 ( 144 MB)
[000005957ms] modules : 0xbf000000 - 0xc0000000 ( 16 MB)
[000005957ms] .init : 0xc0008000 - 0xc0028000 ( 128 kB)
[000005958ms] .text : 0xc0028000 - 0xc06ca000 (6792 kB)
[000005958ms] .data : 0xc06ca000 - 0xc0701520 ( 222 kB)
[000005958ms] SLUB: Genslabs=11, HWalign=32, Order=0-3, MinObjects=0, CPUs=1, Nodes=1
[000005958ms] Preemptable hierarchical RCU implementation.
[000005958ms] RCU-based detection of stalled CPUs is disabled.
[000005958ms] Verbose stalled-CPUs detection is disabled.
[000005958ms] NR_IRQS:160
[000005958ms] Console: colour dummy device 80x30
[000005958ms] Calibrating delay loop... 897.84 BogoMIPS (lpj=4489216)
[000006218ms] pid_max: default: 4096 minimum: 301
[000006218ms] Mount-cache hash table entries: 512
[000006218ms] CPU: Testing write buffer coherency: ok
[000006219ms] start log trace.
[000006223ms] NET: Registered protocol family 16
[000006224ms] Serial: BalongV7R1 UART driver
[000006224ms] dev:uart0: ttyAMA0 at MMIO 0x90007000 (irq = 102) is a Balong rev0
[000006435ms] console [ttyAMA0] enabled
[000006461ms] bio: create slab at 0
[000006465ms] hi_gpio_probe:gpio sync in acore.
[000006469ms] hi_gpio_probe:gpio sync over.
[000006474ms] SCSI subsystem initialized
[000006478ms] enter Acpu-softtimer-modeule-init!!!
[000006482ms] softtimer_module_start_success-,1-- >>>>>>>>>>>>>>
[000006488ms] start create the softtimer thread!!!
[000006492ms] end the Acpu_softtimer_init() !!!
[000006497ms] usbcore: registered new interface driver usbfs
[000006503ms] usbcore: registered new interface driver hub
[000006508ms] usbcore: registered new device driver usb
[000006513ms] ***************************************************************
[000006520ms] begin to init mutilcore: 0000
[000006524ms] hw id: main,0x400, sub,0x1
[000006528ms] ===== beg mem usr function =====
[000006532ms] begin to init mutilcore: 222
[000006536ms] start BSP_ICC_Init
[000006539ms] g_pstIccCtrlChan = 0xf2fc02c0
[000007098ms] ##### icc init success!, cnt=1971, connet=1
[000007103ms] end BSP_ICC_Init
[000007106ms] begin to init mutilcore: 333
[000007110ms] begin to init mutilcore: 444
[000007113ms] BSP_MODU_IFCP
IFC Process init success!
[000008606ms] A:start icc cshell...
[000008609ms] cshell_icc_open success,cshell_udi_handle is 5898241
[000008615ms] free_ok
[000008617ms] the lcr_reg is 3
[000008620ms] pTemp is 0xc8a90000
[000008623ms] UDI_BUILD_DEV_ID is 0x300
[000008626ms] start NVM_Init
[000008629ms] MSP_IPC udi_open Start
[000009297ms] MSP_IPC udi_open End Handle = 5a0002
[000009715ms] end NVM_Init
[000009718ms] begin to init mutilcore: 555
[000009721ms] BCM43239_WIFI_Release: Entering...
[000009726ms] DRV_HSIC_Release: Entering ...
Actually there is like 1000 lines more log, but it's just Linux loading. Including in the log there are SSH-passwords for 2 users admin and user. They are exactly what sshusers.cfg
will have after boot.
It will take couple of seconds for the bootloader to kick on the Android-side. The bootloader serial-data starts flowing in immediately, but this one sleeps a while and starts after that.
Side buttons exaplained
I have previously touched the subject of WiFi / Reset / WPS -buttons. Also I got a comment about un-bricking a s-22, but that didn't help me much. This is related to serial output in a sense, that pressing the buttons will have effect on the serial output.
Now that I have a clear view of what's happening at the box I'd like to take this opportunity of describing the three buttons' behaviour:
- (device running normally) WiFi button pressed for over 1 second: WiFi on/off
- no surprises there, you can do this from Web-GUI too
- (device running normally) Reset button pressed for over 2 seconds: Factory reset
- (device running normally) Reset button pressed for less than 2 seconds: no-operation
- (device running normally) WPS button pressed: on/off
- no surprises there, you can do this from Web-GUI too
- (device running normally) WiFi and WPS buttons pressed: no special functionality, will toggle WiFi and WPS as they would be pressed separately
- (device running normally) WiFi, Reset, WPS buttons pressed: no special functionality
- (device not powered) WiFi button pressed while powering on: baseband (VxWorks) serial console displays Android console briefly and stops
- Linux-side serial console will be completely silent
- (device not powered) WPS button pressed while powering on: no-operation
- (device not powered) Reset button pressed while powering on: no-operation
- (device not powered) WiFi and WPS buttons pressed while powering on: enter bootloader menu
- (device not powered) WiFi, Reset and WPS buttons pressed while powering on: enter bootloader menu
If you have other suggestions about the buttons, please drop me a comment.
Huawei B593 s-22 RS-232 pins
Thursday, March 19. 2015
As I told earlier, I bricked one. It was a loaned one, so I really got burned on that. There was not much to do, but pop the hood of the s-22 and hope to find something interesting there. An interesting thing would be serial console (RS-232) or JTAG.
Here goes:
There are 3 Phillips PH-2 screws holding the unit together. One screw always has a thin paper on top of it. It is a "Huawei-thing". If the paper is broken, it will void your warranty. Remove the 3 screws, and you can pry the box open:
Then the front cover is gone, you have the wrong side of the motherboard in front of you. You need to detach the MoBo from the back cover. There are 4 Phillips PH-2 screws holding it:
Now you're seeing the real thing:
Here is a layout of all the good stuff:
Mr. Asiantuntijakaveri gave me a hint to check couple pins near the CPU for serial signal. I attached an oscilloscope into couple of interesting pins and got following:
Definitely an RS-232 signal. Based on the timings, looks like 115200 bps. Just as in B593 u-12. The only thing was about the voltage. My scope said 1,792 volts peak-to-peak. That's way too low for my 3,3 volt TTL to RS-232 converter. I put in a purchase order for more capable (expensive) adapter and eventually UPS-guy brought it to me:
The one I have is Future Technology Devices International TTL-232RG, TTL-232RG-VREG1V8-WE to be specific. Their spec says: VREG1V8 = USB to UART cable with +5 to +1.8V TTL level UART signals and WE = wire end. A Linux sees it as a Bus 005 Device 004: ID 0403:6001 Future Technology Devices International, Ltd FT232 USB-Serial (UART) IC
. It is fully working after plugging in both on a Linux and Windows 7.
I put this into a PuTTY (115200 N81, no flow control):
And yes, there are results:
onchip NF_boot! UnSec_boo v?l?space?%s start addr:0x%x size:0x%x first step second step thred step DDR exam right !!!!!!!!!!!!!!!!!!!!!!! press space key to enter bootrom: Start from: vxWorks Kernel. >>loading: VxWorks ... success. >>loading: FastBoot ... success. hw main id:00000400, sub id:00000001activate_fastboot...0x3CD00000 Starting from entry: 0x30004000
That's it no more. Not very useful. Then Mr. Asiantuntijakaveri gave me another hint. Try the three-finger-salute, press WiFi, Reset and WPS buttons and then kick on the power. An u-12 will go to some sort of serial-console service mode. And yes, a s-22 does the same. All I have to do is have all three buttons pressed, kick the power on and immediately release all them. Now I have on serial:
first step second step thred step DDR exam right !!!!!!!!!!!!!!!!!!!!!!! press space key to enter bootrom: enter load backup IMAGE_BOOTROM load from:0x00340000>>loading: BootRom ... try inflate. image length: 000A412A ram_inflate_addr: 34F4382E inflating... return value: 00000000 inflate success! data check OK! hw main id:00000400, sub id:00000001Starting from entry: 0x300040Target Name: vxTarget Adding 5472 symbols for standalone. ]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]] ]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]] ]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]] ]]]]]]]]]]] ]]]] ]]]]]]]]]] ]] ]]]] (R) ] ]]]]]]]]] ]]]]]] ]]]]]]]] ]] ]]]] ]] ]]]]]]] ]]]]]]]] ]]]]]] ] ]] ]]]] ]]] ]]]]] ] ]]] ] ]]]] ]]] ]]]]]]]]] ]]]] ]] ]]]] ]] ]]]]] ]]]] ]]] ]] ] ]]] ]] ]]]]] ]]]]]] ]] ]]]]]]] ]]]] ]] ]]]] ]]]]] ] ]]]] ]]]]] ]]]]]]]] ]]]] ]] ]]]] ]]]]]]] ]]]] ]]]]]] ]]]]] ]]]]]] ] ]]]]] ]]]] ]] ]]]] ]]]]]]]] ]]]] ]]]]]]] ]]]]] ] ]]]]]] ] ]]] ]]]] ]] ]]]] ]]]] ]]]] ]]]] ]]]]]]]] ]]]]] ]]] ]]]]]]] ] ]]]]]]] ]]]] ]]]] ]]]] ]]]]] ]]]]]]]]]]]]]]]]]]]]]]]]]]]]]] ]]]]]]]]]]]]]]]]]]]]]]]]]]]]] Development System ]]]]]]]]]]]]]]]]]]]]]]]]]]]] ]]]]]]]]]]]]]]]]]]]]]]]]]]] VxWorks 6.8 ]]]]]]]]]]]]]]]]]]]]]]]]]] KERNEL: WIND version 2.13 ]]]]]]]]]]]]]]]]]]]]]]]]] Copyright Wind River Systems, Inc., 1984-2009 CPU: ARM RealView PBX-A9. Processor #0. Memory Size: 0x4efa000. BSP version 2.0/0. Created: Jun 03 2013, 13:52:34 ED&R Policy Mode: Deployed -> GU base addr: 0x3e200000 HIFI base addr: 0x3f800000 ===== beg mem usr function ===== Hisilicon NANDC_V4.00 initialize... NAND device: Manufacturer ID: 0xad, Chip ID: 0xbc (Hynix NAND 512MiB 1,8V 16-bit) ptable_yaffs_mount: /yaffs0 ...yaffs: Mounting /yaffs0 yaffs: yaffs_GutsInitialise() yaffs: yaffs_GutsInitialise() done. OK. ptable_yaffs_mount: /yaffs1 ...yaffs: Mounting /yaffs1 yaffs: yaffs_GutsInitialise() yaffs: yaffs_GutsInitialise() done. OK. ptable_yaffs_mount: /yaffs2 ...yaffs: Mounting /yaffs2 yaffs: yaffs_GutsInitialise() Collecting block 1136, in use 39, shrink 0, wholeBlock 0 Collecting block 1136, in use 34, shrink 0, wholeBlock 0 Collecting block 1136, in use 29, shrink 0, wholeBlock 0 Collecting block 1136, in use 24, shrink 0, wholeBlock 0 Collecting block 1136, in use 19, shrink 0, wholeBlock 0 Collecting block 1136, in use 14, shrink 0, wholeBlock 0 Collecting block 1136, in use 9, shrink 0, wholeBlock 0 Collecting block 1136, in use 4, shrink 0, wholeBlock 0 yaffs: yaffs_GutsInitialise() done. OK. ptable_yaffs_mount: /yaffs5 ...yaffs: Mounting /yaffs5 yaffs: yaffs_GutsInitialise() yaffs: yaffs_GutsInitialise() done. OK. Collecting block 301, in use 34, shrink 0, wholeBlock 0 Collecting block 301, in use 29, shrink 0, wholeBlock 1 0x34ef9d7c (tRootTask): PMU PWR IRQ1 : 0x0 0x34ef9d7c (tRootTask): PMU PWR IRQ2 : 0x20 0x34ef9d7c (tRootTask): PMU PWR IRQ3 : 0x0 0x34ef9d7c (tRootTask): PMU REG IRQ1 : 0x0 0x34ef9d7c (tRootTask): PMU REG IRQ2 : 0x20 0x34ef9d7c (tRootTask): PMU REG IRQ3 : 0x0 0x34ef9d7c (tRootTask): PMU REG H_N_STATUS(0x43) : 0x0 0x34ef9d7c (tRootTask): PMU REG H_N_STATUS(0x44) : 0x0 0x34ef9d7c (tRootTask): PMU FLAG REG 0x4 : 0x0 0x34ef9d7c (tRootTask): PMU FLAG REG 0x5 : 0x0 0x34ef9d7c (tRootTask): PMU FLAG REG 0x6 : 0x0 0x34ef9d7c (tRootTask): PMU FLAG REG 0x7 : 0x5 0x34ef9d7c (tRootTask): PMU FLAG REG 0x8 : 0x0 0x34ef9d7c (tRootTask): hw main id:0x400, sub id:0x1 0x34ef9d7c (tRootTask): PMU NVM_Read ERROR. 0x34ef9d7c (tRootTask): getFactoryMode:not in factory mode! 0x34ef9d7c (tRootTask): BootRom update_getWebUIUpdateFlag: 0x8B6A7024 0x34ef9d7c (tRootTask): dloadIsDoBackupUpdate: need to do the backup update! 0x34ef9d7c (tRootTask): getBackupBinState: open file failed! 0x34ef9d7c (): task deadexcutePreBackupUpdate: the backup bin is invalid! 0x34ef9d7c (): task deadclearBkupUpdateFlag: succeed to clear the backup update flag! 0x303c32f0 (tUSBTask): BSP_USB_GetDevDescIdx: MDM+PCUI+DIAG in Bootrom image 0x303c32f0 (tUSBTask): Starting USBware stack, Version 3.4.30.21
Oh yes! I was getting somewhere. On an enter I got a prompt and threw in some commands:
[M]->? C interp: syntax error. [M]->help help Print this list dbgHelp Print debugger help info edrHelp Print ED&R help info ioHelp Print I/O utilities help info nfsHelp Print nfs help info netHelp Print network help info rtpHelp Print process help info spyHelp Print task histogrammer help info timexHelp Print execution timer help info h [n] Print (or set) shell history i [task] Summary of tasks' TCBs ti task Complete info on TCB for task sp adr,args... Spawn a task, pri=100, opt=0x19, stk=20000 taskSpawn name,pri,opt,stk,adr,args... Spawn a task tip "dev=device1#tag=tagStr1", "dev=device2#tag=tagStr2", ... Connect to one or multiple serial lines td task Delete a task ts task Suspend a task tr task Resume a task Type to continue, Q or q to stop: tw task Print pending task detailed info w [task] Print pending task info d [adr[,nunits[,width]]] Display memory m adr[,width] Modify memory mRegs [reg[,task]] Modify a task's registers interactively pc [task] Return task's program counter iam "user"[,"passwd"] Set user name and passwd whoami Print user name devs List devices ld [syms[,noAbort][,"name"]] Load stdin, or file, into memory (syms = add symbols to table: -1 = none, 0 = globals, 1 = all) lkup ["substr"] List symbols in system symbol table lkAddr address List symbol table entries near address checkStack [task] List task stack sizes and usage printErrno value Print the name of a status value period secs,adr,args... Spawn task to call function periodically repeat n,adr,args... Spawn task to call function n times (0=forever) version Print VxWorks version info, and boot line shConfig ["config"] Display or set shell configuration variables Type to continue, Q or q to stop: strFree [address] Free strings allocated within the shell (-1=all) NOTE: Arguments specifying 'task' can be either task ID or name. value = 10 = 0xa [M]->
I don't yet know what to do with all that, but ... if I do, I'll tell about it. The part "press space key to enter bootrom
" sounds interesting. I don't know if I can un-brick this thing from VxWorks-side.
So, about the pins. First a ground is needed. Typically it's available almos everywhere. There are couple of easy points to get the ground from, especially in the PSU-area. Of all the easily available GND-pins I chose this one:
The choice was made by a simple logic, it was just an easy one to solder. Then the RS-232 DCE pins at the CPU-unit:
The metallic thing is simply a cover, the actual CPU is under that hood. I did check that one out, but I didn't find anything interesting under that one. Also understand about serial signals, that transmit and receive are from the point of the router (DCE), not from your computer (that would be DTE). You can think of it like this: when DCE transmits (TX), it will go to receive (RX) of a DTE.
If you do your own hacks, know that the power system on a s-22 is weird one. Input is 12 VDC, majority of the Vcc pins have 5 VDC, but I seriously doubt that the system would run on that voltage. If you need it, there is one easily accessible pin with 3,3 VDC:
At the time of writing, the box is still bricked. But this time I have something to work with.
Update 24th Mar 2015:
There is more information available about this subject in this article.
Huawei E5186 (prototype) reviewed
Thursday, March 12. 2015
As I mentioned earlier, a reader of this blog got a Huawei E5186 and I got to test drive it. The model is still in prototype and the semi-official rumour is, that it will be released Q2/2015. As usual, they are not sold directly by Huawei, but by telcos. The one I had was from Germany, T-mobile. The mobile side is pretty much same as in B593s-22, the exact model I had was in fact E5186s-22. Frequencies and modulations are: LTE FDD DD800/900/1800/2100/2600 and TDD 2600. It is very likely, that inside the box is a HiSilicon Android running on a ARM-chip.
It looks exactly like a B593. Here are the pics:
The first things I noticed, that the Tel1 and Tel2 RJ-11 connectors are missing. Also: no USB!! What! I found information from discussion boards, that this particular T-Mobile version is a "poor man's model". There does exist other E5186 models, which have USB and the Tel-connectors.
As a B593 has, there are dual antenna connectors and they are SMA:
For testing this router I didn't need external antennas, the RF-side is much more sensitive than in a B593. In a location where I normally have one bar (without external antenna), this one got three (out of five). Nice!
If you'd want to pop the hood, it opens like B593 does, from the bottom:
All Huawei-hardware has a thin paper on top of one screw. This is to indicate if that screw was removed to void any warranty. I didn't open it, it wasn't my own box.
The web-GUI is completely new:
Everything looked brand new, so had to port-scan the thing:
PORT STATE SERVICE 53/tcp open domain 80/tcp open http MAC Address: 38:F8:89:03:1C:36 (Unknown)
What a surprise! Nothing there. Nothing! No SSH, no FTP, no Samba, no HTTPS. A B593 has plenty of ports open, but this beast is closed as a clam.
A cursory check on the HTML and JavaScript prooved, that entire front was re-written. B593 front has issues on security and functionality, this thing is entirely jQuery / AJAX -based thing. All the requests transfer XML. I was expecting JSON, but hey, it works. I guess there is something on back-end, which runs better on XML.
As the stripped-down hardware suggests, the web-GUI has very little options:
No real surprises there. The only thing, that really caught my eye, was the 5GHz WLAN which B593 doesn't have. There must be some new electronics inside.
This is the device information screen:
As it happened, also Finnish magazine happened to review the E5186. I don't have a permission for reprint, but here is a small glimpse what they said:
As a conclusion, the mag loved the box. I don't know which version they had, but this one without USB I don't especially love. It's too pricey without the port. Under the hood, the AJAX-API has a ton of features not available via your web browser. I'll get back to that subject later.
ZTE MF910 Wireless Router reviewed
Sunday, March 1. 2015
I had a chance to setup a modern 4G/3G/2G router. Of course I took pics and share the details here!
This is what a ZTE MF910 looks like:
Pretty much the first thing that comes to my mind is: "It's a cell phone!" Yes, indeed. It is. It is an Android phone. My guess is, it is 99% of a cell phone when compared to an Android in your pocket. It is small, it has an USB-charger, runs hours from a battery. It is shiny (pretty difficult to get decent pictures of it). It has a display (no touching or anything expensive). And it costs 99,- €. There is very little differentiating it, except that it doesn't have a speaker and a microphone. I didn't pop the hood of it (that thing isn't mine, I was just helping to set it up), but I'm thinking it has all the chips and electronics a phone would have.
Screen will indicate connection type (2G/3G/4G), bars, Internet status (ok, both arrows up and down), Wi-Fi enabled, how many clients are connected to the Wi-Fi, battery charge level, operator name, cumulative time connected and the cumulative transmitted bytes.
On the back there are out-of-the-box defaults and mandatory IMEI-information. The TAC-code for this one is 86415402 and I couldn't find it from any TAC databases. Must be quite a new one. What I didn't find is how to replace the battery. I guess you cannot, it is like a cell phone. It doesn't feel hot or anything when running, looks like the electronics design is also modern. It puts all the electrons where you'd expect them to go, not to dissipate heat.
Here is a clear difference to a phone:
There are two antenna connectors (TS9) on the sides. As all LTE equipment always has 2 antennas (your phone does, you just won't see them), there needs to be connectors for both of them. The intended purpose for this is to convert cellular connection into Wi-Fi. As sometimes the cell network connection is poor, adding a proper antenna (or two) can make a difference. Power button has one extra feature including the obvious one. If you press it shortly, it will display the default WLAN SSID and password on the screen. Funny thing: if you change them, the screen won't display the new ones. On the as-expected, there is a mini-SIM -slot and mini-A USB for the charger.
The antenna connector is a quirky one:
I couldn't find anything to connect to it. Any typical small appliance (like Huawei USB-sticks) have CRC9-connector, or the bigger routers (like Huawei B593) have SMA-connectors. I guess the new TS9 is suiting better for some reason.
When the SIM-card in inserted, power button pressed and box is up and running, it connects automatically to internet. It distributes an IP-address to any client devices and enables the management web-console. It looks like this:
There is a decent selection of langauges for the GUI:
And the top right corner status indicator is good one:
It provides a lot of information without need to login. This is what it looks like once in:
There is no need to look for Wi-Fi settings. They are right there after a login. In general I really love their approach, lot of useful features and really well thought web-GUI implemented. Also the existence of 5 GHz WLAN tells about a modern design. A while ago only 2,4 GHz existed in routers such as this.
The Internet connection details are:
APN I didn't touch, it just worked. Network mode (2G/3G/4G) may be necessary if reception has issues. The most important thing is, that this box has a built-in freq lock in it. No need of hacking or any quirks. This is by far the most commonly asked question nowadays, how do you lock B593 into a frequency. With this el-cheapo box, setting is right there! Nice.
I also love the status screens:
Lot of relevant information right at your screen! This is exactly what everybody else should be doing. Unfortunately the network status screen is optimized heavily for LTE-connections and on UMTS it won't tell much.
As a conclusion I have to recommend this cheaply built piece of plastic for any router needs. It certainly is worth the money and has just the right features in it. The only thing that worries me is the constant charging: will it survive future years? I don't care if the thing wouldn't run from the battery, but will the charger alone be enough to run it?
First B593 s-22 exploit: Setup FTP to get /var/sshusers.cfg
Monday, February 23. 2015
I have a new version of B593_exploit.pl published. See this article about previous info.
This version has s-22 FTP hack added to it. u-12 has the classic FTP USB-share flaw where it is possible to create a FTP share of the /. Unfortunately in this box Huawei guys made the web GUI a bit smarter, you cannot do such a nice share anymore. The fortunate part is, that the guys don't check for that at the save. If you manage to lure the ../.. past the GUI, you can do it. That's what the exploit is about.
Example run:
./B593_exploit.pl 192.168.1.1 admin --ftp-setup \ ftpuser ftppassword
That command will share the first USB-device found at the filesystem root of the box. You have to have a physical USB-storage attached. It doesn't have to have anything on it and it won't be affected during the process. But setting a path will fail, if there is no USB-storage.
I had problems with the FTP-client, it kept complaining about FTP passive mode. I switched the client into NcFTP and that solved my problem.
When in the box the SSH passwords are at the classic /var/sshusers.cfg
. If configuration is of interest to you, it can be found from /app/curcfg.xml
. When the admin user's password is known, it is only a trivial task to SSH into the box and gain a shell access.
While looking around the box, I got carried away with the lteat
-command. I managed to brick the box. But that's an another story.)
New features to curcfg_tool [Failure]
Sunday, October 19. 2014
The original post about curcfg_tool.
So I decided to add couple of new features to my tool. However, neither of of them work.
Asiantuntijakaveri-blog introduced hack to run commands on boot: Persistent customizations to Huawei B593u with stock firmware. I added a feature to do that:
./curcfg_tool -rc "update-westerneurope.huaweidevice.com ; /upgflash/init.d/rc.local" -w
The flaw is in the httpupg-command startup. It takes the server address from curcfg.xml, but it doesn't escape it properly. This makes it possible to piggy-back any command on it. The thing is, that in my B593, the automatic firmware upgrade does not run automatically. I can go trigger it manually. At that point it runs my script I created at /upgflash/init.d/rc.local. My hope was, that system would run it automatically on bootup, but it doesn't.
Another thing I added was NTP-server change. I don't know where the list comes from, in my case it is completely ridiculous. However, the source for information is not from curcfg.xml. For example:
./curcfg_tool -ntp1 ntp.dnainternet.fi -ntp2 fi.pool.ntp.org -w
... doesn't change anything. The new servers don't appear at the list in GUI, nor the system doesn't update time from them.
Crap! Both attempts failed miserably. Please drop me a comment if you have anything to add to those ones.
Introducing curcfg_tool: Utility to make changes to your configuration
Tuesday, September 16. 2014
As I have promised a number of times to number of people. Here it finally is! The first version of my tool to alter your B593 configuration. With this tool you can change admin passwords for web GUI and SSH to something of your liking. It does not (yet) convert plaintext passwords into encrypted ones, but it successfully writes the changes to flash, thus making them permanent.
Prerequisites
- Huawei B593 u-12
- Access to your box for running commands, telnet/SSH are really good options for this
- While at Busybox sh prompt, internet connectivity via the mobile interface (4G/3G/2G)
Getting the tool
The MIPS32 binary version suitable for running at your B593 is at http://opensource.hqcodeshop.com/Huawei%20B593/curcfg/latest. The C source code is also available at: http://opensource.hqcodeshop.com/Huawei%20B593/curcfg/
- Log into your box
- (recommended) Change into directory /upgflash/
- Download the binary into your box:
wget -g -v -l curcfg_tool -r "/Huawei%20B593/curcfg/latest" opensource.hqcodeshop.com - As you can see, Busybox has a mighty quirky wget!
- Anyway, that command will download the tool from the above URL and place it to the current directory with local name curcfg_tool.
- Also note, that your box must have a functioning Internet access for download. The only other viable option is via FTP-hack. The environment is very limited and file transfers are restricted heavily.
- Make sure, that the file is executable:
chmod a+x curcfg_tool
Running the tool
Now that you have the thing sitting there, run it:
# ./curcfg_tool
Usage:
-V - Print version information
-cw <base64 encoded web gui password> - set password
-cs <base64 encoded SSH password> - set password
-w - write changes to flash (default: don't write)
-fi <file name> - input file (default: read from flash)
-fo <file name> - write changes (default: /tmp/flashinfo.bin)
An example of resetting the web-GUI password would be:
# ./curcfg_tool -cw f5338SA1kb4= -w
Read data: addr = 0xe00000, len = 0x4 ...
Begin write to file
Export done
Reading 25785 bytes of config
Read data: addr = 0xe00000, len = 0x64bd ...
Begin write to file
Export done
Writing 25785 bytes of config
/tmp/flashinfo.bin size = 25790 Bytes
Read file done
Begin write to flash
Load file done
The magicical Base64 encoded 3-DES encrypted string f5338SA1kb4= is "admin" in plain text. After a reboot (just say reboot at prompt), you can login into your web-GUI and change the password into something of your liking.
What next?
That's pretty much it as of now. If you don't like your operator designated passwords, you can change them.
How do I ...
- ... see what my current password is:
You cannot. Encryption key is not known for pre-SP100 firmware and SP100+ firmware is using double encryption with 3-DES and AES and entire flow of information is not yet known. - ... access the prompt of my box:
See B593_exploit.pl for details. - ... access the prompt of my box, but I have SP100+ firmware and don't know any of my passwords:
You cannot. Yet. Currently known exploits have been fixed preventing access.
However, in this case the real question seems to be: "How did you get your box running in the first place?" - ... run the B593_exploit.pl -tool, my Perl isn't working:
You may want to install all CPAN-modules the script requires. Also skip the Windows and use a proper computer.
u-12 pre-SP100 exploits in a single tool
Monday, September 15. 2014
I created a new tool to obsolete the classic B593cmd.pl ping-exploit tool. I wrote that one almost a year ago to run any commands on your B593. That could be used to lift IPtables restrictions or get your sshusers.cfg contents.
Now that Mr. Ronkainen found out that pre-SP100 firmwares have another flaw, which is much more simpler to exploit, I wrote a tool to combine both of them into a single package.
Neither one of these work in SP100+ firmwares, but not to worry! They have SSH-port open for full access anyway. So ... getting a SP100+ firmware into your box should be your target anyway. This tool can help you gain access to your box.
The B593_exploit.pl tool is at http://opensource.hqcodeshop.com/Huawei%20B593/exploit/latest.pl. In the top of the file there is a list of Perl-modules it requires to run. You will get the complaints, if any are missing. Usage:
./B593_exploit.pl --help
Usage: B593_exploit.pl
--help|-h This help
--run-cmd Run a command: pre SP-100 ping-exploit
to run any command via web-console
--telnet-login Login via telnet: lift IPtables firewall from telnet and login
Ping-exploit -mode
This is the classic. Run example:
./B593_exploit.pl --run-cmd 192.168.1.1 admin "iptables -nL INPUT"
There are couple of bugs fixed, it should be more robust and has --debug -mode in it.
Telnet-exploit -mode
This is the newer one. Run example:
./B593_exploit.pl --telnet-login 192.168.1.1
Attempt 1 telnetting to 192.168.1.1
BusyBox vv1.9.1 (2012-03-01 14:00:34 CST) built-in shell (ash)
Enter 'help' for a list of built-in commands.
# iptables -nL INPUT
Ok. It's not a full telnet-client like you'd a regular telnet to be. This emulates one with Perl's Term::Readline, so your vi won't work or tab-based command-line completion. However, it has enough power in it to allow you to run commands and display contents of the files or fiddle with your IPtables.
In my next post I'm about to release a tool for editing and storing values of your curcfg.xml. This is a prerequisite, getting to the prompt and running stuff on the prompt is a must-have.
Network appliance and hard-coded passwords
Tuesday, August 26. 2014
Trend Micro reported that they found a backdoor from Netis/Netcore firmware. It is a quite serious one allowing remote code execution from the Internet side. Sure, the backdoor is "protected" by a password. As you may expect, the password is hard-coded, cannot be changed and is exactly same in each unit. Nice "security", huh!
Why doesn't this surprise me? Mr. Ronkainen, who is a really keen B593 hacker did find the Huawei internal documentation (available from the entire Internet, of course) Log_Capturing_Guide_of_LTE_CPE_B593_V1.2.docx. It describes following "Step 5 Enter admin after Login and press Enter. Then enter the password -removed- and press Enter". Actually, according to Mr. Ronkainen, the same password is the hard-coded password of serial-console. In reality, some soldering is required for serial console to work, but if you do ... there goes your security.
All B593 hacking always reveals hard-coded encryption keys and passwords. My conclusion: that poor security in these produced-as-cheaply-as-possible devices is by design, and it cannot be changed. Not too many samples in my "research", though. I don't mind having fixed default passwords, you can go and change them. These Chinese units, have fixed passwords, which is yet another story.
Again, I thank Mr. Ronkainen for sharing his findings. Even website https://www.sec-consult.com/ crredits him for his findings in SEC Consult Vulnerability Lab Security Advisory < 20140122-0 >.
B593 u-12 /etc/ PEM-files explained
Monday, August 18. 2014
During the quest of hacking my u-12, Mr. Ronkainen from blog.asiantuntijakaveri.fi insisted, that the certificate files in /etc/ are actually used. My personal belief was, that the purpose of having those would be something not-so-important. It turned out, that I badly misjudged the situation.
My firmware has these files:
# cd /etc/
# ls -l *pem
-rwxrwxrwx 1 0 0 963 privkey.pem
-rwxrwxrwx 1 0 0 963 privkey.b593pem
-rwxrwxrwx 1 0 0 3700 cachain.pem
-rwxrwxrwx 1 0 0 1751 b593cpekey.pem
Please note, that the files are in a Read-Only -partition. They are not unique to my device! Your u-12 should have the exactly same files like I do. Also note, that pre-SP100 firmwares are using different encryptions and may not have those (I didn't bother to check).
The cachain.pem is the trivial one. It contains two CA-certificates issued by Huawei expiring 2040 or so. That is a very common PKI-procedure to have the public certificates in a device to make sure, that the actual certificate being used can be verified to a trusted root-CA. There is very little interesting about that file.
However, the remaining PEM-files are more interesting. The exact purpose of b593cpekey.pem is yet unknown. It is an 3-DES encrypted private key to something. If you want to take a peek into the file, the encryption password is CPE-B593-12 as Mr. Ronkainen dug out of the libraries. A command like this will tell us more:
# openssl rsa -in b593cpekey.pem -noout -text -passin pass:CPE-B593-12
Private-Key: (2048 bit)
...
It is a 2048-bit RSA key. If you know what the key is used for, please tell us.
The remaining files privkey.pem and privkey.b593pem are exactly the same. To me it looks like poor engineering. Libraries seem to be using the latter filename, but my guess is, that somebody is using the first one too. The password for this private key was also recovered by Mr. Ronkainen, it is lteb593. Basic information recovery:
# openssl rsa -in privkey.pem -noout -text -passin pass:lteb593
Private-Key: (1024 bit)
...
Hm. handy, but the really interesting part is where this file is actually used. This information was recovered by Mr. Ronkainen with looking at the GUI admin traffic via Wireshark.
If you go change the admin password at System -> Password change (the frame source would be http://-the-IP-here-/html/management/account.asp), you can see the HTML containing tags for loading a number of JavaScript files, the most interesting ones are /js/account.js and /js/rsa.js. The actual password change code from account.js is:
function AddSubmitParam(SubmitForm,type)
{
var cfgUsername = ADMIN_USER_NAME;
SubmitForm.addParameter('cfgUsername',cfgUsername);
SubmitForm.addParameter('Userpassword',MyRSAEncryptB64(getValue('id_cfmPassword')));
//SubmitForm.addParameter('Username',ADMIN_USER_NAME);
SubmitForm.addParameter('OldPassword',MyRSAEncryptB64(getValue('id_oldPassword')));
SubmitForm.setAction('chgacount.cgi?RequestFile=/html/management/account.asp');
It RSA-encrypts the value from form field with id id_cfmPassword! Wow! They really beefed up their security. The RSA-code is at /js/rsa.js and it contains:
// Return the PKCS#1 RSA encryption of "text" as a Base64-encoded string
function RSAEncryptB64(text) {
var h = this.encrypt(text);
if(h) return hex2b64(h); else return null;
}
...//my encrypt function, using fixed mudulus
var modulus = "BEB90F8AF5D8A7C7DA8CA74AC43E1EE8A48E6860C0D46A5D690BEA082E3A74E1"
+"571F2C58E94EE339862A49A811A31BB4A48F41B3BCDFD054C3443BB610B5418B"
+"3CBAFAE7936E1BE2AFD2E0DF865A6E59C2B8DF1E8D5702567D0A9650CB07A43D"
+"E39020969DF0997FCA587D9A8AE4627CF18477EC06765DF3AA8FB459DD4C9AF3";
var publicExponent = "10001";
function MyRSAEncryptB64(text)
{
var rsa = new RSAKey();
rsa.setPublic(modulus, publicExponent);
return rsa.encrypt_b64(text);
}
It surely is RSA PKCS#1 encryption implemented with JavaScript. That's really cool! A complete PKCS#1 library implemented with a completely wrong language. I didn't realize, that having a fully functional RSA-library with JavaScript was even possible, but there it is.
Next I took the public key modulo and exponent from the above JavaScript-code and used Per Olesen's tool from https://gist.github.com/polesen/2855098 to re-create an actual PEM-file from those ingredients. Mr. Olesen has a nice article Converting RSA public key Modulus and Exponent into PEM file about that.
The resulting PEM-file is:
-----BEGIN PUBLIC KEY-----
MIGeMA0GCSqGSIb3DQEBAQUAA4GMADCBiAKBgQC+uQ+K9dinx9qMp0rEPh7opI5o
YMDUal1pC+oILjp04VcfLFjpTuM5hipJqBGjG7Skj0GzvN/QVMNEO7YQtUGLPLr6
55NuG+Kv0uDfhlpuWcK43x6NVwJWfQqWUMsHpD3jkCCWnfCZf8pYfZqK5GJ88YR3
7AZ2XfOqj7RZ3Uya8wICJxE=
-----END PUBLIC KEY-----
and a simple verify run with OpenSSL for both the private and public keys confirm, that we have a pair:
# openssl rsa -pubin -in privkey.pub.pem -noout -modulus | md5sum
92e88d0b38fe93cd41a000b3c0b1928e -
# openssl rsa -in privkey.pem -noout -modulus -passin pass:lteb593 | md5sum
92e88d0b38fe93cd41a000b3c0b1928e -
Both keys have the same modulo in them, thus, they are the private and public parts of the same key. Excellent!
Credits go (as usual) to Mr. Ronkainen for his hard work in hacking the B593. Also Mr. Olesen deserves thanks for his ready-made tool (which btw. builds in my Linux easily) for putting the PEM-parts back together.
Final credits go to Huawei engineers, this time they took data encryption really seriously. However, when you're in a leaking boat, it really doesn't matter if you have the best motor or not, your boat still leaks. In this case the critical information (like encryption keys) are hard-coded, used in every device they manufacture and recoverable in plain-text format. It looks like Huawei is suffering from the weakest-link-in-your-security -syndrom. If your FTP is flakey, you store your SSH-passwords in plain-text format and let people in as they please, they are likely to find this stuff out!
... More to follow about SSH and web-GUI user password encryption. This was a very critical find in the path of full disclosure.
Password encryption
Sunday, August 17. 2014
A fellow B593 hacker Mr. Ronkainen from blog.asiantuntijakaveri.fi informed me about his findings regarding /var/curcfg.xml password encryption. This is something I did already spit-ball with him in comments, but this time he had something concrete to show.
This is for decrypting an FTP-password. Since you can set your own, you definitely know what the plaintext password is. His findings are:
exe->Data_DbDecrypt(nil, "llxYjYnY:\021\003\2324\275\241\233Wu\353$Vx;\333#", "", "" <unfinished ...>
exe->strncpy(0x7facddd8, "llxYjYnY", 8) = 0x7facddd8 (Data_DbDecrypt)
exe->strcpy(0x7facdaf8, "12345678") = 0x7facdaf8 (Data_getProductInfo)
exe->strncpy(0x7facdb01, "12345678", 9) = 0x7facdb01 (Data_getKey)
exe->strncat("12345678", "llxYjYnY") = "12345678llxYjYnY" (Data_getKey)
<... Data_DbDecrypt resumed> ) = nil
exe->strcpy(0x4ce009, "BBBB") = 0x4ce009
The first call is for the raw input data. It clearly contains 8 characters, a colon (:) and something encrypted after it. Then there is a surprising part, call to a function named Data_getProductInfo() returning hard-coded 12345678 every time. Based on the code, the "product info" is simply concatenated into the Base64-decoded 8 char prefix, forming a 16 byte encryption key.
I've already speculated, that they changed encryption in SP100+ from 3-DES to AES. Based on the function names in firmware libries, combine that with knowledge of block ciphers and give it a go with AES-128 ECB with the above keying. Hey presto! It works!
I wrote a public tool for doing password encryptions/decryptions: http://blog.hqcodeshop.fi/B593/password_recover.php The sources for my web-thing are also there, if you want to use that by yourself.
As you can see from the form, I cannot work with the previous 3-DES stuff. It's simply because I don't know what the key/IV are. There is also another thing with web-GUI and SSH-passwords. They are not using the above keying mechanism. My speculation is, that they are using AES-256 (possibly in ECB-mode) for those, but I have no details about the key.
If you want to test the password recovery, you'll need your /var/curcfg.xml at hand. Pick an encrypted password from that, for example:
<X_FTPServiceInstance InstanceID="1" Username="test" Password="bU50RkQ1T2o6UNkuA7Bdj40/TiNehA6fDw==" FtpUserEnable="1" Privilege="2" Path="usb2_1/../.."/>
or
<WEPKeyInstance InstanceID="4" WEPKey="bU50RkQ1T2o69goRBo2nWOh00YDVCHLGDw=="/>
Select web-form Target as FTP-user, copy/paste the value from XML Password-field into Base64-encoded and klick decrypt. It should give you "test" as Plain-text value. There is another example for Wi-Fi WPA-key, it says WEP in the XML-file, but we can ignore that.
I'll keep investigating the other passwords too. Mr. Ronkainen suggested, that something in the box could be encrypted with PKCS#1, but the block size is off, at least in passwords. Stay tuned for more updates.
Huawei B593 u-12 firmware spreadsheet
Tuesday, July 15. 2014
Since there has been no updates for Mr. Bjørn Grønli's spreadsheet, I chose to continue his work.
The link is https://docs.google.com/a/hqcodeshop.fi/spreadsheets/d/1ZJsy0q-8tmR8m32d1bCHkSv1neGVtA5v5TU4qVczH0Q
I did try out a number of SP104 and SP105 T-mobile (German Telecom) firmwares and found that they are really poor. 3 Italy was a pretty poor firmware, as I had problems logging in! Polkomtel's SP103 was a solid performer, but after a round trip, I went back to Telia's SP102.
Please drop me a comment if something is wrong or new columns should be added, or if I'm missing a firmware in the list. My idea is to try to keep this up to date with firmware information and I will appreciate any help from you.
US travel pics: San Francisco
Saturday, June 28. 2014
Not much has happened here on the blog as I have been busy doing some training and planning abroad.
As the saying goes, "pics or it didn't happen!". Here are the pics:
My hotel is in Nob Hill, but for work I go to SoMa. I didn't have a chance to go to Alcatraz, as the queue is something in the region of 3 months, but I managed to take a nice picture of it from Russian Hill. I don't have the classic Golden Gate picture yet, as it would require renting a car. On the other hand, the Bay Bridge is easily visible throughout the city, including Washington Street where I took the picture of Cable Car Museum. The Also, we had a nice evening get-together and went to see Giants vs. Reds baseball game at AT&T Park. Giants lost 1-3.
Once I get back to home, I'll continue hacking the B593.
Update 2nd July:
I got back home and here are some more pics:
There are the classic Golden Gate pics you'd expect from anybody who visited San Francisco.
During the last day I had time to do a little pilgrimage:
University of California, Berkeley is the place where BSD Unix was initially written from AT&T's Unix. Nowadays that code runs among other OS X and iOS and most TCP/IP implementations, like the one in your Windows. So, it is a mighty important place. Second pic is a composite from Apple HQ's Apple Store. Every programmer will get the "infinite loop" joke. Since Infinite Loop is a looping street, you can actually take as many loops you want (until security throws you out). Third one is a composite from Google's HQ. There are number of Google bikes for employees to use (not that there wasn't security present when I drove one, typically there are). The last one is from YouTube HQ. It was surprising that it still has an own place and is not embedded into Google Campus.
Btw. In general the pics are of somewhat poor quality. I took them with my iPhone 4S. I didn't want to take my DSLR to a business trip.