Lastly i figured out a trick to enable telnet on port 2323. what needs to be done to enable it is go to http://192.168.10.1/webcmd.shtml. this is a hidden web page in the router. type "telnet" into the command box and apply. nothing will show up in the box below but it if you port scan the router afterwards you will see that port 2323 is now open. the default login is "admin" and the password is also "admin". hopefully this is enough information for someone to compile even a small light version of dd-wrt for this device because it is a rather powerful router thats cost effective and the stock firmware sucks.
Good luck. OpenWRT seems to support it, but you would likely have to donate a device and wait for BS to port it.
why would a device need to be donated? between what i have posted, what openWRT has done for the hardware/software there should be no problem for someone thats skilled in compiling dd-wrt to do this. i can provide any information and files from the ones i have right here. if anyone wants a dump of the actual flash i have equipment on hand here that i can extract it and post it up for them.
actually i just pulled a dump from the flash of one of them that had a water issue but i realized this one was flashed with a wonky copy of openWRT so the dump from that one is no good. i will have to pull the one thats in use right now and dump its flash. also im dumping these chips with an MCUmall GQ-4X4 programmer and an SOIC clip . flash chip is GD25Q64C. it can be pulled and reinstalled fairly easy with a hot air soldering station and some steady hands.
If the flash dump of the one that was running openWRT could be helpful i will gladly post it up too. i had both 2.4G and 5G radios working in openWRT.
I guess if you want to be the guinea pig and be the first to find out if it bricks or if it works without it being tested by the developer. How do you think OpenWRT figured it out? Looking at pictures? Honestly, if you have OpenWRT working on it, then what's the boggle? I get it, but I don't get it. If I had the time to re-download 20+GB of source code and dive into another project.... but hey, feel free if you wish.
well having the ability to reflash the flash chip itself externally isnt an issue so bricking it is technically impossible because i can just remove the flash, erase it and flash it back to a stock BIN image and start over as long as i made a backup of it prior to any testing.
i dont like the openWRT interface. DD-WRT is better and more user friendly. luci interface sucks. im not sure how openWRT did it but they only had a basic installation for it without the luci interface and i installed it over U-boot, than once it was on the device i used SSH to setup networking and have it download/install luci separately. it didnt always work well though, sometimes the wireless radios would screw up and it needed rebooted and over all the stock firmware could see more on a wireless scan than openWRT could. openWRT lacks the ability to fine tune the wifi radio or radios specifically and DD-wrt does do that. i want that feature so i can put different antennas on this device and be able to adjust x-mit to compensate for the different antennas.
im looking into trying to do it myself and i dont know where to start honestly. seems like so many different ways to do it but only one way will work. i mean if he would consider doing it i'll provide whatever is needed here without a doubt. i think i've already covered most everything needed aside from the stock flash dump of the OEM firmware from the one working AP. correct me if im wrong but getting the flash dump is as good as if not better than having decompressed firmware from the BIN file right?
i do a lot of automotive ECU reverse engineering which is a bit different from this. car ECU's dont have compression on their BIN files so when we get a dump from the flash we can just load it into IDA pro and go. as for modifications to it we can just edit the code right in IDA if need be to check if its flowing correctly than export the new BIN and flash it right back into the car. in the car world our toughest feat is getting around the flash and eeprom protection placed by the ECU manufacturer because they do not want us messing with the software for performance reasons let along in the right hands firmware can be modified to bypass things like govt mandated emissions control crap. anyhow im lost with all of this dd-wrt development stuff. its nothing like what im used to seeing or working with, its a whole new learning curve.
Joined: 08 May 2018 Posts: 7185 Location: Texas, USA
Posted: Fri Nov 29, 2019 0:47 Post subject:
With modern car control systems, I find it kinda hard to believe there is no file compression. Nav systems using QNX do have file system compression, otherwise, it wouldn't work. But hey, if you say so.
i mean yeah the devices like the multimedia interfaces have compressed operating systems but those are not my target. i work on the ECU itself directly and in a lot of new audi's for example the TCU (transmission computer) for performance applications. like the infineon tricore processor based ECU's dont use a compressed file system along with any of its predecessors. flash file size just keeps getting bigger. i would think eventually there will be compression on them as they are up to 4mb in size on average now. hopefully that happens long after im out of this game and i dont care about it.
how to i go about submitting a ticket for this? can you point me in the right direction with a link?
Where it says, "Bugtracker" on this page. ^^^^^ Upper left.
I'm surprised with a 4mb binary size that those ECUs and TCUs aren't compressed images, but again, not surprised. They have to be read fairly quickly, and I don't think they have any kind of RAM involved?
there is RAM in there too. some of these actually have RAM and RAM mirror. its strange the layout of a lot of these honestly.
Here is the Flash dump of 190200 firmware for this router.