Hitron CGNM-2250 - Revision history

Leo: /* ARM/NP CPU Command-line shell access */

2023-12-21T21:53:39Z

ARM/NP CPU Command-line shell access

← Older revision		Revision as of 21:53, 21 December 2023
Line 1,919:		Line 1,919:

	=== ARM/NP CPU Command-line shell access ===		=== ARM/NP CPU Command-line shell access ===
	Decompiling the CLI shell shows that the password to run the 'shell' command is indeed <code>D0nt4g3tme!</code>~~. The password, however, doesn't work~~.		Decompiling the CLI shell shows that the password to run the 'shell' command is indeed <code>D0nt4g3tme!</code>.
	{{Highlight		{{Highlight
	\| code = bool CLI_CheckProdPasswd(void)		\| code = bool CLI_CheckProdPasswd(void)
Line 1,939:		Line 1,939:
	}		}
	\| lang = C		\| lang = C
	}}Changing <code>/etc/passwd</code> so telnet uses <code>/bin/sh</code> is the workaround.		}}The password, however, doesn't work.
			{{Highlight
			\| code = Console, CLI version 1.0.0.5
			Type 'help' for list of commands

			mainMenu> shell
			Password:D0nt4g3tme!
			Wrong password!
			mainMenu>
			\| lang = text
			}}
			Changing <code>/etc/passwd</code> so telnet uses <code>/bin/sh</code> is the workaround.

	==== Web UI settings backup and restore ====		==== Web UI settings backup and restore ====

Leo: /* Final thoughts */

2023-12-21T21:50:22Z

Final thoughts

@@ Line 1,910: / Line 1,910: @@
 * On the Intel side, just run <code>telnetd</code> to start telnet.
 * On both sides, IPTables is executed with <code>xtables-multi iptables</code>. Eg. <code>xtables-multi iptables -L -n</code>.
-* Adjust the default policy for INPUT to accept to make life easier: <code>xtables-multi iptables -P INPUT ACCEPT</code>.
+* Adjust the default policy for INPUT to accept to make life easier: <code>xtables-multi iptables -P INPUT ACCEPT</code>. This only applies to the ARM side. There doesn't appear to be a firewall on the Intel/APP CPU side.
 * ARM's processor is in big endian. You have to cross-compile armv7-be.
 * You kinda have to run the DOCSIS services. Otherwise, nothing seems to come up.
@@ Line 1,918: / Line 1,918: @@
 * Dropbear supports only RSA with DH-SHA1. So you'll have to SSH using this command: <code>ssh -o KexAlgorithms=+diffie-hellman-group1-sha1 -o HostkeyAlgorithms=ssh-rsa cusadmin@192.168.0.254</code>
-==== CLI shell? ====
+=== ARM/NP CPU Command-line shell access ===
 Decompiling the CLI shell shows that the password to run the 'shell' command is indeed <code>D0nt4g3tme!</code>. The password, however, doesn't work.
 {{Highlight
@@ Line 1,940: / Line 1,940: @@
 | lang = C
 }}Changing <code>/etc/passwd</code> so telnet uses <code>/bin/sh</code> is the workaround.
 == Final thoughts ==
@@ Line 1,950: / Line 2,026: @@
 == See also ==
-* Encode/Decode firmware config file - https://raw.githubusercontent.com/habohitron/habohitron/6add0d002fe553f0924a3bba197994c53ca7d52d/firmwares/3.1.1.21/analyse/hc.c
+* Encode/Decode firmware config file - https://raw.githubusercontent.com/habohitron/habohitron/master/firmwares/3.1.1.21/analyse/hc.c
 * Hacking with an old RCE exploit - https://geekness.eu/content/remote-code-execution-hitron-cgnm-2250-part-1
 *Hardware info - https://wikidevi.wi-cat.ru/Hitron_CGNM
 *Process Control Daemon (PCD) - https://meetrp.github.io/pcd/script.html

Leo: /* Getting root access on both subsystems in normal boot mode */

2023-12-21T21:34:38Z

Getting root access on both subsystems in normal boot mode

← Older revision		Revision as of 21:34, 21 December 2023
Line 10:		Line 10:
	There are two distinct subsystems, each using a different CPU architecture on this modem and communicate with each other using RPC over a built-in network bridge:		There are two distinct subsystems, each using a different CPU architecture on this modem and communicate with each other using RPC over a built-in network bridge:

	# The Intel Atom CPU which the firmware files refer to as '~~APPCPU~~' and is responsible for services like Samba and handling of the USB ports. It is also the CPU that boots up the system when the system is powered on. The CPU appears to read the first 2MB of the flash storage when powered on as that's where the ~~BIOS related~~ data is stored.		# The Intel Atom CPU which the firmware files refer to as 'APP CPU' and is responsible for services like Samba and handling of the USB ports. It is also the CPU that boots up the system when the system is powered on. The CPU appears to read the first 2MB of the flash storage when powered on as that's where u-boot and the first/second stage boot data is stored.
	# The ARM CPU which is referred to as the 'NP CPU' which is responsible for network related services including the web UI interface, SNMP, DOCSIS related services, and the network CLI program. This CPU is disabled (or made to not boot) if the system is powered on with the front button pressed. The processor boots using u-boot stored on partitions 7 and 8 of the flash storage. Whenever this ARM/NP CPU side is rebooted, the Intel/APP CPU side also reboots. Interestingly, rebooting the Intel/APP CPU side does not affect the ARM/NP CPU side.		# The ARM CPU which is referred to as the 'NP CPU' which is responsible for network related services including the web UI interface, SNMP, DOCSIS related services, and the network CLI program. This CPU is disabled (or made to not boot) if the system is powered on with the front button pressed. The processor boots using u-boot stored on partitions 7 and 8 of the flash storage. Whenever this ARM/NP CPU side is rebooted, the Intel/APP CPU side also reboots. Interestingly, rebooting the Intel/APP CPU side does not affect the ARM/NP CPU side.

Line 461:		Line 461:

	=== Intel / APPCPU side ===		=== Intel / APPCPU side ===
			Running kernel: <code>Linux version 2.6.39 (root@US1-Yocto) (gcc version 4.5.1 (IntelCE toolchain-V5 Tue Apr 17 19:34:48 PDT 2012) ) #2 SMP PREEMPT Thu Nov 18 01:35:16 EST 2021</code>

	Here are some logs from the Intel side of things.		Here are some logs from the Intel side of things.

Line 1,914:		Line 1,916:
	* You can leverage the PCD service manager to run your customized startup script.		* You can leverage the PCD service manager to run your customized startup script.
	* You have to start a watchdog daemon on the ARM side or else the system reboots (which also reboots the Intel side)		* You have to start a watchdog daemon on the ARM side or else the system reboots (which also reboots the Intel side)
			* Dropbear supports only RSA with DH-SHA1. So you'll have to SSH using this command: <code>ssh -o KexAlgorithms=+diffie-hellman-group1-sha1 -o HostkeyAlgorithms=ssh-rsa cusadmin@192.168.0.254</code>

	==== CLI shell? ====		==== CLI shell? ====

Leo: /* Final thoughts */

2023-12-21T21:27:45Z

Final thoughts

← Older revision		Revision as of 21:27, 21 December 2023
Line 3:		Line 3:
	This modem is based on Intel's Puma 6 modem chipset with a somewhat notorious reputation of having high network jitter and latency. While I didn't really notice any issues with this modem with day-to-day tasks, I did notice a significant reduction in network jitter with ICMP pings after replacing the modem.		This modem is based on Intel's Puma 6 modem chipset with a somewhat notorious reputation of having high network jitter and latency. While I didn't really notice any issues with this modem with day-to-day tasks, I did notice a significant reduction in network jitter with ICMP pings after replacing the modem.

	Instead of throwing it out, I'd like to see whether it can be turned into something useful. ~~This page will cover things worthy of note in~~ this ~~endeavor~~.		Instead of throwing it out, I'd like to see whether it can be turned into something useful. But really, this thing isn't worth saving. Go spend some extra money on something that can run OpenWRT and save yourself the headache.

	== Hardware ==		== Hardware ==
Line 11:		Line 11:

	# The Intel Atom CPU which the firmware files refer to as 'APPCPU' and is responsible for services like Samba and handling of the USB ports. It is also the CPU that boots up the system when the system is powered on. The CPU appears to read the first 2MB of the flash storage when powered on as that's where the BIOS related data is stored.		# The Intel Atom CPU which the firmware files refer to as 'APPCPU' and is responsible for services like Samba and handling of the USB ports. It is also the CPU that boots up the system when the system is powered on. The CPU appears to read the first 2MB of the flash storage when powered on as that's where the BIOS related data is stored.
	# The ARM CPU which is referred to as the 'NP CPU' which is responsible for network related services including the web UI interface, SNMP, DOCSIS related services, and the network CLI program. This CPU is disabled (or made to not boot) if the system is powered on with the front button pressed. The processor boots using u-boot stored on partitions 7 and 8 of the flash storage.		# The ARM CPU which is referred to as the 'NP CPU' which is responsible for network related services including the web UI interface, SNMP, DOCSIS related services, and the network CLI program. This CPU is disabled (or made to not boot) if the system is powered on with the front button pressed. The processor boots using u-boot stored on partitions 7 and 8 of the flash storage. Whenever this ARM/NP CPU side is rebooted, the Intel/APP CPU side also reboots. Interestingly, rebooting the Intel/APP CPU side does not affect the ARM/NP CPU side.

	=== Overview ===		=== Overview ===
Line 1,777:		Line 1,777:

	=== Partitions ===		=== Partitions ===
	There are 13 partitions on mmcblk0. The area before the first partition has the u-boot and possibly boot options. ~~The last few KBs~~ of ~~this area does have the boot cmdline~~. ~~I'm not sure if changing this directly on the flash device~~ is ~~a good idea since it also looks like~~ the boot ~~stages verifies the contents. I have no real way to re-write this if I brick the system either~~.		There are 13 partitions on mmcblk0. The area before the first partition has the u-boot and possibly boot options. There are two copies of everything. Which image is booted from is determined by the u-boot environment variable <code>ACTIMAGE</code>.
	{\| class="wikitable"		{\| class="wikitable"
	!Partition		!Partition
Line 1,805:		Line 1,805:
	\|Intel		\|Intel
	\|Squashfs, created: Wed Aug 21 03:54:11 2019		\|Squashfs, created: Wed Aug 21 03:54:11 2019
	Intel rootfs		Intel/APP CPU rootfs. Use squashfs with xz compression.
	\|-		\|-
	\|4		\|4
Line 1,816:		Line 1,816:
	\|Intel		\|Intel
	\|Squashfs, created: Thu Nov 18 07:30:34 2021		\|Squashfs, created: Thu Nov 18 07:30:34 2021
	Intel rootfs. Use squashfs with xz compression.		Intel/APP CPU rootfs. Use squashfs with xz compression.
	\|-		\|-
	\|6		\|6
	\|2MB		\|2MB
	\|Intel		\|Intel
	\|Mounted as <code>/nvram</code>.		\|Mounted as <code>/nvram</code>. on the Intel/APP CPU side.
	EXT3		EXT3
	\|-		\|-
Line 1,936:		Line 1,936:
	}		}
	\| lang = C		\| lang = C
	}}		}}Changing <code>/etc/passwd</code> so telnet uses <code>/bin/sh</code> is the workaround.

	== Final thoughts ==		== Final thoughts ==
	I never noticed any performance issues with this modem while using it for years. However, I can definitely see some issues with the design of this device. For one thing, why are there two disjoint systems running different architectures but using the same memory and flash storage, bridged together with a hardware network bridge? Why not use one system?		I never noticed any performance issues with this modem while using it for years. However, I can definitely see some issues with the design of this device. For one thing, why are there two disjoint systems running different architectures but using the same memory and flash storage, bridged together with a hardware network bridge? Why not use one system?

	The Intel CPU ~~is a dual core processor and~~ seems to be used just to handle USB storage and Samba. The ARM processor seems to be overloaded by the DOCSIS handling, let alone all the other network related processes like SNMP, Web UI, Telnet, Dropbear/SSH, VPN, GRE tunnels, etc. High latency and jitter isn't really surprising since the ARM processor ~~appears to be overloaded and starved of memory~~.		The Intel CPU seems to be used just to handle USB storage and Samba. The ARM processor seems to be overloaded by the DOCSIS handling, let alone all the other network related processes like SNMP, Web UI, Telnet, Dropbear/SSH, VPN, GRE tunnels, etc. High latency and jitter isn't really surprising since it appears traffic to/from the DOCSIS and ethernet side have to go through the ARM/NP CPU processor which is very weak.

	The more I understand the system, the more it looks like a chimera to me. Two random creatures stapled together and made to work as modem -- poorly.		The more I understand the system, the more it looks like a chimera to me: Two random creatures stapled together and made to work as modem -- poorly.

	== See also ==		== See also ==

Leo at 20:53, 21 December 2023

2023-12-21T20:53:10Z

Show changes

Leo at 19:31, 21 December 2023

2023-12-21T19:31:21Z

Show changes

Leo at 22:23, 20 December 2023

2023-12-20T22:23:51Z

← Older revision		Revision as of 22:23, 20 December 2023
Line 164:		Line 164:
	There are 2 4-pin UART headers on the main board, each one for each of the ARM and Intel subsystems. The one closest to the USB ports appear to be connected to the ARM CPU while the other serial UART header on the other side of the board is connected to the Intel system.		There are 2 4-pin UART headers on the main board, each one for each of the ARM and Intel subsystems. The one closest to the USB ports appear to be connected to the ARM CPU while the other serial UART header on the other side of the board is connected to the Intel system.

	The Intel system appears to be the 'master' system and its UART will show POST messages immediately when the system is powered on. It also will prompt for a password if a key is hit during the POST stage (about 2-5 seconds after power on) with this message: "<code>please input your password</code>". ~~The~~ password ~~to unlock~~ the ~~boot menu is unknown to me~~. ~~I wasn't able to find this~~ particular ~~code~~ in the Intel CEFDK source code so this must be custom to the Hitron.		The Intel system appears to be the 'master' system and its UART will show POST messages immediately when the system is powered on. It also will prompt for a password if a key is hit during the POST stage (about 2-5 seconds after power on) with this message: "<code>please input your password</code>". There is a MD5 hash in the bootloader area of the flash "<code>aa6670c39dc93b73a34605e4d14d5003</code>", which appears to be the same password used by the cli tool <code>D0nt4g3tme!</code>. This particular password prompt did not appear in the Intel CEFDK reference source code so this must be custom to the Hitron.

	The ARM system only boots after the Intel system starts and when the secondary button is not pressed during the POST stage. Initial u-boot messages will appear on the ARM UART. No other messages appear after the system boots and no input appears to be read from this serial port.		The ARM system only boots after the Intel system starts and when the secondary button is not pressed during the POST stage. Initial u-boot messages will appear on the ARM UART. No other messages appear after the system boots and no input appears to be read from this serial port.

Leo at 17:28, 20 December 2023

2023-12-20T17:28:56Z

← Older revision		Revision as of 17:28, 20 December 2023
Line 1,659:		Line 1,659:
	* Hacking with an old RCE exploit - https://geekness.eu/content/remote-code-execution-hitron-cgnm-2250-part-1		* Hacking with an old RCE exploit - https://geekness.eu/content/remote-code-execution-hitron-cgnm-2250-part-1
	*Hardware info - https://wikidevi.wi-cat.ru/Hitron_CGNM		*Hardware info - https://wikidevi.wi-cat.ru/Hitron_CGNM
			*Process Control Daemon (PCD) - https://meetrp.github.io/pcd/script.html

Leo at 08:06, 20 December 2023

2023-12-20T08:06:07Z

← Older revision		Revision as of 08:06, 20 December 2023
Line 1,644:		Line 1,644:
	* ARM's processor is in big endian. You have to cross-compile armv7-be.		* ARM's processor is in big endian. You have to cross-compile armv7-be.
	* You kinda have to run the DOCSIS services. Otherwise, nothing seems to come up.		* You kinda have to run the DOCSIS services. Otherwise, nothing seems to come up.
	* You can control what services are started on the ARM side by looking at the PCD service manager files. The Intel side just uses rc.d startup scripts, not PCD.		* You can control what services are started on the ARM side by looking at the PCD service manager files. The Intel side just uses rc.d startup scripts, not PCD. PCD on the ARM side has many services set to reboot the system on failure. You may want to change this behavior if you want to hack/stop services without causing a reboot.
			* You have to start a watchdog daemon on the ARM side or else the system reboots (which also reboots the Intel side)

	== Final thoughts ==		== Final thoughts ==

Leo at 07:57, 20 December 2023

2023-12-20T07:57:58Z

← Older revision		Revision as of 07:57, 20 December 2023
Line 6:		Line 6:

	== Hardware ==		== Hardware ==
	The CGNM-2250 is based on the Puma 6 modem chipset/architecture. The architecture of the entire system is extremely odd and was offered many surprises as I dug deeper into the firmware. There are two distinct subsystems (using different CPU architectures) on this modem. Each system runs different components of the modem and communicate with each other using ~~some sort of~~ message passing. Networking is bridged between the two subsystems with an internal 'l2sd' interface with ~~internal~~ VLANs.		The CGNM-2250 is based on the Puma 6 modem chipset/architecture. The architecture of the entire system is extremely odd and was offered many surprises as I dug deeper into the firmware. There are two distinct subsystems (using different CPU architectures) on this modem. Each system runs different components of the modem and communicate with each other using RPC message passing through an internal VLAN network. Networking is bridged between the two subsystems with an internal 'l2sd' interface with multiple VLANs.

	=== Overview ===		=== Overview ===
Line 299:		Line 299:

	You may also try to connect to the UART using a 3.3 volt adapter (or use something like ESP-Link) to get a shell directly on the device.		You may also try to connect to the UART using a 3.3 volt adapter (or use something like ESP-Link) to get a shell directly on the device.



	This is what it looks like on the Intel UART when in this mode:{{Highlight		This is what it looks like on the Intel UART when in this mode:{{Highlight
Line 1,551:		Line 1,549:
	\|Intel		\|Intel
	\|Squashfs, created: Thu Nov 18 07:30:34 2021		\|Squashfs, created: Thu Nov 18 07:30:34 2021
	Intel rootfs		Intel rootfs. Use squashfs with xz compression.
	\|-		\|-
	\|6		\|6
Line 1,645:		Line 1,643:
	* Adjust the default policy for INPUT to accept to make life easier: <code>xtables-multi iptables -P INPUT ACCEPT</code>.		* Adjust the default policy for INPUT to accept to make life easier: <code>xtables-multi iptables -P INPUT ACCEPT</code>.
	* ARM's processor is in big endian. You have to cross-compile armv7-be.		* ARM's processor is in big endian. You have to cross-compile armv7-be.
			* You kinda have to run the DOCSIS services. Otherwise, nothing seems to come up.
			* You can control what services are started on the ARM side by looking at the PCD service manager files. The Intel side just uses rc.d startup scripts, not PCD.

	== Final thoughts ==		== Final thoughts ==
	I never noticed any performance issues with this modem while using it for years. However, I can definitely see some issues with the design of this device. For one thing, why are there two disjoint systems running different architectures but using the same memory and flash storage, bridged together with a hardware network bridge? Why not use one system?		I never noticed any performance issues with this modem while using it for years. However, I can definitely see some issues with the design of this device. For one thing, why are there two disjoint systems running different architectures but using the same memory and flash storage, bridged together with a hardware network bridge? Why not use one system?

	The Intel CPU is a dual core processor and seems to be used just to handle USB storage and Samba. The ARM processor seems to be overloaded by the DOCSIS handling, let alone all the other network related processes like SNMP, Web UI, Telnet, Dropbear/SSH, VPN, GRE tunnels, etc.		The Intel CPU is a dual core processor and seems to be used just to handle USB storage and Samba. The ARM processor seems to be overloaded by the DOCSIS handling, let alone all the other network related processes like SNMP, Web UI, Telnet, Dropbear/SSH, VPN, GRE tunnels, etc. High latency and jitter isn't really surprising since the ARM processor appears to be overloaded and starved of memory.

	The more I understand the system, the more it looks like a chimera to me. Two random creatures stapled together and made to work as modem -- poorly.		The more I understand the system, the more it looks like a chimera to me. Two random creatures stapled together and made to work as modem -- poorly.