Verizon Fios G3100 and E3200 Research

[FiosFiend]

The weeks go by quick and it’s time for another update already! This week I didn’t run any scrapes or process any images for passwords, which means we don’t have a database update.

@samer59 shared his wordlists collected from the TMobile KVD21, so I thought I should extract all of the words in my database to their appropriate lists again. I have also included these Fios words in my lists.  These lists are attached below.

Saved 454 unique words to 3_letter_words.txt
Saved 888 unique words to 4_letter_words.txt
Saved 611 unique words to 5_letter_words.txt
Saved 379 unique words to 6_letter_words.txt
Saved 564 unique words to 7_letter_words.txt
Saved 7 unique words to 8_letter_words.txt

Without including samer59’s contrubution, using the dictionary generator I previously posted would create a dictionary of 14,779,552,320 possible combinations for the strict 15-char <word><word><word> SSID passwords. Unfortunately I still haven’t found a way to reduce this list further.

It’s not all bad news this week though, I’ve made a bit of progress with the firmware! I shared the list of firmware links that I've found, and a GitHub user is hosting them for people that can’t download directly from Verizon  (https://3to.moe/verizon_fw/). My G3100 device is currently on version 3.4.0.10, which I thought was the latest version. However, I had noticed version 3.6.0.6 was listed on the Verizon firmware page. We already know the URL to find this firmware, so it was easy to find the link. Other devices had newer firmware listed too, so we grabbed those. I updated the fuzzing script with the new info and here’s what we found.

Code:

G3100:
https://cpe-ems34.verizon.com/firmware/BHRx/g3100_fw_3.6.0.5_loader.bin
https://cpe-ems34.verizon.com/firmware/BHRx/g3100_fw_3.6.0.6_loader.bin

E3200:
https://cpe-ems34.verizon.com/firmware/BHRx_Ext/e3200_fw_3.6.0.3_loader.bin

CR1000A:
https://cpe-ems34.verizon.com/firmware/CHRA/chr2fa_fw_3.6.0.2_BD_loader.bin

CR1000B:
https://cpe-ems34.verizon.com/firmware/CHRB/chr2fb_fw_3.6.0.2_BD_loader.bin

I was also rereading the huge OpenWRT thread on unlocking the CR1000A again, which this post had a link to firmware that I previously overlooked. These file names would be much harder for me to fuzz since they include a timestamp. However searching for the "cdn3.vzwdm” I came across these links. These files are also able to be directly downloaded by anyone!

Code:

https://cdn3.vzwdm.com/hdm/chr2fa_fw_3.2.0.11_oldsig_1685136655890.bin
https://cdn3.vzwdm.com/hdm/chr2fa_fw_3.3.0.11_loader_1715281399811.bin
https://cdn3.vzwdm.com/hdm/chr2fa_fw_3.3.1.2_1735849764361.bin

The firmware with the oldsig caught my attention. That is the first time we’ve seen this in the file name, and version 3.2.0.11 is actually one that we didn’t previously have. Unfortunately we don’t get any different outcomes using binwalk on these newly found firmware. However, the G3100/E3200 are Broadcom devices, and I found this script (BRCM-Unpack) that is supposed to unpack their firmware. Sadly it doesn’t correctly extract any of the G1100/G3100/E3200 firmware, but we get the following output for ALL of the CR1000A/B.

Code:

Image Processing Started on Thu 26 Jun 08:04:50 EDT 2025

Log: output.log
Source: chr2fa_fw_3.2.0.11_oldsig.bin
Size: 61219600

Checking Package Version

SQFS Offset: 55468552
Saved: root_fs.sqfs

Checking for FDT Pattern

FDT Offset: 256
Saved: chr2fa_fw_3.2.0.11_oldsig.dtb
chr2fa_fw_3.2.0.11_oldsig.dts: Warning (unit_address_vs_reg): /images/script/hash@1: node has a unit name, but no reg property
chr2fa_fw_3.2.0.11_oldsig.dts: Warning (unit_address_vs_reg): /images/hlos-199b4e2d5c82b8034f572c5225279453506f03d4/hash@1: node has a unit name, but no reg property
chr2fa_fw_3.2.0.11_oldsig.dts: Warning (unit_address_vs_reg): /images/rootfs-38f7ad8fe7922c1367cfac77ce43c6ee879dc450/hash@1: node has a unit name, but no reg property
chr2fa_fw_3.2.0.11_oldsig.dts: Warning (unit_address_vs_reg): /images/wififw_v1-45b62ade000c18bfeeb23ae30e5a6811eac05e2f/hash@1: node has a unit name, but no reg property
chr2fa_fw_3.2.0.11_oldsig.dts: Warning (unit_address_vs_reg): /images/wififw_v2-d1ec7b26faa44d75a2a40afa9a11c844f2b6ead3/hash@1: node has a unit name, but no reg property
Saved: chr2fa_fw_3.2.0.11_oldsig.dts

Description: Flashing emmc 200 200
Nodes: images
Images: script hlos-199b4e2d5c82b8034f572c5225279453506f03d4 rootfs-38f7ad8fe7922c1367cfac77ce43c6ee879dc450 wififw_v1-45b62ade000c18bfeeb23ae30e5a6811eac05e2f wififw_v2-d1ec7b26faa44d75a2a40afa9a11c844f2b6ead3

Extracting: script
  Description:  flash.scr
  Created:      Wed May 24 13:38:48 2023
  Type:        Script
  Compression:  uncompressed
Saved: script

Extracting: hlos-199b4e2d5c82b8034f572c5225279453506f03d4
  Description:  openwrt-ipq-ipq807x_64-qcom-ipq807x-hkxx-fit-uImage.itb.padded
  Created:      Wed May 24 13:38:48 2023
  Type:        Firmware
  Compression:  uncompressed
Saved: hlos-199b4e2d5c82b8034f572c5225279453506f03d4

Extracting: rootfs-38f7ad8fe7922c1367cfac77ce43c6ee879dc450
  Description:  openwrt-ipq-ipq807x_64-squashfs-root.img
  Created:      Wed May 24 13:38:48 2023
  Type:        Firmware
  Compression:  uncompressed
Saved: rootfs-38f7ad8fe7922c1367cfac77ce43c6ee879dc450

Extracting: wififw_v1-45b62ade000c18bfeeb23ae30e5a6811eac05e2f
  Description:  wifi_fw_squashfs.img
  Created:      Wed May 24 13:38:48 2023
  Type:        Firmware
  Compression:  uncompressed
Saved: wififw_v1-45b62ade000c18bfeeb23ae30e5a6811eac05e2f

Extracting: wififw_v2-d1ec7b26faa44d75a2a40afa9a11c844f2b6ead3
  Description:  wifi_fw_ipq8074_qcn9000_squashfs_v2.img
  Created:      Wed May 24 13:38:48 2023
  Type:        Firmware
  Compression:  uncompressed
Saved: wififw_v2-d1ec7b26faa44d75a2a40afa9a11c844f2b6ead3

Finished Image Processing: Thu 26 Jun 08:05:15 EDT 2025

Started Kernel Processing: Thu 26 Jun 08:05:15 EDT 2025
All Processing Completed on Thu 26 Jun 08:05:15 EDT 2025

The script extracted several images for us! That rootfs looks nice, but its LUKS encrypted.

Code:

rootfs-38f7ad8fe7922c1367cfac77ce43c6ee879dc450: LUKS encrypted file, ver 1 [aes, xts-plain64, sha1] UUID: 4d12098e-44d5-46f4-8dd4-2622485ae277

The file that starts with “hols-“ is actually the U-Boot image (fit-uImage.itb.padded), and is also encrypted. Fortunately the user spol-eff posted a script to decrypt this image. The original script was in Swift code, but I ported it to python.

Code:

import hashlib
from cryptography.hazmat.primitives.ciphers import Cipher, algorithms, modes
from cryptography.hazmat.backends import default_backend
import os
import struct

def decrypt_hlos(input_filepath, output_filepath):
    """
    Decrypts the HLOS image using SHA384 for key derivation and AES-256 CBC.

    Args:
        input_filepath (str): Path to the input encrypted HLOS file.
        output_filepath (str): Path for the decrypted output file.
    """
    # 1. Key Derivation (SHA384)
    # The Swift code uses SHA2(variant: .sha384).calculate(for: ...)
    # The input bytes are [0x26, 0x46, 0x35, 0x75, 0x61, 0x23, 0x4f, 0x72, 0x36, 0x56]
    key_material = bytes([0x26, 0x46, 0x35, 0x75, 0x61, 0x23, 0x4f, 0x72, 0x36, 0x56])
    sha384_hash = hashlib.sha384(key_material).digest()

    # The AES key is the first 0x20 (32) bytes of the SHA384 hash.
    # SHA384 produces a 48-byte hash, so we take the prefix.
    aes_key = sha384_hash[:0x20] # 32 bytes for AES-256

    # 2. AES Setup (CBC Mode, No Padding)
    # IV is Array(repeating: 0x0, count: 0x10) -> 16 null bytes
    aes_iv = bytes([0x0] * 0x10) # 16 bytes for AES block size

    # Initialize AES cipher
    cipher = Cipher(algorithms.AES(aes_key), modes.CBC(aes_iv), backend=default_backend())
    decryptor = cipher.decryptor()

    # 3. File Handling and Decryption
    try:
        # Ensure output directory exists if output_filepath includes one
        os.makedirs(os.path.dirname(output_filepath), exist_ok=True)

        with open(input_filepath, 'rb') as input_file:
            # Read the first 4 bytes (UInt32) for image size (little-endian)
            # and then seek back and past the 0x200 offset.
            # Swift code reads 4 bytes, then seeks to 0, then seeks to 0x200.
            # We can directly seek to 0x200 and read the rest.
           
            # First, read the full content after the header to calculate size if needed
            # For this script, we'll mimic the Swift behavior for imageSize display
           
            input_file.seek(0)
            size_bytes = input_file.read(4)
            if len(size_bytes) < 4:
                raise ValueError("Input file too small to read image size header.")
           
            # The Swift code loads as UInt32 littleEndian.
            # struct.unpack('<I', ...) parses 4 bytes as unsigned int, little-endian.
            image_size = struct.unpack('<I', size_bytes)[0]
            print(f"Image size (from header): {image_size} bytes")

            # Seek to the actual start of the encrypted data
            input_file.seek(0x200)
            image_bytes = input_file.read() # Read the rest of the file

            # Decrypt the image bytes
            decrypted_bytes = decryptor.update(image_bytes) + decryptor.finalize()

        # Write decrypted data to output file
        with open(output_filepath, 'wb') as output_file:
            output_file.write(decrypted_bytes)

        print(f"Done: written {len(decrypted_bytes)} bytes to {output_filepath}")

    except FileNotFoundError:
        print(f"Error: One of the files was not found.")
        print(f"Input: {input_filepath}")
        print(f"Output: {output_filepath}")
    except Exception as e:
        print(f"An error occurred: {e}")

Once the hlos- file is decrypted, the image unpacks cleanly with unblob! The U-Boot image contains /etc/keyfile



On a Linux system with cryptsetup installed, we can use this keyfile to decrypt and open the LUKS encrypted rootfs.

Code:

#sudo cryptsetup --key-file=keyfile luksOpen <file_path> <mapping_name> -v
sudo cryptsetup --key-file=keyfile luksOpen rootfs-38f7ad8fe7922c1367cfac77ce43c6ee879dc450 CR1000A_rootfs -v

This command has -v for verbose output, and should display:
Key slot 0 unlocked.
Command successful.

The decrypted SquashFS image will be located at /dev/mapper/<mapping_name>, so we can extract the image with

Code:

#sudo unsquashfs /dev/mapper/<mapping_name>
sudo unsquashfs /dev/mapper/CR1000A_rootfs

Which gives us the full, decrypted rootfs



The keyfiles themselves aren’t in plain text, but we can view/share them using the command

Code:

cryptsetup luksDump —dump-master-key —key-file <keyfile path> <rootfs path>

WARNING!
========
The header dump with volume key is sensitive information
that allows access to encrypted partition without a passphrase.
This dump should be stored encrypted in a safe place.

Are you sure? (Type 'yes' in capital letters): YES
LUKS header information for rootfs-38f7ad8fe7922c1367cfac77ce43c6ee879dc450
Cipher name:      aes
Cipher mode:      xts-plain64
Payload offset:    4096
UUID:              4d12098e-44d5-46f4-8dd4-2622485ae277
MK bits:          256
MK dump:    30 c8 8e 47 a9 a0 d2 90 bb 3c 22 27 3f c7 53 a6
        71 e7 29 80 53 1f 43 67 e1 dd ca d4 5c c9 3a f4

I tried all of the above steps on the latest CR1000A firmware (chr2fa_fw_3.6.0.2_BD_loader.bin), everything works as expected!

Code:

LUKS header information for rootfs-d616347925ecd1d9eb4366fd0013d30798e505f5
Cipher name:      aes
Cipher mode:      xts-plain64
Payload offset:    4096
UUID:              36281f72-7198-49fb-aa70-70b1557b8b1b
MK bits:          256
MK dump:    82 29 97 83 3e 52 25 92 6b c5 c8 10 4c 32 a8 ea
        be 99 f1 68 ae 08 6a c8 c7 86 fe 3d 31 aa 27 39

I haven’t had much of a chance to poke around, but please let me know if anything catches your eye.