Request for mtdblock9 dumps, for working on firmware 4.4.6 support

[jspavlick]

Hello everyone,

I have a UFiber Loco, and it bugs me that this tool doesn’t work entirely on firmware 4.4.6; it supports an older version, 4.3.1. The problem I have, as well as others, is the MAC address. After flashing a new MAC address, rebooting the device, and running ifconfig, the new MAC address is only applied to gpon0.0 and veip0. All the other interfaces have the hardware MAC address, except br1 and br2 which have different values all together. (Oddly some interfaces like bcmsw, br0, eth0, and eth0.0 have 69 in there while gpon0 and gpondef have 68)

On the bottom of my loco, it says “Serial # UBNTC26813E0” and “MAC ID 1938G 7483C26813E0” where the interesting part is 74:83:C2:68:13:E0.

I have dumped mtdblock9 (you can accomplish the same using dd, but I have modified the project to make it easier [https://github.com/jspavlick/UFiber.Configurator/tree/dump-and-flash-mtdblock-9]) and found some interesting values. The dump is the exact same byte size as mtdblock3 which is what the original program dumps and flashes. On both 4.3.1 and 4.4.6, the “virgin” dumps of mtdblock9 are exactly the same and contain the hardware MAC address. However, when modifying the address and flashing it back, 4.3.1 doesn’t seem to care, but 4.4.6 gets very upset and fails to boot entirely. If I simply change the MAC from 74:83:C2:69:13:E0 to 75:83:C2:69:13:E0, reboot, then SSH into the device, the “welcome to UFiber!” Message at the top of the terminal shows me the 75 MAC address! Logging into the web interface “works” but then the interface is totally broken.

Inspecting the contents of /tmp/bootupmessages I see some interesting lines such as “<2>bcmsw: MAC address has not been initialized in NVRAM.” Running ifconfig shows me the very odd MAC address of 00:10:18:63:00:00, and I don’t see all the network interfaces. I’m missing gpon0, gpon0.0 (which remember, had the correctly flashed MAC address previously), gpondef, veip0, and veip0.1.

Finally, let’s get to the contents of mtdblock9. I will post mine here at the bottom of this issue. At the top of the file, we see my MAC address, twice, but slightly off. 7483C268 13E07683 C26813E0 EEC30777 0009910D FFFF000D. There is my MAC address, starting with 74, but then it repeats, starting with 76. Then some “magic bytes” then all FFFFFF. Later down in the file, the exact same “EEC30777 7483C268 13E07683 C26813E0” is found. There are the EEC3… magic bytes, along with my “repeated, off by 2 MAC address(es)” 0009910D is found one other place in the file, close by. However, FFFF000D is not.

I’ve played with these MAC address values, flashing back and forth. I can’t seem to get anywhere. I haven’t bricked my device, though. I think I’m close, though. I believe there is a checksum somewhere close-by that upon recalculating (as the main configurator program does) will fix everything. This is just a guess, though.

I am requesting others to share the contents of their mtdblock9 dumps along with their hardware MAC addresses. Maybe we can find something out by pattern matching. Any insight or help would be greatly appreciated. Thanks everyone.

Github won't allow me to upload a .bin file so I renamed the file .zip. If you attempt to unzip it, you'll get an error, I assume. Just rename it with extension .bin (or .img or whatever you'd like). Although, you can inspect it with xxd or any hex editor regardless of the extension.

virgin-4.4.6.zip

[micallan17]

glad someone is working, i can test with a spare loco if needed.

[gbschenkel]

I bought 1 UF-Loco and the seller sent me 3, I think all they are in v2.0.1. One of them I just upgraded to v4.8.0, and is the one which I am uploading the dump. @jspavlick I used your repo for generate the file.

### Original Image ###
--- NVRAM Information --
- mtdblock3 hash: d09c7089f431d2d0a6aa126b5a138cf4a0daf20a85549c769cfdbd56ce61c8f5
- NVRAM Version: 6
- Boot parameters: e=192.168.1.1:ffffff00 h=192.168.1.254 g= r=f f=vmlinux i=bcm963xx_fs_kernel d=1 p=0 c= a= 
- Board Id: UBNT_SFU_6848
- PSI size: 24
- Total MAC addresses: 5
- GPON MAC address: 78:8A:20:C0:A8:A6
- GPON Vendor Id: UBNT
- GPON Serial Number: 20c0a8a6
- GPON SLID (password):           
- Checksum: 4128802369

Serial: UBNT20c0a8a6
Mac ID: 1821G 788A20C0A8A6

fw-15102024-115000.zip

[jspavlick]

@gbschenkel this looks to be mtdblock3 which is not what I'm looking for. I'm looking for mtdblock9. I bought two more locos (or nanos. whatever they are called) and comparing the mtdblock9s is weird. They are super different* but the area of interest is pretty obvious. I've been working on this (I even fired up stuff in IDA and was trying to reverse engineer. There is _getSysMacAddress or something) but it seems to be some sort of system call that is sent directly to the Broadcom chip. I couldn't figure it out.

I have a python script that brute-force-mode loops over the file in chunks looking for the ucrc32 of stuff somewhere with no success. I think in the "range" that I posted here in the screenshot, there is a piece that needs to be zero-ed out and then a checksum taken. I have yet to modify my script to brute force compute that. What I can do is upload the two mtdblock9s of my two units for anyone else to take a look at them. (Two bin files inside a zip)

mtdblock9s.zip

[jspavlick]

I did update and finish that python script and no dice. it didn't work. I could pretty it up and post it here, but I'm at a bit of a loss as what to do next. Maybe dive more into some findings I haven't posted here (strings that are shown in logs when booting up with a tampered mdtblock9 and where the strings exist in the binaries onboard the Loco, and where they show up in IDA, and where they are linked/referenced etc. This is getting a little out of my skill set and will require an untold amount of time for me to fix it, if I'm able to. It would be great if we had a MIPS expert or some such person who is "better than me" at this stuff haha.