It's solved in the Wiki 
guys, i thank you for your support, but my biggest problem here is flashing anything to the device, not setting up a VM ahah
i hope there's an alternative to desolder the ROM and swapping the chips, otherwise i may just scrap the project for good!
Burial at sea is appropriate, Cap't, if you're even having to consider this..
1 Like
i know that most of you don't care, but i think i've made some progress: i found a possible entry point for the unit!
in the motherboard photo, second photo, there are 4 holes right up to the ROM chip, which is the chip at the left of the heatsinked chip at the center
The number 4 is suspicious, since 2 of them could be for power and 2 for data. They also suspiciously align with the jumper headers.
Do you think that i should follow the route (pun) of the older versions?
At worst i kill it, but it's not the end of the world (a reasonable price to pay for freedom), at best i could get an exciting puny signal back.
like this (i had to break the link):
https://openwrt.org/ _detail/media/netgear/dgn2200/dgn2200v2.jpg?id=toh%3Anetgear%3Adgn2200v2
I searched the previous versions in the search field at the top, and following some links i arrived to this useful page: https://oldwiki.archive.openwrt.org/doc/hardware/port.serial
(EDIT; for reference, the new version: https://openwrt.org/docs/techref/hardware/port.serial)
There is a 4, so let's name the following pins to its right 3, 2, and 1.
As a basic electronics hobbyist, i couldn't find a "common ground pin" , so i tried various locations, like: connections of the power plug into the motherboard (worked), casing of the power button (worked), casing of the USB (didn't work), the always present green background in the board (didn't work), Y200, whatever the hell it is, located under the CPU (worked), the copper hole next to it (worked).
Pins 4,3 and 2 offer the same behaviour:
voltage: 8.4 V
resistance: infinite
pin 1:
voltage: 12 V
resistance: <20 Ohm
voltage was measured with the unit turned on, but only to the power plug connections, not to the other points i tried for resistance.
It seems that is not a serial... 
I would suggest opening a new thread for the device in the #hardware-questions-and-recommendations section.
The people who really get into the hardware aspect of this tend to congregate there, and might be better geared towards addressing hardware specific questions.
And I care 
If for no other reason than to up-cycle what is essentially e-waste for just a little bit longer. Go, keep at it! 
1 Like
thanks for all the help!
1 Like
Hi, here is the report for the day.
There are 3 ways to interact with the device: firmware update, telnet and serial.
Serial was discussed in the previous post.
I tried using the update firmware.
I downloaded the firmwares from this site and analized the global one a bit.
once you extract, you find a "img" file, and if you open it with an hex editor you see that is made by a strange header 512 bytes long with "sercomm" and other strange random letters, then a ZIP file. if you cut the rest of the file (address: [512 ; lenght-1] ) and save it, you obtain a perfectly functioning zip, that contains a 31 MB file, which i think it's the real ROM image.
the problem is that if you invert this process the firmware update screen tells you that the firmware is corrupt, so maybe there's some nasty check. I don't know how it would be implemented, given that the header is made mostly of 0x00. Maybe it could be possible to reverse engineer the algorithm from the ROM, but hash functions are not invertible, so it would be very difficult to produce a valid firmware.
Now for the telnet method.
After a bit of fiddling, i discovered (or better, recalled, since last time i did this was 2 or more years ago) that there is an user writable folder, called /home. There are some nice utilities, like dd and vi, but these are very minimal. What i discovered is that in telnet you can execute scripts, it's not blocked like in todays android devices. So obviously the next step was trying to run a true program, compiled in MIPS. Since we have ~ 10 MB of free RAM, there is plenty of space for a low level program, and the hope is that with some C tricks to be able to trigger the write to the ROM, a thing that the original firmware is doing. Maybe this operation can only be performed by rebooting the device in a particular mode, like the "recovery" of smartphones, and doing so in C is difficult or impossible? The program would be loaded from the USB to the /home directory, by simply mounting the device like you would do on a desktop Linux.
Anyway, i entered a rabbit hole that is really deep, since it involves cross compiling.
There are some results on google, but here's two of them: one is an SDK called codescape, that unfortunately is somehow unable to LINK THE MOST BASIC LIBRARIES. When i successfully compiled the most minimal C program ever, a return statement, the router console spitted out an "illegal operation" error. curious.
The second try i made was installing mips-linux-gnu-gcc on Windows subsystem for linux. It compiled nicely, but when run, it said "not found". Interestingly, i remember having received this message on my desktop computer, when trying to run 32 bit x86 software on the x64 linux PC. It was solvable, but it required installing a bunch of libraries, that we can't do on a ROMmed device. I tried launching the compiler with an "-march=mips32" option, but it produced an exact copy of the previous file.
Maybe you are right, it's not worth the effort even for just the fun of doing it, there will be much more easily hackable devices.
The topic is marked for closure after 10 days, If i ever find something new (difficult to do that in such a short timeframe when you literally need to compile a compiler), can it be reopened by sending a private message to a moderator?
bye
this may even be my last post for a long time! when the warranty of my recently acquired netgear product will expire, in one and a half year, i will surely try something! it's a wifi 6 access point with 128/128 MB! (that's why this morning i made the mistake of saying "32/32" instead of "32/64", because i was confused with that much cooler hardware that has the same dimensions for both!)
Since there is no real solution (=OpenWrt image) yet, I have unsolved the topic now, which leaves it open.
2 Likes
You can always explore OpenWrt on the qemu targets or x86_64 if you have a spare beater box sitting around (or one of the RaspPi targets if you have one of those sitting around).
I believe there are docker containers that you can make and run you can use for testing the build system and exploring how it works as well.
1 Like