Reversing Huawei router firmware, part 5

Juan Carlos has a written part 5 of his series of firmware reversing posts!


I think I missed part 4!



Reversing Huawei routers, part 3

In part 2, Juan Carlos was interacting with the CLI in U-Boot. What will happen in episode 3? Spoiler alert: there is an episode 4 planned!

Practical Reverse Engineering Part 3 – Following the Data
Part 1: We found a door into the firmware in the form of a UART debug port
Part 2: We took a first look at the firmware, collected all sorts of data

The best thing about hardware hacking is having full access to very bare metal, and all the electrical signals that make the system work. With ingenuity and access to the right equipment we should be able to obtain any data we want. From simply sniffing traffic with a cheap logic analyser to using thousands of dollars worth of equipment to obtain private keys by measuring the power consumed by the device with enough precission (power analysis side channel attack); if the physics make sense, it’s likely to work given the right circumstances. In this post I’d like to discuss traffic sniffing and how we can use it to gather intel. Traffic sniffing at a practical level is used all the time for all sorts of purposes, from regular debugging during the delopment process to reversing the interface of gaming controllers, etc. It’s definitely worth a post of its own, even though this device can be reversed without it. […]






Reversing Huawei router part 2: U-Boot’s CLI

Juan Carlos Jiménez has written the 2nd part of his series on reversing a Huawei router! The first part was excellent, this one is just as good.

Practical Reverse Engineering Part 2 – Scouting the Firmware

In part 1 we found a debug UART port that gave us access to a linux shell. At this point we’ve got the same access to the router that a developer would use to debug issues, control the system, etc. This first overview of the system is easy to access, doesn’t require expensive tools and will often yield very interesting results. If you want to do some hardware hacking but don’t have the time to get your hands too dirty, this is often the point where you stop digging into the hardware and start working on the higher level interfaces: network vulnerabilities, ISP configuration protocols, etc. […]

Part 2:

Part 1:


AArch64 Xen gets Dom0 ACPI support

Shannon Zhao of Huawei submitted a 17-part patch to the Linux-ARM-kernel, Linux-EFI, Linux-Kernel, and Xen-devel lists, which adds ACPI support for Xen Dom0 on AArch64 systems.

This patch set adds ACPI support for Xen Dom0 on ARM64. The relevant Xen ACPI on ARM64 design document could be found from [1]. The corresponding Xen patches can be fetched from [2].

  Xen: ACPI: Hide UART used by Xen
  xen/grant-table: Move xlated_setup_gnttab_pages to common place
  Xen: xlate: Use page_to_xen_pfn instead of page_to_pfn
  arm/xen: Use xen_xlate_map_ballooned_pages to setup grant table
  xen: memory : Add new XENMAPSPACE type XENMAPSPACE_dev_mmio
  Xen: ARM: Add support for mapping platform device mmio
  Xen: ARM: Add support for mapping AMBA device mmio
  Xen: public/hvm: sync changes of HVM_PARAM_CALLBACK_VIA ABI from Xen
  xen/hvm/params: Add a new delivery type for event-channel in HVM_PARAM_CALLBACK_IRQ
  arm/xen: Get event-channel irq through HVM_PARAM when booting with ACPI
  ARM: XEN: Move xen_early_init() before efi_init()
  ARM64: ACPI: Check if it runs on Xen to enable or disable ACPI
  ARM: Xen: Document UEFI support on Xen ARM virtual platforms
  XEN: EFI: Move x86 specific codes to architecture directory
  ARM64: XEN: Add a function to initialize Xen specific UEFI runtime services
  FDT: Add a helper to get specified name subnode
  Xen: EFI: Parse DT parameters for Xen specific UEFI

[1] http://lists.xen.org/archives/html/xen-devel/2015-11/msg00488.html
[2] http://git.linaro.org/people/shannon.zhao/xen.git  ACPI_XEN_ARM_V3


Huawei 3G routers

Multiple news sites are pointing to a blog bost by Pierre Kim, on Huawei 3G router security:

A comprehensive study of Huawei 3G routers – XSS, CSRF, DoS, unauthenticated firmware update, RCE

Huawei Technologies Co. Ltd. is a Chinese multinational networking and telecommunications equipment and services company. It is the largest telecommunications equipment manufacturer in the world. The Huawei B260A device is a 3g modem / access point overall badly designed with a lot of vulnerabilities. The device is provided by Orange Tunisia as a “Flybox”. It’s available in a lot of countries to provide Internet with a 3G network (Vodafone provides this device, for example). The tests below are done using the last available firmware (firmware 846. – Feb 20 2013). Note: This firmware seems to be used for these 14 Huawei devices (from ) which, therefore, are likely to be vulnerable to the same threats: ]…]



CVE-2015-5367: HP Gobi 4G firmware vulnerability

I missed this CVE the first time around, only noticed it with recent mainstream news reports. 😦

Quoting the Debian page:

The HP lt4112 LTE/HSPA+ Gobi 4G module with firmware before 12.500.00.15.1803 on EliteBook, ElitePad, Elite, ProBook, Spectre, ZBook, and mt41 Thin Client devices allows local users to gain privileges via unspecified vectors.

Huawei is also listed with this CVE, so perhaps other vendors besides HP are impacted?

More Information: