NVG510 Fixer -- An Android Application

New Application/Method

Someone by the moniker of Blend3r contacted me with a new method of rooting both the NVG510 and NVG589 modems. It does require downgrading the firmware, but it looks easy enough to execute. He provides a Java app, or a write up on how to do it manually. I did a cursory check through the Java code while writing this, but he can of course change it at anytime. I trust him enough to link to him, but if you're security paranoid it is best to do the DIY method instead of using his app.

Anyway, his website is http://nvg589.tk/

Do not contact me about problems with his tool/method unless you think it's a virus or something like that (so I can unlink it). I looked through it and it makes sense to me, but I by no means support any of these. Don't ask me for help on how to do it, etc etc.

(the rest is left here for archival/historical purposes)

App was pulled from Google Play. The app violated Google's ToS out right, so there's nothing I can really do to appeal it and get it listed again. So, I'm making it free for everyone to download and side-load on their android device.

Download the latest binary release here: http://earlz.net/static/com.earlz.nvg510fixer.v2.2.apk

Also, this application is now open source! (albeit very dirty source code) You can find the source code on github.

I was selling it for $3 on Google Play, so if this app helps you, consider donating. My paypal address is earlz -at- earlz dot net. My Bitcoin address is 178DgR2aZcHeYHhXZwtvcJ5RD13Y6YMQBf, or my Dogecoin address is DLY7Vh8oDYLRxQLFAg2PruA15zFMRqoXGu.

About NVG510 Fixer

I get a lot of people coming to this site every day for fixing problems with the AT&T U-Verse NVG510 modem. I found the information to fix the common problems and root it. However, the procedure for fixing this is a bit technical. So, I made the Android application NVG510 Fixer. An Android application makes it a lot easier for you, but I also get to make a tiny bit of money along the way (have I mentioned there is a baby on the way!?)

First off, make sure the IP address of your modem is correct. If you don't know what an "IP Address" is, don't worry about it. This should only be different if you explicitly set it differently (which there is no reason to do)

Second, you'll need to enter in the password to the device. This should be written on a sticker on the modem labeled "Device Access Code". It should be a 10 digit number. Type that in.

What these buttons do

Now, you have a few different options:

  1. Enable Telnet -- If you know what this is, you may be interested in it (It'll be on port 23)
  2. Disable Telnet -- Everything here will enable telnet. It shouldn't be terribly dangerous to turn on since it's password protected, but if you're paranoid about security, you can disable it afterwards
  3. Fix Redirect -- This is the infamous "Potential Connection Issue" or /cgi-bin/redirect.ha problem that hijacks other websites and is extremely annoying. Click this button and you'll never see that page again(note: you may have to restart your computer/browser if you are currently seeing it)
  4. Enable UPnP -- If you're a gamer, this option is useful to you. This enables Universal Plug And Play, which is a long way of saying that you can have an Open NAT type without having to do anything else
  5. Reboot -- Finally, you can restart the modem remotely if you're feeling lazy

Potential Problems

There are a few different issues that could happen with this. I'll try to point you in the right direction

  • I keep getting "login appears to have been unsuccessful" -- Make sure you're using the "device access code", not the "wireless network key". Also, make sure that when you go to http://192.168.1.254 in your browser that you get the AT&T modem page.
  • I get "no route to host" -- Make sure your devices's wifi is connected to your NVG510 access point
  • I get "operation timed out" -- You might have to try pushing that button once more
  • I get "connection refused" -- sometimes it takes a few seconds to enable telnet(which every other button relies on). Wait a few seconds and try again
  • Your application force closes! -- That's not good :( Send me an email at earlz -at- (this website name) or post below in the comments and I'll try and fix it

After Factory Reset

If you (or AT&T) does a factory reset of your modem, you will have to do this again. However, if your modem loses power and resets, you shouldn't have to run this again

It didn't work!

If you were seeing the "potential connection issue" page, and afterwards your browser gives an error like "server timed out" or "host not reachable", then you may actually not have internet. In that case, call AT&T and hope for the best :) This application will not solve issues with your phone line!

If it didn't do what you wanted, request a refund!

Where is a free version?

I know it's a bit tacky to charge for such a simple application, but I think it's justified in this case. I've spent plenty of time getting to know the NVG510 and helping other people with it, as well as preparing all of the information for publication here. So, I think it's fair. If you don't like it, I will always provide the slightly more technical version for free. See this blog post for details on how to do that.

What's next

I'm not sure. I want to add DNS server fixing, but I don't think I'll be able to fit it in. I'm using Xamarin Android Starter Edition. As such, I have limitations on how complex and big I can make my application. If you want to donate $300 for me to obtain a full license, I'd love you forever :)

Factory Reset

This will completely reset your modem as if AT&T just shipped it to you. It will undo all configuration settings

Bridge Mode

Check the other published info (stub)

Posted: 8/3/2013 8:06:41 PM

Introducing NetBounce

So, I've been working on a quick project called NetBounce. It's basically a nifty tool to test HTTP clients and dump the data they send somewhere, without actually running your own HTTP server. This also supports HTTPS, which means it supports clients which do not allow SSL certificate errors.

Anyway, my main points of making it was because, eventually I want to expand on it to include programmable responses and this is a very good start, and because it's a valuable tool for a project I work on at my job.... And because it's cool and I've always wanted a test project with HTTPS support

Posted: 6/30/2013 6:46:11 PM

Hacking the 2-Wire

So, I've been trying to find an exploit in the 2-wire modem I received. In my journeys, I found one guy who has already done a lot of work on it. His blog is here

Now, here is a quick summary:

  • It uses a TriMedia SoC with a proprietary instruction set
  • It uses some kind of *nix
  • It has an SSH server, but it ships disabled
  • It has an exposed JTAG connector, but it's very involved to try to get anything out of it.

He's ran arbitrary code on it, but he's failed at flashing it so that it uses it's standard firmware, but with sshd enabled.

So, I'm now refocusing my efforts on finding an external (black-box) exploit against the DNS and HTTP servers. I've been poking around the HTTP server, trying to find a simple command-injection type exploit, but even where it looks like it should work, it just doesn't. This seems quite hardened. The only significant thing I've forced it to do is to run out of memory (apparently the HTTP server doesn't have a maximum request size)

The DNS server, however, I've already found a bug with. It apparently doesn't clear the response memory properly... So, if I go to facebook.com and then I go to the DNS server and send an invalid commmand, it'll send back a garbled response with a mention to facebook.com. That's a pretty scary privacy flaw heh. It also has recursion disabled, so the DNS server seems quite weak, but I've never tried to exploit DNS

Happy hacking

Posted: 6/1/2013 8:42:45 PM

Hacking Another Modem

So someone was nice enough to donate a 2-Wire 3801HGV to me. For what purpose? I don't have U-Verse! Why to root it of course! Apparently no one knows how to make a decent modem these days. So, my goals for this are to get as much info as possible, hopefully find a remote exploit like I did with the NVG510 and publish what's possible and what's not, as well as lay the groundwork for future hackers that probably know a lot more about this stuff than I do. My primary goal at this very second is to get a serial port working and get a root shell.

I'll publish more as I work through this

Posted: 5/21/2013 12:43:19 AM

My first DDoS attack, kinda

Enter my home town: Wilburton, Oklahoma. A small town(~3000 people) you've probably never heard of, and probably won't again after this article. When you think Oklahoma you probably think back woods and redneck, not computers. You're usually correct, but I didn't quite fit that stereotype. This is how I came to be banned from using the computers at my high school for a semester.

How I got here

I figured out what programming was around 13 (7th grade). Instantly fell in love with it. So much so that I'd stay up til 3 AM on school nights learning more about it, leading to failing grades until some parental intervention stepped in.

So, I knew my way around a computer. I was young. Just the right kind of person to be a bit dangerous. Luckily I never enjoyed the hacking scene and never crossed over to the script kiddie stuff, but I knew the basics of vulnerabilities.

The day the internet broke

I was a junior the year this happened. It was sometime in the first semester. There is usually an inherit trait among programmers: curiosity. A yearning for wanting to know the consequences of a previously untried action. My lunch periods usually consisted of boredom. Recently the blocks at the school had been relaxed, so flash games could be played in the library. Hence, that was where me and my friends went to during our free time. Someone mentioned something about the command line and hacking. I don't quite remember what led up to it, but I ended up typing something like this:

ping -n 10000 -l 10000 1.2.3.4

The IP(1.2.3.4 is just a placeholder)) I used was the particular IP returned when content was blocked. They did block some content, but it wasn't horrible yet(at some point my own website got blocked for flash games. Ruthless!)

For the non-technical people reading: This is a command which basically says "send this huge message to a server and tell it to send back a huge reply". This command took me a tiny bit of research (using ping /?) to even know. I wasn't a black-hat by any means.

So, the technically minded out there are thinking "there is no way this would break anything"... Well, it didn't.. but then I ran it from 4 other consoles on the computer. At this point I started to hear "hey is the internet slow for you?" asked around the room. This is where I made the naive mistake of running with it. So, I opened like 10 command lines on this computer running this crude flood ping. Then, I went to the free computer beside me and did the same thing there. I think I did it on a total of 4 computers.

And then everything stopped working

I did not expect what came next. I had expected for there to be fairly strict controls on bandwidth. I thought I just maxed out the router in the library. Like the young naive teenager I was though, I left it running... on all 4 computers.

I was in 5th period when I started to realize what I had actually done. The teacher tried to load something on the internet and it wasn't working. "Connection timed out". I would later find out that I had brought the networks of the high school, middle school, elementary, and portions of the college to a stand still; as well as inflicting some damage on the IP address I used

About 30 minutes later it started working... another 5 minutes later, just before class was over, the principal knocks on the class' door. "I need to speak with Jordan".

"Ah shit."

So, we meet in the principal's office. My friend Joe is also there, and the IT guy. He starts saying that someone maliciously attacked the school network and their upstream provider for censorship. My friend Joe stares blankly and says "I have no idea what you're talking about." At this point, I know there is no point in not confessing, so I do. "Yea, he didn't have anything to do with it. I did it".

I can't remember of what follows but I was scared out of my mind. Not of police being called or whatever punishment they were going to arrange. The only thing on my mind was how much trouble I would be in when I got home. I got in-school-suspension before for some stupid thing. I was assigned 3 days of it... That was the worst month of my life though at home.

Anyway, so he sends me back to class and says he'll decide my punishment. Later he calls me back in and hands me my sentence "You can not touch a computer for the rest of the semester". Luckily, I didn't have a programming or typing course. I had both the next year.

Somehow, I manage to never have to tell my parents. They didn't find out until I was moved out.

It's hilarious looking back on it, but man was it scary when it was happening.

Unforeseen Consequences

This lead to interesting situations. The IT guy was usually not on premises, so I would literally get called out of classes to fix some teachers' computers. During this time, I had to walk them through what to do, since I couldn't touch the keyboard or mouse. That was annoying, at best.

The most awesome part of this story is that I landed my first programming job literally, without a doubt because of my fame from crashing the network. My first boss had a son who was a grade below me. He was complaining about how he can't find anyone who knows anything about computers in this small town. His son popped off that I do. This conversation took place in the drive through of McDonald's. I happened to be working drive through. So, I say "that'll be ..." and he proceeds to ask "Hey what programming languages do you know". Completely caught off guard I start saying the last language I used. "C++". He gave me his business card and we exchanged numbers. About 2 months later I graduated from high school and began working there gaining vital experience right out of the gate.

I had quite a bit of fun with other stuff in high school as well.

Other "hacks"

CD_Opener

I wrote a program called CD_Opener. It was my first real program to use threading and the Win32 API at the same time. It was a simple and stupid program. It did nothing but open a pop-up window with just an "OK" button. In one thread it would keep your CD drive open no matter what, in the other it told a story through these popup windows you clicked through. There were two versions, titled "ending" and "nonending" The nonending version told the story so that it fell into an infinite recursion along the lines of "and a dialog box opened on my comptuer... and do you know what it said?". There was no way to kill it other than to use task manager. The ending version was more polite and eventually the story did come to an end

After showing my friends this program(and how to run it), it was not uncommon to come in to the library to see 6 computers with their CD drives stuck open and a familiar popup dialog.

Getting around censors

At one point I built a small PHP script to dumbly download whatever files I told it to and give me a link to it hosted by my server. This was only effective though for flash games and other single-file things.

The unfinished senior prank

I found an absolutely brilliant vulnerability in the high school network my senior year. Basically, all the computers used a common "student" account. The student account was of course just a template. When a student logged in, it copied over the template. Changes in this way didn't persist.

However, the huge flaw with this design was that I found I way to put my own files into the template student account. I tested it with a small batch file and logged in with another computer and indeed, it did run on startup. I then proceeded to delete the batch file. I thought long and hard about writing a senior prank program that would run on almost every computer on the school at a certain time of day. Nothing harmful or distasteful, but not something one would forget either.

I ended up writing a stub program, but never finished it and as far as I can remember never exploited this vulnerability. I vaguely remember leaving a text file in some obscure folder, but I probably ended up deleting it after a while.

Many more vulnerabilities lie here, but I won't go into them here. Our IT guy didn't have the best knowledge of basic security.

Conclusion/Disclaimer

If you're under 18 and reading this, Please don't try to break your school's network. There are many more positive ways to get a reputation. My school was easy on me. I have read(as an adult) about similar (trivial) cases of such things where the school involves the police and the kid receives a record that'll stay with him for life.

Posted: 4/18/2013 3:45:49 AM

A Proposal For Spam-Free Writeable APIs

I've been having an interest in Bitcoin recently, but it would appear I'm too late to the party to make any money on mining. So, what's the next best thing? Taking their idea and using it elsewhere.

The idea behind Bitcoin is to make a particular thing a rare commodity. Now let's pretend we have a website like say http://stackoverflow.com We want to make a public API for it that is writable. Current options appear to be

  1. API keys which require a human to register
  2. ????

I'll throw a second option into the mix. "API Coins" which require a fair bit of computing power to create and are only good in a certain context.

Let's say you wanted to make an account at stackoverflow with a machine that didn't require any human interaction, or rather, didn't require a captcha, valid email, personal info, etc. In theory, a program could register it completely in an automated fashion.

My proposal to prevent masses of spam bots: make it expensive. Use a bitcoin like scheme. Instead of SHA256, I'd go for scrypt because it's so mostly better on CPUs rather than GPUs, and thus capable of executing from Javascript.

So, when you visit the register page I provide something like

  1. Conditions a hash must match (difficultly)
  2. The value hashed must contain a certain provided phrase (to prevent pre-mining of API coins)
  3. That's it!

You calculate a hash which matches and poof! You've got an API key. Ideally, this would be a process that would take no more than 5 minutes on the slowest of hardware. Now, when you need to perform an operation, there will be another hash request, but it won't be as intense as the creation of your API key... but if you're a bad boy, your API key will get banned and you'll have to generate a new one.

Now, how does our site know that API keys are "valid" without pre-mining risk? The key is to make the nonce phrase be random and unique, but slightly persistent. So, when the request is made to get the nonce, it is stored for say an hour. If the API key isn't "found" within an hour or two, it's considered invalid. This would prevent batching of API key creation.

To help to enforce these "hard" checkpoints, if a user, say wanted to post a comment, they'd be given a request like the API key request. A certain difficulty and a phrase to be contained within the pre-hash value. Ideally, this would be significantly easier than generation of an API key.. You could also enforce throttling at this phase by increasing the difficulty for their account as they post more and more things.

The other awesome part about this scheme? It's anonymous other than the IP address in the logs. You can be reasonably sure that it's a human posting while getting absolutely no personal information and storing absolutely no personal information. No passwords needed. You effectively have a sort of private key instead, stored in a cookie or some such.

This also enables awesomely easy registration for users of your API users. "What's an API key?" crops up plenty. Eliminate the need for it!

Some unsolved problems with this approach however:

  1. How to link accounts with it? Assuming you'd want multiple API keys to each API user?
  2. Password to facilitate linking accounts?
  3. What if you lose your key?
  4. What about those mystical FPGA scrypt machines I've heard rumors about?

I might throw together an extremely simple "micro-blog" thing(twitter clone) that uses this concept just to see how it turns out. The hardest thing would probably be implementing scrypt in Javascript

Note One last thing. This isn't to "stop" spam. It's rather to make your site so expensive to spam that it's not profitable. Sure, you can always rent out a few hundred EC2 VMs or some such and compute a few hundred API tokens, but how much is that going to cost? How much do you expect to make from spamming that site?

Posted: 3/31/2013 4:11:10 AM

How to reuse an NVG510

If you are like me and you decide to give AT&T the middle finger and move away from U-Verse, there is still hope you can use the NVG510. It's uses are very limited however due to it's very poor engineering, even with root access.

It's fairly trivial to root and then disable the DHCP server, making it function as a dumb switch. From there, you can now configure it's wifi and such to be a dumb access point.

However, I did this and found the NVG510 is complete and utter crap. It has this really retarded power saving thing (power saving, yet it's still hot to the touch) which basically means "lets cut the wifi power to 1% after being on for 30 minutes"

So, in summary: how to recycle a U-Verse modem:

  1. Douse modem with gasoline
  2. Strike match

Actually though, I think I'm going to begin tinkering with the NVG510's internals. Maybe looking at trying to reflash it and doing other dangerous things... and when I inevitably brick it, proceed to those instructions.

Posted: 12/28/2012 2:30:57 AM

Reworked NVG510 Pages

I reworked the primary NVG510 page. It's not much more informative and should be considered the one stop page for everything contained on this blog about the NVG510 that is useful for people without soldering irons.

Also, this will be the last time I touch that content probably. I don't have U-Verse anymore, and thus don't have to put up with that crappy modem anymore. I still have a modem to test things out on, so if someone manages to make an alternative ROM or something for it, I might try it.. But, otherwise, those pages aren't going to be touched.

Also, of course, if you find out something useful not documented here about the NVG510, I'd love to either link to your site or publish it with credit to you. the DNS problem is the most pesky thing. If someone can fix that and tell me about it, you'd earn 20 internet cookies, from me personally.

If you know anything about the NVG510, shoot me a tweet, comment here, or send me an email (my email address is in the about me

Posted: 12/6/2012 3:58:58 AM

Rooting The NVG510 from the WebUI

New Application/Method

Someone by the moniker of Blend3r contacted me with a new method of rooting both the NVG510 and NVG589 modems. It does require downgrading the firmware, but it looks easy enough to execute. He provides a Java app, or a write up on how to do it manually. I did a cursory check through the Java code while writing this, but he can of course change it at anytime. I trust him enough to link to him, but if you're security paranoid it is best to do the DIY method instead of using his app.

Anyway, his website is http://nvg589.tk/

Do not contact me about problems with his tool/method unless you think it's a virus or something like that (so I can unlink it). I looked through it and it makes sense to me, but I by no means support any of these. Don't ask me for help on how to do it, etc etc.

UNSUPPORTED

Sometime ago, my app got pulled from Google Play. That really bummed me out, then AT&T published a new firmware update fixing all of my known exploits. And well, I just haven't had the motivation to try to find another. I'll leave everything up for reference, and if you downgrade your firmware, maybe it'll work... but I have no idea. I haven't touched my NVG510 in at least 6 months. So, you're on your own. If you end up finding another exploit or can help people here, please give me a link and I can point people to your website.

I have no intentions of picking back up on rooting the NVG510 and NVG589.

One-click Android Application

The fix to common problems with the NVG510 and NVG589 is now available as a push-button $3 Android app called NVG510 Fixer. You can see more information at this blog post. If you don't think it's worth it though, (or want to do crazy technical things), just stick with the free instructions on this page

 

 

Updated for new firmware! :)

This guide has been tested to work with the following hardware and firmware:

  • NVG510 9.0.6h2d30
  • NVG510 9.0.6h2d21
  • NVG510 9.0.6h048
  • NVG589 (unknown)

It's very possible that other Netopia OS based modems are affected as well. There is a Netopia modem used in Switzerland that probably can be rooted with this.

How to root the modem

Warning

WARNING: This is information on how to root your modem. Rooting is to take full control, like rooting your Android phone. It can possibly brick your modem if not used responsibly. USE AT YOUR OWN RISK

Enabling a telnet backdoor and reaching root shell

  1. View the modem's update page, which should be at http://192.168.1.254/cgi-bin/update.ha
  2. Login if you haven't already.
  3. Now you'll want to view the HTML source of the page.
  4. Search for the term "nonce" in the HTML source. You should see something like this:

    input type="hidden" name="nonce" value="815a0aaa0000176012db85d7d7cac9b31e749a44b6551d02"

  5. Hang on to that piece of text and now load my control2 page page.

  6. Take the "value" of the nonce and put it into the text field labeled nonce on the page. 815a0aaa0000176012db85d7d7cac9b31e749a44b6551d02 would be what you put into it for this example.
  7. Load the page up and push Save.
  8. At this point, you might see different things, depending on your browser. You might get a message that the page couldn't be displayed, or you might see some text. If you see the text, make sure that it says "backdoor telnet enabled" or some such. You might also just see the normal Web Update interface with a "invalid firmware image" message. This is nothing to worry about either.
  9. Now, you will need to reboot your modem. You can do this by doing to http://192.168.1.254/cgi-bin/restarting.ha
  10. Now you should be able to login to the modem with telnet on port 28. The username is admin and the password is your modem's "access code" that should be written on it.
  11. Finally, you should see the shell.

To clarify, your telnet session should look like this:

[earlz@EarlzZeta ~]$ telnet 192.168.1.254 28
Trying 192.168.1.254...
Connected to 192.168.1.254.
Escape character is '^]'.

login: admin
Password:

Terminal shell v1.0
Copyright (C) 2011 Motorola, Inc.  All rights reserved.
Motorola Netopia Model NVG510 Wireless-N ADSL AnnexA Ethernet Switch
Running Netopia SOC OS version 9.0.6 (build h2d30)
ADSL capable
(admin completed login: Admin account with read/write access.)

NOS/XXX> 

From here, you can do a few different things. This shell is called nsh. If you want to get to a root shell, just type !. At that point, you can do exit to get back to nsh. Also, if you prefer the shell described in the FCC manual (and used by AT&T techs), you can type cshell after getting to the root shell.

How does it work?

I've found a vulnerability in the WebUI of the NVG510 (and other modems) that allows me to execute any command as root. You can utilize this by sending it a specially crafted HTTP request.

So, I use this to download the shell script at http://earlz.net/static/backdoor.nvg510.sh and execute it on the modem. What the shell script does is it will install a new service into inetd so that it starts a telnet shell, and I configure it using pfs to be persistent. Otherwise, it would go away after rebooting.

Uninstalling the backdoor

The backdoor installed should be fairly safe, being password protected, but if you're especially worried, then it can easily be uninstalled. Just telnet into the modem, get to the root shell by using !, and then type:

pfs -r /var/etc/inetd.d/telnet28

Note! This backdoor will not be uninstalled with a factory reset or firmware update!. Once you've installed it, it's there until you uninstall it! Again, there should be no risk in leaving it there, it will not be internet accessible. But, it's easy to uninstall as well.

Solving common problems

To confirm you're at nsh, you should see a prompt like this:

Axis/1234565678> 

The nsh Console

This console is fairly simple and easy to use, and breaks out everything that you can configure on the modem. But, it is not the console described in the FCC manual.

This is the help text for the console, to help you understand:

Axis/124578433> help
help [command]                 : Get help.
history                        : Show command history.
get OBJ.ITEM                   : Get the value of OBJ.ITEM (ITEM is a
                                 parameter or status). ### Hint: run 'info
                                 OBJ.params' or 'info OBJ.status' to get a
                                 list of the OBJ's parameters and status.
set OBJ.ITEM VALUE             : Set the value of OBJ.ITEM to VALUE.
info INFO [ARGS ...]           : Get the INFO information (expert mode).
new OBJ [NAME]                 : Create an object with an (optional) name
                                 (requires an 'apply')
del OBJ                        : Delete an object (requires an 'apply')
aget OBJ.ITEM ATTR             : Get the OBJ.ITEM's ATTR attribute.
aset OBJ.ITEM ATTR VALUE       : Set the OBJ.ITEM's ATTR attribute to VALUE.
name OBJ [NAME]                : Get or set the OBJ's "name" (specify a new
                                 name to set it).
names [OBJ]                    : Recursively show all object names.
validate [OBJ]                 : Validate OBJ, or the entire database if no
                                 OBJ specified.
apply                          : Apply changes to the database (changes are
                                 NOT saved).
revert                         : Revert the database by discarding your
                                 changes.
save                           : Save the database (rewrites config.xml).
defaults                       : Reset the system back to the factory
                                 defaults (deletes config.xml).
dump [OBJ [LEVELS]]            : Dumps the OBJ's parameters, or the entire
                                 database. Use the optional LEVELS parameter
                                 to limit the depth of the database tree.
sdump [OBJ [LEVELS]]           : Dumps the OBJ's status, or the entire
                                 database.
tdump [TEMPLATE [LEVELS]]      : Dumps the template, or the entire SDB schema.
dirty [OBJ]                    : Displays which parameters are dirty.
run CMD [ARGS ...]             : Run the SDB's CMD command (expert mode
                                 only!).
event EVT [ARGS ...]           : Send the EVT (event number) to the SDB
                                 (expert mode only!).
console [on | off]             : Direct all log messages to this console.
                                 Without arguments, toggles on and off.
log [OPTIONS]                  : View log messages. See "log help" for more
                                 information.
voiplog [OPTIONS]              : View log messages. See "log help" for more
                                 information.
mfg [OPTIONS]                  : Set or view MFG parameters. See "mfg help"
                                 for more information.
mirror [PORT CAPTURE-PORT] | "off" : Mirror Ethernet traffic on PORT so that it
                                 may seen on CAPTURE-PORT. Specify "off" to
                                 turn mirroring off.
resetstats [OBJ] ["all"]       : Reset any statistics the object may have.
                                 The optional "all" argument will recursively
                                 reset all children's stats as well. If only
                                 "all" is given (OBJ is omitted), this will
                                 reset all statistics starting at the root
                                 node.
metadata OBJ.PARAM             : Returns metadata information about a given
                                 parameter.
fwinstall URL | "last"         : Install a firmware image. Use "last" to
                                 reuse the last URL.
crashdump ["erase"]            : Shows the most recent crash dump contents.
                                 The optional "erase" will erase both current
                                 and last saved crash dump contents.
reboot [N] | ["cancel"]        : Reboot the router in N seconds (default is
                                 2). "cancel" argument can be issued to
                                 cancel a previous reboot command.
source FILE                    : Read and process commands from FILE.
. FILE                         : An alias for 'source'.
exit                           : Exit from this shell.
quit                           : An alias for 'exit'.
magic                          : Enter magic mode.
crash                          : Read and Write the Memory mapped registers

Seems simple enough then doesn't it?

Example Configuration

So, let's say you want to enable SSH. The relevant configuration option for this is mgmt.shell.ssh-port. So, to set this, we type this in:

set mgmt.shell.ssh-port 22

This will set the SSH port to 22, rather than disabled. And then, if you're done configuring, you can save and apply the changes by typing these commands in:

validate
apply
save

You don't necessarily have to do validate, but I assume it's safer to use it I think. I believe that this is what happens:

  1. validate will validate the changes to make sure that no data was input in a way that wouldn't make sense (like if nameserver was set to 921.123.45.673)
  2. apply will actually cause the modem to notice the changes and begin executing using those changes you've made
  3. save will cause the changes you made to persist after reboot. I assume it saves it to flash with this command.

That's really about all there is to know. Configuration is super simple.

Configuration

As you can tell from the dump log, there are a ton of configuration options. Here I'll give you a hint to the more useful ones, as well as some configuration stuff to be aware of

DNS problem fix

This is provided for historical reasons, but it's WRONG. This will not fix the DNS problems or let you point it at a different DNS server. I don't know why it doesn't work, but I've received multiple reports that it doesn't. Your best bet in this case is to use the true bridge mode and get your own router

ip.dns.domain-name             = att.net
ip.dns.primary-address         = 99.99.99.53
ip.dns.secondary-address       = 99.99.99.153
ip.dns.proxy-enable            = on
ip.dns.override-allowed        = off

You should be able to change these to something more appropriate. override-allowed should be turned on(otherwise I believe they will be reset by DHCP over the DSL link).

Enabling Telnet and/or SSH

mgmt.shell.ssh-port            = 0
mgmt.shell.telnet-port         = 0

These you should change to what port you want it to run on. Note though that I've yet to figure out the username and password used for SSH. I've searched through both the dump and through the GPL source code and can't find any hints really.

So, to enable these you can just do something like

set mgmt.shell.ssh-port 22
set mgmt.shell.telnet-port 23
validate
apply
save

If you want to enable remote access to telnet and/or ssh (I highly recommend not opening up telnet to the world) you can modify these values to something appropriate:

mgmt.remoteaccess[3].protocol  = telnet
mgmt.remoteaccess[3].port      = 0    XX change this to 23
mgmt.remoteaccess[3].idle-timeout = 5
mgmt.remoteaccess[3].total-timeout = 20
mgmt.remoteaccess[3].max-clients = 4
mgmt.remoteaccess[4].protocol  = ssh
mgmt.remoteaccess[4].port      = 0     XX change this to 22
mgmt.remoteaccess[4].idle-timeout = 5
mgmt.remoteaccess[4].total-timeout = 20
mgmt.remoteaccess[4].max-clients = 4

Enabling UPnP

I haven't confirmed this, but I believe UPnP can be enabled by changing this to on:

mgmt.upnp.enable               = off

Disable "Potential Connection Issue" warnings

mgmt.lan-redirect.enable       = on

Change it to off. lan-redirect is what causes that extremely annoying redirecting to happen when the connection is lost or "has possible problems". What the modem will do is when you request a nameserver, it will, instead of sending back no route, timeout, or the actual name servers response, it will instead make every domain forward to 192.168.1.254, so that you can then load an HTML page that causes a redirect(but doesn't set it to do-not-cache) to /cgi-bin/home.ha... So basically, you click do not show, yet the page continues to try to redirect due to modern web browser caching and the lack of a no-cache directive on the redirect page.

Disabling the DHCP server

conn[1].dhcps-enable           = on

Note that you'll have to configure a static IP to the modem to access it after this. I don't see much of a point in disabling it completely.

True Bridge Mode

A very often wanted feature of the NVG510 is for it to just get out of your way and let your (hopefully more sane) router to deal with all the firewall and NAT business. After quite a bit of experimenting and starting over with default and a bit of an accident, I believe I've figured it out.

Some of the values in the NVG510's configuration "database" appears to be magical, and lots of assumptions have to be made without real technical documentation. So, let's look at the link object that appears to be linked to WAN and LAN connections in an assumed manner.

Here is what was in my modem's dump about links. Your's should look similar:

link[1].type                   = ethernet
link[1].igmp-snooping          = off
link[1].mtu-override           = 0
link[1].port-vlan.ports        = lan-1 lan-2 lan-3 lan-4 ssid-1 ssid-2 ssid-3 ssid-4
link[1].port-vlan.priority     = 0
link[2].type                   = ethernet
link[2].mtu-override           = 0
link[2].supplicant.type        = eap-tls
link[2].supplicant.qos-marker  = AF1
link[2].supplicant.priority    = 0
link[2].port-vlan.ports        = vc-1
link[2].port-vlan.priority     = 0
link[2].tagged-vlan[1].ports   = ptm
link[2].tagged-vlan[1].vid     = 0
link[2].tagged-vlan[1].priority = 0

ptm is the PPP connection. So we basically want for the PPP connection to be routed straight to an ethernet port so our router can handle it. So here is what I did

set link[1].port-vlan.ports "lan-2 lan-3 lan-4"
set link[2].port-vlan.ports lan-1

The first command sets the LAN link so that only the LAN ports 2-4 is used. The next link sets the link for the WAN side of the link. Previously, the port is vc-1. I assume vc-1 is hardwired to magically go to the LAN somehow. Anyway, replacing vc-1 with lan-1 basically makes the equivalent of a PPP bridge.

On the router side, all you have to do is use that port and the modem will do all of the PPP authentication, and I assume MRU shifting to 1500.. All your modem will get is a raw stream from AT&T's servers. So if you send it a DHCP client request, you'll get a response straight from AT&T's servers.

This is the only configuration required as well. This will short through all of the modem's crappy configuration and directly forward it to the first ethernet port(the one closest to the barrel jack power adapter).

And if for some odd reason you need to access the actual modem(such as for reconfiguration), just plug your network cable into another port. The built-in DHCP server runs just as before, except it will never be connected to the internet.

Note: I've had reports that this doesn't completely work when your account is provisioned with multiple static IP addresses. If you have problems and are willing to lend me some time to test things with you, email me at earlz -AT- earlz dot net

Possible Problem: If your modem seems to "hang" when doing apply with the bridge mode configuration and you can't use the save command, then that means you tried to do it from port-1. Change which port on the NVG510 your computer is plugged into(or use Wifi if you're extra brave)

Other Dangerous Things

From this bootloader, you can change a lot of things AT&T probably would frown upon. Basically, you can make it look like another modem. I'm not for sure about this though and will have to test it and research it more. I don't recommend changing anything in the mfg section. If you do one of these kind of hacks, be prepared for AT&T to notice and ban you from U-Verse, your modem to become bricked, or for your dog to randomly die. Don't go too far into the dangerous looking unknown.

Conclusion

The NVG510 is really a decent modem, but has been kiddie-proofed so hard that it hurts. I hope this guide helps you to taking full control of your modem. Also, I don't recommend trying to evade your U-Verse accounts capabilities. I imagine AT&T won't care much if they catch you modifying your modem... they will care if you modified it to reach 16Mbit speeds when you only have a 3Mbit account though, and I'm sure they keep tabs on it. Don't be stupid.

Same goes for trying to boost wifi power or use channels not specified for use in your country. The FCC is real! (btw, don't tell them about my FM transmitter project ;) )

Configuration Template You can dump this for yourself, but to see what Motorola's "template" is for it's configuration options you can check out this pastebin. If you don't know what options a configuration object supports, this is a good bit to look at. Though a few things in the template don't exist in my NVG510 at least and will cause crashes if objects are created. (cifs will not work for me)

Older Versions

This is a new hack that should work on old firmware. However, if you're interested in the old hack(that only works on old firmware), you can see the wayback machine for a historical copy.

Posted: 6/7/2012 12:26:03 AM

Motorola NVG510 Reverse Engineering Information

Goto this page unless you're wanting to do some soldering onto your modem This page is only here now for historical reasons

Motorola NVG510 Reverse Engineering Information

This information is still a work in progress, and if it doesn't work, fries your modem, or kills your dog. Don't blame me just because you listened to a random blog on the internet. USE AT YOUR OWN RISK

Rooting It with the WebUI: There is a way to root the modem without opening it up and soldering on it. See http://lastyearswishes.com/blog/view/4fcff51b4aa5d8385420c706 If you don't want to solder onto your modem, use this. In fact, unless you plan on opening the device up or doing some real hacking, everything should be located there. Again goto http://lastyearswishes.com/blog/view/4fcff51b4aa5d8385420c706

Update: A true bridge mode I believe has been found. Scroll to the bottom for more

Big Update: A way to the root shell has been found. At the serial console shell, all that must be entered is ! and it'll take you there.

Introduction

Hopefully, you reached this web page because you are like me. Tired of the shitty NVG510 modem that you can't do anything about because of AT&T. Well, if you have a bit of electronics know how, and are comfortable with a command line, you can make your modem actually pretty decent. I happened to have an extra one of these things(though both work on my U-Verse account) so I decided what better way to put it to use, than to tear it apart. That said, I'm fairly surprised I didn't fry it in some way. You might not be that lucky. Be prepared to buy a new one if things don't work out.

The Basics

The FCC manual should be the first step in understanding the operation of the NVG510. It can be found at this website

To get access to the described console in the manual however, I'm 99% sure that you must open it up. I've yet to find anything that would allow me to enable the console on an unopened modem.

To open it up, on the underside there are 4 rubber/felt pads. Remove those and under two of them there will be screws. Remove the screws and it should open up fairly easily.

The Serial Port

Now take a look at the circuit board. As you can see, there is plenty of things to modify. There are plug-ins for an external wifi antennae as well as a possible JTAG connector that is unpopulated. You should now look for 4 unpopulated pins labeled "J10". This is a 3.3V/TTL serial port. The square hole is Ground, the hole next to it is 3.3V. The hole next to power is TX and next to that is RX.

Those four holes ended up being fairly difficult to desolder for me. The RX and TX luckily are quite easy to desolder and insert pin headers into, and luckily is all you need. I also soldered a wire into GND, though not properly. Soldering the GND wire is very difficult because it's connected to a fairly large ground plane and I couldn't get it hot enough for all of the solder to melt at one time, so I just (improperly) added some solder to the top of it and stuck in a wire. It's worth it to try reading from the serial port now.

To hook this up to you computer you'll need a proper 3.3V serial cable. Computers natively use 5V serial ports, so they must be level shifted. Also, if you're going to hand-make this cable, you'll need to use an isolator. Or, if you'll feeling extra ambitious, (like I was) you can connect a grounded supply up to it. I managed this by using a PC power supply. I connected GND to the negative terminal, and 12V(yellow) to the positive terminal.. I soldered wires straight to the PCB, but a barrel jack that fits would have been a lot more proper.

Also, the way I accomplished the serial port bit is just use an FPGA I had lying around. My FPGA has a USB-Serial FTDI built in, so all I had to do was make a quick VHDL design like so:

ExtTX <= PCRX;
PCTX <= ExtRX;

And then it did all the heavy lifting, and my FPGA works off of 3.3V already, so it did the level shifting for me.

Now, at first I had a problem in that I never received data from the serial port. I ended up finding a 10K pull up resistor on both RX and TX that I had to remove and then create a solder bridge over. If you're having problems getting any data from the modem, desoldering is worth a try. They are just right of the 4 pins, and are easy to trace out to make sure you got the right two. They are extremely tiny though. Remember, flux is your friend.

The serial port on the modem uses 57600bps, 8-bit data, and 1 stop bit. That information I got from wikidevi

So I simply did

$ screen /dev/ttyUSB1
$ sudo stty -F /dev/ttyUSB1 57600 cs8 -cstopb

Where ttyUSB1 is the USB serial port provided by my FPGA FTDI.

Now, you should be able to turn on the modem and see it's boot log and dmesg. After that press enter into the console and it should pop up something like

Axis/1234565678> 

The Console

This console is actually fairly simple and easy to use, and breaks out everything that you can configure on the modem. But, it is not the console described in the FCC manual.

This is the help text:

Axis/124578433> help
help [command]                 : Get help.
history                        : Show command history.
get OBJ.ITEM                   : Get the value of OBJ.ITEM (ITEM is a
                                 parameter or status). ### Hint: run 'info
                                 OBJ.params' or 'info OBJ.status' to get a
                                 list of the OBJ's parameters and status.
set OBJ.ITEM VALUE             : Set the value of OBJ.ITEM to VALUE.
info INFO [ARGS ...]           : Get the INFO information (expert mode).
new OBJ [NAME]                 : Create an object with an (optional) name
                                 (requires an 'apply')
del OBJ                        : Delete an object (requires an 'apply')
aget OBJ.ITEM ATTR             : Get the OBJ.ITEM's ATTR attribute.
aset OBJ.ITEM ATTR VALUE       : Set the OBJ.ITEM's ATTR attribute to VALUE.
name OBJ [NAME]                : Get or set the OBJ's "name" (specify a new
                                 name to set it).
names [OBJ]                    : Recursively show all object names.
validate [OBJ]                 : Validate OBJ, or the entire database if no
                                 OBJ specified.
apply                          : Apply changes to the database (changes are
                                 NOT saved).
revert                         : Revert the database by discarding your
                                 changes.
save                           : Save the database (rewrites config.xml).
defaults                       : Reset the system back to the factory
                                 defaults (deletes config.xml).
dump [OBJ [LEVELS]]            : Dumps the OBJ's parameters, or the entire
                                 database. Use the optional LEVELS parameter
                                 to limit the depth of the database tree.
sdump [OBJ [LEVELS]]           : Dumps the OBJ's status, or the entire
                                 database.
tdump [TEMPLATE [LEVELS]]      : Dumps the template, or the entire SDB schema.
dirty [OBJ]                    : Displays which parameters are dirty.
run CMD [ARGS ...]             : Run the SDB's CMD command (expert mode
                                 only!).
event EVT [ARGS ...]           : Send the EVT (event number) to the SDB
                                 (expert mode only!).
console [on | off]             : Direct all log messages to this console.
                                 Without arguments, toggles on and off.
log [OPTIONS]                  : View log messages. See "log help" for more
                                 information.
voiplog [OPTIONS]              : View log messages. See "log help" for more
                                 information.
mfg [OPTIONS]                  : Set or view MFG parameters. See "mfg help"
                                 for more information.
mirror [PORT CAPTURE-PORT] | "off" : Mirror Ethernet traffic on PORT so that it
                                 may seen on CAPTURE-PORT. Specify "off" to
                                 turn mirroring off.
resetstats [OBJ] ["all"]       : Reset any statistics the object may have.
                                 The optional "all" argument will recursively
                                 reset all children's stats as well. If only
                                 "all" is given (OBJ is omitted), this will
                                 reset all statistics starting at the root
                                 node.
metadata OBJ.PARAM             : Returns metadata information about a given
                                 parameter.
fwinstall URL | "last"         : Install a firmware image. Use "last" to
                                 reuse the last URL.
crashdump ["erase"]            : Shows the most recent crash dump contents.
                                 The optional "erase" will erase both current
                                 and last saved crash dump contents.
reboot [N] | ["cancel"]        : Reboot the router in N seconds (default is
                                 2). "cancel" argument can be issued to
                                 cancel a previous reboot command.
source FILE                    : Read and process commands from FILE.
. FILE                         : An alias for 'source'.
exit                           : Exit from this shell.
quit                           : An alias for 'exit'.
magic                          : Enter magic mode.
crash                          : Read and Write the Memory mapped registers

Well, seems simple enough then doesn't it? I don't understand the difference in sdump and dump, but I don't think it matters too much.

Now what you want to probably do next is do mfg show and copy those values and then do dump and copy that text.

If you're new to screen, what you need to do is have defscrollback 10000 in your ~/.screenrc and then to copy the text, just push CTRL-A and then [. Then push space to get the first "mark" and then scroll up (with pg-up/up arrow) and press space again. After that, just do CTRL-A and then > and it will write what you just "copied" into /tmp/screen-exchange.

From there, you can easily browse all of the available configuration options.

Configuration

As you can tell from the dump log, there are a ton of configuration options. Here I'll give you a hint to the more useful ones, as well as some configuration stuff to be aware of

DNS problem fix:

ip.dns.domain-name             = att.net
ip.dns.primary-address         = 99.99.99.53
ip.dns.secondary-address       = 99.99.99.153
ip.dns.proxy-enable            = on
ip.dns.override-allowed        = off

You should be able to change these to something more appropriate. override-allowed should be turned on(otherwise I believe they will be reset by DHCP over the DSL link).

So, let's say we want to set the primary name server to 8.8.8.8, google's sane primary name server. We would enter this at the command line:

set ip.dns.primary-address 8.8.8.8

Now if that's about all the configuration we want to do and we want to save our changes and make the modem notice them, we have to do a few commands:

validate
apply
save

You don't necessarily have to do validate, but I assume it's safer to use it I think. I believe that this is what happens:

  1. validate will validate the changes to make sure that no data was input in a way that wouldn't make sense (like if nameserver was set to 921.123.45.673)
  2. apply will actually cause the modem to notice the changes and begin executing using those changes you've made
  3. save will cause the changes you made to persist after reboot. I assume it saves it to flash with this command.

Enabling Telnet:

mgmt.shell.ssh-port            = 0
mgmt.shell.telnet-port         = 0

These you should change to what port you want it to run on. Note though that I've yet to figure out the username and password used for SSH. I've searched through both the dump and through the GPL source code and can't find any hints really.

So, to enable these you can just do something like

set mgmt.shell.ssh-port 22
set mgmt.shell.telnet-port 23
validate
apply
save

If you want to enable remote access to telnet and/or ssh (I highly recommend not opening up telnet to the world) you can modify these values to something appropriate:

mgmt.remoteaccess[3].protocol  = telnet
mgmt.remoteaccess[3].port      = 0    XX change this to 23
mgmt.remoteaccess[3].idle-timeout = 5
mgmt.remoteaccess[3].total-timeout = 20
mgmt.remoteaccess[3].max-clients = 4
mgmt.remoteaccess[4].protocol  = ssh
mgmt.remoteaccess[4].port      = 0     XX change this to 22
mgmt.remoteaccess[4].idle-timeout = 5
mgmt.remoteaccess[4].total-timeout = 20
mgmt.remoteaccess[4].max-clients = 4

Enabling UPnP:

I haven't confirmed this, but I believe UPnP can be enabled by changing this to on:

mgmt.upnp.enable               = off

Disabling "Potential connection issue" and "no connection" redirect loop crap:

mgmt.lan-redirect.enable       = on

Change it to off. lan-redirect is what causes that extremely annoying redirecting to happen when the connection is lost or "has possible problems". What the modem will do is when you request a nameserver, it will, instead of sending back no route, timeout, or the actual name servers response, it will instead make every domain forward to 192.168.1.254, so that you can then load an HTML page that causes a redirect(but doesn't set it to do-not-cache) to /cgi-bin/home.ha... So basically, you click do not show, yet the page continues to try to redirect due to modern web browser caching and the lack of a no-cache directive on the redirect page.

Disabling the DHCP server:

conn[1].dhcps-enable           = on

Note that you'll have to configure a static connection to the modem to access it. I don't see much of a point in disabling it completely, as there is (still) no true bridge mode unfortunately.

Bridge mode discoveries:

There does not appear to be a straight forward PPPoE bridge mode, even with full control over the device. I believe there could be a way by doing some special stuff with the link configuration objects, but I don't see anything obvious so far

Possible money saver

From this bootloader, you can change a lot of things AT&T probably would frown upon. Basically, you can make it look like another modem. I'm not 100% sure, but I believe 1 modem is tied to 1 account, making modems that are used worthless. I'm not for sure about this though and will have to test it and research it more. I don't recommend changing anything in the mfg section.

Conclusion

The NVG510 is really a decent modem, but has been kiddie-proofed so hard that it hurts. I hope this guide helps you to taking full control of your modem. Also, I don't recommend trying to evade your U-Verse accounts capabilities. I imagine AT&T won't care much if they catch you modifying your modem... they will care if you modified it to reach 16Mbit speeds when you only have a 3Mbit account though, and I'm sure they keep tabs on it. Don't be stupid.

Same goes for trying to boost wifi power or use channels not specified for use in your country.

True Bridge Mode

A very often wanted feature of the NVG510 is for it to just get out of your way and let your (hopefully more sane) router to deal with all the firewall and NAT business. After quite a bit of experimenting and starting over with default and a bit of an accident, I believe I've figured it out.

Some of the values in the NVG510's configuration "database" appears to be magical, and lots of assumptions have to be made without real technical documentation. So, let's look at the link object that appears to be linked to WAN and LAN connections in an assumed manner.

Here is what was in my modem's dump about links. Your's should look similar:

link[1].type                   = ethernet
link[1].igmp-snooping          = off
link[1].mtu-override           = 0
link[1].port-vlan.ports        = lan-1 lan-2 lan-3 lan-4 ssid-1 ssid-2 ssid-3 ssid-4
link[1].port-vlan.priority     = 0
link[2].type                   = ethernet
link[2].mtu-override           = 0
link[2].supplicant.type        = eap-tls
link[2].supplicant.qos-marker  = AF1
link[2].supplicant.priority    = 0
link[2].port-vlan.ports        = vc-1
link[2].port-vlan.priority     = 0
link[2].tagged-vlan[1].ports   = ptm
link[2].tagged-vlan[1].vid     = 0
link[2].tagged-vlan[1].priority = 0

ptm is the PPP connection. So we basically want for the PPP connection to be routed straight to an ethernet port so our router can handle it. So here is what I did

set link[1].port-vlan.ports "lan-2 lan-3 lan-4"
set link[2].port-vlan.ports lan-1

The first command sets the LAN link so that only the LAN ports 2-4 is used. The next link sets the link for the WAN side of the link. Previously, the port is vc-1. I assume vc-1 is hardwired to magically go to the LAN somehow. Anyway, replacing vc-1 with lan-1 basically makes the equivalent of a PPP bridge.

On the router side, all you have to do is use that port and the modem will do all of the PPP authentication, and I assume MRU shifting to 1500.. All your modem will get is a raw stream from AT&T's servers. So if you send it a DHCP client request, you'll get a response straight from AT&T's servers.

This is the only configuration required as well. This will short through all of the modem's crappy configuration and directly forward it to the first ethernet port(the one closest to the barrel jack power adapter).

And if for some odd reason you need to access the actual modem(such as for reconfiguration), just plug your network cable into another port. The built-in DHCP server runs just as before, except it will never be connected to the internet.

Configuration Template You can dump this for yourself, but to see what Motorola's "template" is for it's configuration options you can check out this pastebin. If you don't know what options a configuration object supports, this is a good bit to look at. Though a few things in the template don't exist in my NVG510 at least and will cause crashes if objects are created. (cifs will not work for me)

Posted: 6/4/2012 7:54:36 AM