Did they do this just for the lulz?
I worked on a similar type of project. We designed and prototyped a module in the US but the end customer wanted to assemble their finished product in China. Management was worried that the 'proprietary secrets' (cough cough) from the firmware could be stolen by the CM and used in their other customers' projects or sold to someone else. Fears escalated when our staff came back from a first visit and they showed us photographs of counterfeit Samsung Galaxies being built on the line right next to our legitimate product.
So what we did was design the bootloader to use a form of obsfucation (really, a rotating matrix of XOR patterns) and have the trusted processor manufacturer flash that onto the chips at the fab before reeling them up and shipping them to China. Then management could rest easier knowing that the production firmware being transmitted to the CM's testing line wasn't easily disassembled or copied into a similar part.
Of course, any clever engineer (like the OP) could have blown it apart in a day or so. We were a bit luckier that our entire firmware could fit on the protectable on-board eNVM and not use external NOR flash like this router. I guess the hope was to just discourage the practice and cross your fingers that this method would be enough.
Me: The customer has asked for security measures to stop unauthorised employees from subverting the system and defrauding them. Your solution uses clear-text passwords, so anyone with a copy of Wireshark could crack it in seconds.
Management: Yeah, but they're only asking for the appearance of security. They don't care about the details.
Me: What will they say if someone cracks our "security" and steals millions of dollars from them?
I don't get it from economical point of view. It's just additional work that doesn't bring any profits. Sole exception I could think of, is securing software-based limitations that "encourage" consumers to purchase more pricey devices. But it doesn't seem to be the case for this device - there aren't much of fancy hardware features hiding behind missing software options. One could probably solder an USB port (not sure whenever soldering and rebuilding firmware worth the savings from buying cheaper device), but I guess that's about it.
I have heard a rumour, that for the same reason SanDisk stopped supporting(with free hardware) Rockbox development.
Before somebody could purchase a less expensive Linksys wireless router, install a third-party firmware, and use it like the would a more expensive Cisco AP. So for Cisco this might take away from their higher end lines. For the new owners it's just an added sale that they wouldn't otherwise get.
It's too bad that HTC didn't get how important their XDA supporters were to staying relevant in the mindshare of the early adopters, who in turn recommend hardware purchases for the mainstream consumer. It's the same thing with Linksys.
I had a printer Kodak Hero 4.2. It has ink level warnings which I can not get around without new cartridge and new ink chips.
I found a way to get firmware and how to upload firmware manually. I also disassembled it and found few spots where I could change ARM asm code to jump around ink level checks. But I could not figure out how to put it all back together so printer would use this firmware instead. My naive approach did not work well and I bricked it (not a big deal).
I would love to read more about process people used to, for example, build DD-WRT, which I believe is modification of stock firmware.
There is probably a checksum (or even worse, digital signature) on the firmware image, or some other checks like that, but as for getting the firmware back on the device, I'd probably use a hardware flash programmer.
I wish, I had a better question: What is the software used to produce the "flow charts"?
I'd recommend using Hopper as a hobbiest.
I like the 3D visualization at http://binwalk.org/wp-content/uploads/2013/12/avr32_3d.gif
What might perhaps also be interesting, is to create a plugin for binwalk that compares the firmware with other firmware binaries.
As someone who has looked through many different types of files in doing quite a bit of RE, I've become able to separate out different types of data just by the "feel" of how it looks in a text editor; Z80 and 6502 code, x86, MIPS, ARM, bitmap images, and compressed data all have different "textures" to them.
It is very useful. As different file types and data structures. Often has a quite common entropy level to them.
Rather than doing it in your head as you do one can use a machine to help, which happens to be the hole point of machines.
It is just bytes visually represented.
1byte = x axis, 2byte = y axis, 3byte = z axis. And then jump forward and repeat.