06-14-2025, 06:49 PM (This post was last modified: 06-14-2025, 06:59 PM by FiosFiend.)
Hey everyone, it’s time again for another update. I was able to manually process most of the images from last week's large scrape. I added some more of the G1100 MAC addresses. Unfortunately, we didn’t add to many entries to the database this week.
This week’s scrape did match 2 VERY similar passwords however. Certainly this can’t be a coincidence?
We caught a WNC-CR200A with the WiFi password grille9-yea-ode
We also have a CR1000A with the WiFi password yea-grille9-ork
I also figured out that the script to decrypt the CR1000A config file also works for the G3100! Modifying the config file was has been used to enable SSH on G1100 and CR1000. Unfortunately, on the latest firmware the G3100 doesn’t give us much to work with, just a bunch of files with the normal configuration parameters.
My device is currently on the latest firmware 3.4.0.10, so I tried to rollback my firmware using https://192.168.1.1/#/firmware_upgrade. I was able to roll back to 3.4.0.4, but anything before that was unsuccessful.
During this, I realized that the firmware was one version newer than my OP, so here are the links to the newest Firmware for G3100 and E3200
We also found firmware links for the ASK-NCQ1338, I was able to figure out that the firmware naming is in the format ASK-NCQ1338_<current version>_<new version>.bin. Since I already collected the firmware version in the database, It was easy to enumerate other links! There were a few links missing files, I’m guessing that there is probably another firmware version in between. I could try fuzzing to find them, but I don’t think it’s entirely necessary at the moment. These links are accessible even if you’re not on the Fios network.
This week was just a typical scrape, but we managed to add over 100 new entries! I also got the MAC addresses entered for the NVG558HX entries. We have added model CE1000A to the scrape, they get added under CR1000A/B.
I wanted to highlight some of the devices that get caught in the QR scrape but are out of scope for this thread. Maybe sometime I will have some time to check them out further. I have seen a dozen or so devices, but most of the time the QR only contains the SSID / Password. Here are a few that are a bit more interesting.
The QR code has the SSID, WiFi Password, Model, Serial, and Admin password.
Not much info in the QR code, but the sticker contains everything we would expect. These passwords are 8 characters all digits and very easy to crack as seen here and on WPA-SEC.
06-24-2025, 11:25 PM (This post was last modified: 06-24-2025, 11:28 PM by samer59.)
In case anybody wants them: wordlists (including Admin password lists 8 letter and 9 letter in the next post) for TMobile KVD21. I've been collecting them for awhile. The words compiled strictly collected from KVD21.
06-30-2025, 04:20 AM (This post was last modified: 06-30-2025, 04:23 AM by 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.
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!
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
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
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
# 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.
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.
We have a new device this week, the CME1000. I had been aware of this device for a while, but the sticker doesn’t have much information and I hadn’t found an image with a readable QR code yet. However, when we can read the QR code it has all of the relevant information. There is no device tear down, though I would like to see inside just for fun
I am a bit embarrassed to admit it, but I also realized this week we could have extracted the G1100 firmware since my original post . This GitHub page was part of my initial research, and until recently it contained the only known G1100 firmware (bhr4_release_01.03.02.02-FTR_firmwareupgrade.bin.signed and bhr4_stepstone_release_1.2.0.36.98.0_firmwareupgrade.bin.signed). Both of these firmware are encrypted with a PGP key, but fortunately jameshilliard has already extracted the Private Keys for us! Here are the keys, I have also attached them below.
And this is where I have been stuck... binwalk only extracts a system.dtb and I am not really sure what to do from there. It took me way too long to realize that the decrypted firmware extracts cleanly with unblob!
The PGP Keys also work to decrypt the firmware that I found (bhr4_release_02.03.00.13_firmwareupgrade.bin.signed and bhr4_release_02.03.00.14_firmwareupgrade.bin.signed), but frontier4_vz_stepstone_release_01.03.01.02_firmwareupgrade.bin.signed is still missing the key.
Poking around the firmware just a bit, every version has this in /etc/shadow root:$6$rFBGnLMRIiVVPTZ8$1J3zPn31Wfrht0oOCKZW52YhbA.lmNieZ6C7zaJ3sANjVYYk28E3FAA1xEMN4ezAu1IAQBRShs4vRl/atc5tF0:15861:0:99999:7:::
I didn’t bother to run the scrapes again this week. Since we are really only catching newly listed hits, I will probably update the database every 2-3 weeks from now on. That doesn’t mean that we don’t have some good info to share this week though!
This week I posted the root hashes that I've found for G1100 and NCQ1338, and @Sparton has successfully cracked the G1100root:thinkgreen. THANKS! We are still looking for $1$7uheFpms$9IpAGF0yM8EV4CvwnpgD.1
I also reached out to @RealEnder, who shared the hcxpcapngtool -D output for all of the Verizon/Fios captures uploaded to WPA-SEC. As we know, the broadcast packets give us the MAC, MANUFACTURER, MODELNAME, SERIALNUMBER, DEVICENAME, UUID, ESSID. The first thing that I did was look for new Models. There are a good many MiFi devices. I looked a few of these up on eBay, and it doesn’t seem like they show their default password since the device has a screen. There are also a good many Extenders/Repeaters that are just broadcasting the Verizon/Fios SSID.
The one new device that I was able to identify is the LVR5-100, which is a 5g/4g cellular router manufactured by Wistron NeWeb. The device teardown shows the CPU is a stm32wb35, wihich is an Arm Cortex-M4 32-bit RISC core operating at a frequency of up to 64 MHz. Unfortunately, It doesn’t have a QR code, so we haven’t caught it with our scrape. There are only 2 entries for this device, which is unfortunate because the password is an easy to crack 8 character lowercase HEX! This model has been included with LVSKIHP in the packet database.
There is a device that just shows Broadcom and the same SN/UUID for all of the entries. I checked the MAC prefixes 10:78:5B and 70:F2:20 in the password database and identified this model as WCB6200Q. The only model that I didn’t find entries for is the ASK-RTL108, but here are a ton of entries for ALL of the other devices covered in this thread. Let’s take a look...
Note: Here MACS is what I’ve been calling “steps” throughout the thread. It’s calculated by comparing the differences in MAC address vs differences in Serial number. This results in a whole number that indicates how many MAC addresses each devices occupies.
Model: ARC-XCI55AX
Manufacture: Arcadyan
Device: Titan2
Serial Prefix: ABU GRR
Serial Length: 11
MACS: 4
MAC Prefix: 04:09:86 04:70:56 18:58:80 4C:22:F3 54:B7:BD 74:90:BC 84:90:0A 84:A3:29 8C:83:94 A8:A2:37 AC:B6:87 BC:F8:7E C0:D7:AA C8:99:B2 DC:F5:1B F4:CA:E7
UUID: All entries are bc329e001dd811b28601XXXXXXXXXXXX, where X is 1 less than the broadcast MAC Address
EX: 04098647eaa3 = bc329e001dd811b2860104098647eaa2
SSID: Verizon_XXXXXX
Model: ASK-NCM1100
Manufacture: Arcadyan
Device: TITAN4
Serial Prefix: ACL ACN ACQ ACR
Serial Length: 11
MACS: 6
MAC Prefix: 38:88:71
UUID: All entries are bc329e001dd811b28601XXXXXXXXXXXX, where X is 2 less than the broadcast MAC Address
EX: 3888710aee34 = bc329e001dd811b286013888710aee32
SSID: Verizon_XXXXXX
Model: ASK-NCQ1338E
Manufacture: Askey
Device: NCQ1338
Serial Prefix: AA1 AAM ABB ABF ABG G1C G1D G1E
Serial Length: 11
MACS: 4
MAC Prefix: 88:DE:7C 2C:EA:DC 4C:AB:F8 A4:97:33 FC:12:63 74:93:DA
UUID: All entries are 876543219abcdef01234XXXXXXXXXXXX, where X is 1 less than the broadcast MAC Address
EX: 2ceadc10f653 = 876543219abcdef012342ceadc10f652
SSID: Verizon_XXXXXX
Model: CR1000
Manufacture: Arcadyan
Device: ath1 or CHR2f
Serial Prefix: ABJ AB2 AAW AAY ACZ ABP ABQ ABV ABW
Serial Length: 11
MACS: 7 (CR1000A) or 9 (CR1000B)
MAC Prefix: 04:70:56 58:96:71 04:09:86 1C:D6:BE 24:41:FE 34:19:4D 3C:F0:83 4C:22:F3 54:B7:BD 74:90:BC 78:67:0E 84:90:0A 84:A3:29 86:67:0E 88:5A:85 8C:83:94 A8:A2:37 AC:91:9B AC:B6:87 BC:F8:7E C8:99:B2 DC:4B:A1 DC:F5:1B
UUID: All entries are 876543219abcdef01234XXXXXXXXXXXX, where X is 2 less than the broadcast MAC Address. This matches what we discovered earlier.
EX: 047056582046 = 876543219abcdef01234047056582044
SSID: FiOS-XXXXX, Fios-XXXXX or Verizon_XXXXXX
Model: CME1000
Manufacture: Arcadyan
Device: CHR2tte
Serial Prefix: ABA
Serial Length: 11
MACS: 6
MAC Prefix: 4C:22:F3 54:B7:BD 74:90:BC 84:A3:29 8C:83:94 BC:F8:7E DC:F5:1B
UUID: All entries are bc329e001dd811b28601XXXXXXXXXXXX, where X is 2 less than the broadcast MAC Address
EX: 4c22f34c6688 = bc329e001dd811b286014c22f34c6686
SSID: Verizon_XXXXXX
Model: E3200
Manufacture: Arcadyan
Device: E3200
Serial Prefix: E301 E302 AA62 AA63 AA64
Serial Length: 16
MACS: 6
MAC Prefix: 04:A2:22 3C:BD:C5 62:A2:22 62:BD:C5 62:F8:53 6A:A2:22 6A:BD:C5 6A:F8:53 72:A2:22 72:BD:C5 72:F8:53 74:90:BC B8:F8:53 DC:F5:1B
UUID: Appears to be random
SSID: Fios-XXXXX or Verizon_XXXXXX
Model: FSNO21VA
Manufacture: Arcadyan
Device: ath0
Serial Prefix: ABH
Serial Length: 11
MACS: 1
MAC Prefix: 98:C8:54
UUID: All entries are 876543219abcdef01234XXXXXXXXXXXX, but the last 6 digits of X doesn’t match the MAC address
EX: 98c854a7a4e0 = 876543219abcdef0123498c8549951e8
EX: 98c854a8d4af = 876543219abcdef0123498c8549aaa86
SSID: Verizon_XXXXXX
Model: G1100
Manufacture: GreenWave
Device: GreenWave
Serial Prefix: G1A1 G1A2 S1A1
Serial Length: 15
MACS: 5
MAC Prefix: 18:78:D4 20:C0:47 20:C0:C7 29:6A:0B 48:5D:36 C8:A7:0A D4:A9:28
UUID: Appears to be random
SSID: FiOS-XXXXX or Fios-XXXXX
Model: G3100
Manufacture: Arcadyan
Device: G3100
Serial Prefix: G401 G402
Serial Length: 16
MACS: 11 or 8 depending on manufacture date
MAC Prefix: 04:A2:22 3C:BD:C5 B8:F8:53
UUID: Appears to be random
SSID: Fios-XXXXX or Verizon_XXXXXX
Model: LVSKIHP
Manufacture: WNC
Device: Verizon K2
Serial Prefix: GI1A GI1B (identified from image scrape data)
Serial Length: 12
MACS: Unknown
MAC Prefix: 64:FF:0A 88:5A:85 B8:9F:09 44:E4:EE
UUID: All entries are 876543219abcdef01234XXXXXXXXXXXX, where X is 2 less than the broadcast MAC Address.
EX: 64ff0a558556 = 876543219abcdef0123464ff0a558554
SSID: Verizon-5G-Home-XXXX or Verizon-LRV5-XXXX
Model: NVG558HX
Manufacture: Commscope
Device: <same as Serial Number>
Serial Prefix: MV2
MACS: 12
MAC Prefix: 20:F3:75 58:60:D8 8C:5A:25 E4:F7:5B
UUID: Appears to be random
SSID: Verizon-XXXX
Model: WCB6200Q
Manufacture: Broadcom
Device: <blank>
Serial Prefix: GWXA GWXB MWXB (identified from image scrape data)
Serial Length: 14
MACS: 16 (calculated from image scrape data)
MAC Prefix: 10:78:5B 4C:8B:30 70:F2:20
UUID: ALL entries show a single UUID d96c7efc2f8938f1efbd6e5148bfa812
SSID: FiOS-XXXXX or Fios-XXXXX
Note: This device is an extender only, so it is broadcasting the base SSID/Password
Model: WNC-CR200A
Manufacture: Arcadyan
Device: ath0 or ath1
Serial Prefix: ACA AC0
Serial Length: 11
MACS: 4
MAC Prefix: 58:96:71 24:41:FE AC:91:9B DC:4B:A1
UUID: All entries are 876543219abcdef01234XXXXXXXXXXXX, where X is 1 less than the broadcast MAC Address
EX: 589671080e92 = 876543219abcdef01234589671080e91
SSID: Verizon_XXXXXX
I noticed that the new model from last week, the CME1000 has the device name CHR2tte, which looks very similar to CHR2f (CR1000). So I added it to the firmware fuzzing script and we found the firmware for it!
binwalk -Me chr2tte_fw_3.2.0.9.bin --------------------------------------------------------------------------------------------------- DECIMAL HEXADECIMAL DESCRIPTION --------------------------------------------------------------------------------------------------- 256 0x100 POSIX tar archive, file count: 4 --------------------------------------------------------------------------------------------------- Analyzed 1 file for 85 file signatures (187 magic patterns) in 173.0 milliseconds
--------------------------------------------------------------------------------------------------- DECIMAL HEXADECIMAL DESCRIPTION --------------------------------------------------------------------------------------------------- 256 0x100 POSIX tar archive, file count: 4 --------------------------------------------------------------------------------------------------- [+] Extraction of tarball data at offset 0x100 completed successfully ---------------------------------------------------------------------------------------------------
sysupgrade-mt7986a-ax8400-2500wan-emmc-rfb-sb/kernel --------------------------------------------------------------------------------------------------- DECIMAL HEXADECIMAL DESCRIPTION --------------------------------------------------------------------------------------------------- 0 0x0 Device tree blob (DTB), version: 17, CPU ID: 0, total size: 21649465 bytes ---------------------------------------------------------------------------------------------------- [+] Extraction of dtb data at offset 0x0 completed successfully ---------------------------------------------------------------------------------------------------- Analyzed 5 files for 85 file signatures (187 magic patterns) in 1.5 seconds
Last weeks scrape caught a TMOHS1 from T-Mobile. I noticed that it has HUGE weakness. They use the last 8 digits of the IMEI as the password, and the last 4 digits for the SSID. The admin password is even easier to “guess" 🤣
I reached out to @RealEnder with this info. He confirmed that only 2 of the submitted hashes had been found, but both of them followed this pattern. He was able to quickly crack most of the other hashes; there are now 42 found! Looking back at the found hashes, ALL of the passwords start with the first 4 digits 5000-7999. This leaves us with 3000 possible candidates, which means you could probably crack it live without a handshake haha. It’s a very small contribution, but it makes me happy to have discovered this! Using this hashcat command should instantly crack the hash, here we are on a Raspberry Pi 4.
@ZerBea thanks for the response and thanks for all of your work! @RealEnder did a great job with imeigen, and has added the T-Mobile hotspot further reducing the possible candidates. I haven’t had a chance to check out the T-Mobile devices you shared to see if they have the same weakness.
Fios-F1nDr has been updated to differentiate between ARC-XCI55AX, CR1000, CME1000, E3200 for the DC:F5:1B MAC prefix. There is still a bit more of this type of work I have to do to the script, but overall it’s working well.
This week I was able to add 63 new entries to the password database.
We caught a new device too, the XC46BE, which is also manufactured by Arcadyan. The device teardown shows a variety of chips. I believe the Mediatek MT6990V is the ARM CPU, but I couldn’t find much info. The device QR code and sticker provide a great bit of info.
Model: XC46BE
Manufacture: Arcadyan
Device: DRAGON
Serial Prefix: ACS
MACS: Not enough Info
MAC Prefix: 20:37:F0 38:06:E6
UUID: All entries are bc329e001dd811b28601XXXXXXXXXXXX, where X is 2 less than the broadcast MAC Address
EX: 3806e6801442 = bc329e001dd811b286013806e6801440
SSID: Verizon-XXXX
The 3 password entries I was able to find show that The SSID password is 15 characters, and follows a new format <word><digit><word><digit><word>. So far, these passwords are comprised of a 3-letter, 4-letter, and 6-letter word with single digits. The admin password is 9 character alphanumeric as we’ve seen with a lot of the other devices.
The CSG m106 was also caught in the scrape, which is some sort of Verizon device though it doesn’t have the Verizon/Fios SSID. There QR code is just a link to the CSG website. However, the password is 8 character hex that is actually just the end of the serial number. Unfortunately, this device does not broadcast any ESSID information. I did the normal eBay, FB, OfferUp scrape and caught 19 entries. The serial numbers appear to be a a random 16 character hex, possibly a truncated hash. So I had a script try various user input, as well as Unix Epoch time against the password. There are several hashes that produce the password, but none that produce the full serial, so I suspect they are false positives. @RealEnder found the firmware (https://connectcsg.com/pages/firmware-updates), which extracts nicely...so I checked to see how the SN is being generated.
In the file gl_init we see
Code:
uci set glconfig.general.factory_mac=$(get_default_mac_with_colon)
uci set glconfig.general.factory_sn=$(get_default_sn)
ssid=`uci get glconfig.general.factory_mac | awk -F ":" '{print $(NF-1)$NF}'`
uci set wireless.@wifi-iface[$index].ssid="CSG-${ssid}"
key=`uci get glconfig.general.factory_sn | awk '{print substr($0,9)}'`
So we see The SSID is generated from the MAC, and the key is last 8 characters of the factory_sn. Unfortunately the factory_sn is pulled from NVRAM.
The data collected for CSG m106 all have the MAC prefix 94:83:C4, so I checked there in the WPA-SEC data. There are not any CSG entries since they don’t broadcast the information, however there are several GL-SFT1200 that overlap the address space. The firmware for this device is also available (https://dl.gl-inet.com/router/sft1200/stable), extracts cleanly, and is very similar to the CSG m106 with some minor vendor changes. In gl_init file for both firmware we see
Code:
ssid_prefix="GL-"${model}
uci set wireless.@wifi-iface[$index].key=goodlife
As the image above shows, devices with the SSID GL-<model> have the default password “goodlife”. The firmware shows other models this applies to AR300M, AR750, B1300, B2200, E750, MT750, S200, S1300, X750, X1200
router_data_FULL_061425.xlsx (Size: 823.16 KB / Downloads: 2)
![[Image: attachment.php?aid=1311]](https://hashcat.net/forum/attachment.php?aid=1311)
![[Image: attachment.php?aid=1310]](https://hashcat.net/forum/attachment.php?aid=1310)
![[Image: attachment.php?aid=1312]](https://hashcat.net/forum/attachment.php?aid=1312)
![[Image: attachment.php?aid=1313]](https://hashcat.net/forum/attachment.php?aid=1313)
![[Image: ncq1338-png.39122]](https://forum.hashkiller.io/index.php?attachments/ncq1338-png.39122/)
![[Image: s-l1600.jpg]](https://i.ebayimg.com/images/g/U38AAeSwXQBoUfka/s-l1600.jpg)
(
