Print

Please login or register.
1 Hour 1 Day 1 Week 1 Month Forever
Login with username, password and session length

[DAE51D]

Many have asked "Why can't we downgrade?" A downgrade is not impossible, it just requires more effort on the part of the engineering staff to figure out. The explanation is a bit technical, but here it is for anyone who cares.

Well, in spite of everything else, I would really like to thank you for writing this explanation. It really helps to clarify things and I'm also glad you didn't talk down to us in doing so, and you also explained it in a way that anyone (with a modicum of computer knowledge) would understand. Kudos.

[Cobra]

Given the problems I have with the OFFICIAL firmware, I think I'll stay away from some beta code that specifically says, on the page: http://forums.dlink.com/index.php?topic=9246.0

"The following beta firmware is provided on a trial basis only and without any kind of warranty. It is heavily advised not to use this beta firmware for any critical purpose.
 By downloading the beta firmware file, you expressly agree that the use of the firmware is at your own risk and discretion.
It is not supported through the normal support channels. All questions, comments and issues should be directed to this board."

riiiiiiight. I'll get right on that.

I would guess the majority of people who had DNS issues with 132NA had them resolved with the beta.

[davevt31]

http://forums.dlink.com/index.php?topic=10470.0

[sesca]

Thanks davevt31. I was just coming in to post the link to the new firmware.

http://forums.dlink.com/index.php?topic=10470.0

[davevt31]

Started a Feedback thread in the Beta Forum.

[Murr2k]

Downgrading to 1.2 is possible, it's just problematic.  /shrug

The following is just for the curious to see what kind of effort might go into a downgrade hack.

I've been mulling it over. If I had to work out a downgrade hack to make 1.2 firmware work in a 1.3 upgraded router, here's the things I'd have to do:

1. Look at the 1.3 binary code to figure out where the application entry point is. (not too hard)
2.Take the 1.2 binary code and prepend a padding block just the right size so that when the 1.2 code is loaded by the 1.3 loader, the entry point of the 1.2 code is positioned at the same address it used to live at in a 1.2 system. (easy)
3. Insert a jump instruction at the beginning of my new padding block (the 1.3 entry point) to jump to the beginning of the 1.2 code. (easy)
4. Figure out what checksum algorithm the bootloader uses during POST to determine when a valid application block is present, and where in the application code that checksum is located. (medium hard. gonna guess it's crc32 and try the usual seed values, then try other methods if that isn't it)
5. Calculate a the new checksum for my padded 1.2 firmware and put it in at the right address. (easy if I did #4 right)
6. Upload my hacked 1.2 image into a 1.3 router.
7. Hope the 1.2 application code doesn't make any absolute reference to bootloader routines because the 1.2 app code is now running on a 1.3 bootloader and things wont be in the same place. (forget about it. Not worthwhile to continue if this is the case)

Oh and of course I have to decrypt the original bin file before I can work on it, and re-encrypt it after each attempt I make to get the padding and checksum right. D-link doesn't want their executable being scammed by a competitor making cloned hardware. Personally I would have taken the time to use at least an RC4 cipher to make it really hard on me. And what... the image is divided into blocks, each with it's own checksum? If not, I would have done that too.

ok bye



 

[Cobra]

Dude I have already downgraded a 655 from 1.3x firmware.
I just wanted to see if it could be done but it IS very risky.
Then I flashed it back as I have no problems with my router.

[Murr2k]

Well, I was just thinking out loud based on other reverse engineering hacks I've done. They were for companies paying me to tweak their older products whose source code was lost. My approach may not be necessary in this case. I'm happy it works without it.

[foxium]

They are probably gun-shy about releasing a fix for 1.32 until they know it's "right". Or maybe the space they gained by expanding the application block for 1.3 is already used up and they are trying to bum a few more bytes of space out of it. Or maybe the only guy that really knew the system well was canned and there's no time for someone new to figure out what to do. Or maybe the upgrade has reformatted the eeprom and going back means having to save and reload parameters and it's too complicated for some engineer to figure out in one sitting. Or maybe their engineering resources are just too strained with new products and the 655 is really taking a back seat. Who knows.

Downgrading to 1.2 is possible, it's just problematic.  /shrug
 

Thank you for the insight! Kudos.

1.32 works for me except that after flashing to it my two DIR-655 ended up with the same LAN MAC address "00-03-64-00-01-24". This seems to be a bug on D-link's part  -- it weird but at lease another person experienced the same problem and posted about it on the dslreports.

I've tried upgrading one of the routers to the latest beta code but that didn't change the MAC. This is the only reason I want to downgrade -- to see if that will give me the old LAN MAC again.

And I don't know why D-link would run a forum but not properly staff it by at least posting progress they have on the routers, or release official words on the problems we receive. I can understand that they don't want to turn the forums into a tech support channel, but running a forum and keeping mouths shut frustrates their customers. I, for one, am likely not buying another D-link again after reading all the negative comments and seeing virtually no response from D-link. D-link, if you are actually here, it's time for you to act. You are driving your customers away.