How to uncap?
"Uncapping" refers to the concept of somehow lifting the bandwidth cap many cable modem service providers (MSO's) impose. Some users want to do this in order to improve the speed of their cable modem (CM), but this is obviously theft of service and may have seriously unpleasant consequences.
This article is my attempt at giving a snapshot of the world of uncapping DOCSIS 1.0 CM's as it looks in early 2002. I strongly discourage users from stealing bandwidth. At the same time I strongly recommend the MSO's and cable modem vendors to proactively and constantly improve security.
The Myths
FUCKUPC - "There once was a hack for the Lancity cable modems. A disgruntled client of Chello Netherlands created a program to remove the upstream limitation. Instead of 16Kb/s he had over 300Kb/s upstream. The hack doesn't work anymore." says a well known user as a comment in the Q&A section here on Cable-Modems.Org. According to other sources, that bug was fixed years ago. It is so well known that I doubt it will work on any Lancity installation. Notice the Lancity modem is not a DOCSIS modem, but is using a proprietary protocol - so it never worked for any DOCSIS modem.
easyspeed.exe - "I do see a program called 'easyspeed.exe' pop up once in a while. It is one of the more sophisticated trojan horses (full backdoor, IRC controlled) and frequently advertised as a cable modem 'uncapper' or dialup modem speed increase... (it is recognized by anti virus software)" says Johannes B. Ullrich of DShield.Org. You may find this software using P2P software like KAZAA or Limewire (Gnutella clients).
Tweaks - Changing Windows registry settings (specifically TCP Receive Window) to improve speed. This is not what we mean by "uncapping". This is absolutely legal and merely a way to fix/improve network performance in a specific OS. You can find speed tweaks on Cable-Modems.Org also. Many cable techs will do the tweaks during installation.
The Facts
The DOCSIS standard specifies how CM's are supposed to work in each and every detail. The boot sequence is fairly complex, but in order to understand the following ideas a short version is presented here.
* Offline.
* Scan for downstream channel.
* Receive Upstream Channel Descriptor (UCD).
* Ranging to find tx level and symbol timing.
* DHCP to get CM IP address and gateway.
* Use TFTP to get config file.
* Initialize Baseline Privacy (BPI).
* Receive Time Of Day (ToD).
* Online.
All this is happening on the cable side interface, before the users PC is doing anything. Cisco have a very detailed description on how a cable tech can debug this complex boot sequence on their uBR and CM.
The DOCSIS config file contains CM setting for most parameters like:
* Downstream channel identification
* Class of Service settings
* Baseline Privacy settings
* General operational settings
* Network management information
* Software upgrade fields
* Filters
* Vendor specific settings
The config file is a binary file in a well specified format that can be edited using a special config file editor. This software is not intended for the general public, but does not contain any secrets either. There is actually an open source project developing a DOCSIS config file editor, so anyone wanting to edit config files can easily do so.
The Schemes
A number of different schemes are being rumoured and proposed by various (often anonymous) sources on the internet. Let's take a look at them one by one. If you know of other schemes not covered here, let me know.
TFTP - One proposed scheme is to set up a modified DOCSIS config file on a TFTP server connected to the ethernet side of the CM and tricking it to read the config file from the ethernet side instead of the cable side. This is described in great detail by an anonymous source in this web board post and on a site set up for this purpose: www.TCNiSO.net, www.CableModemHack.net, www.CableModemHack.org or www.CableModemHack.us! (these sites may not stay on-line).
A CM is not allowed to do this by the DOCSIS specs. But according to several unrelated anonymous sources, this is possible on some of the very popular Motorola modems due to what must be described as a bug.
Is this likely to be possible? Yes. During development of cable modem firmware, it is very tempting - often necessary - to allow the CM to boot without the cable side connected. It allows debugging in cases that are otherwise not possible or practical in the lab. My guess is that all cable modems at some point in their development cycle have the ability to boot (and read the config file) from the ethernet side. This is obviously not a feature intended for the shipping version of the firmware.
There are various ways to switch between the debug version and the shipping version of the firmware. One approach is to have the debug features always present in the CM, but just blocking access to them in some way for the shipping CM's. This can be a special value in a non-volatile memory, a short on the PC board (maybe a 0R resistor that gets removed for the debug CM's) or some other proprietary scheme. Another approach is to have two different versions of the firmware, so the shipping firmware does not even include the debug features. Often the two versions would be compiled from the same source code set using various build time switches.
If a user somehow manages to switch in the debug part of the firmware, or trigger some bug to the same effect, this uncapping scheme is very likely possible on most CM's.
The authors of the open source DOCSIS config file editor, describes the situation like this: "By and large, the most popular method of uncapping is by tricking the modem into downloading a configuration file from the Ethernet port - taking advantage of the fact that some MSOs do not enable authentication checking (Message Integrity Check) at the CMTS. At least one popular brand of modem can be tricked into doing this but we suspect many more to be vulnerable."
Shell-enabled CM's - Most if not all cable modems have a shell for debug purposes. This is typically a simple command line interface, that you can connect to using either telnet or a serial terminal. Some CM's also provide a http server to allow a web browser to access some parameters.
There are usually two or three versions of the shell. One (web based) is intended for the end users. The cable techs may have access to a more detailed shell to get more information to help during the install, but still unable to modify any of the DOCSIS settings. During firmware development, the engineers will typically have control over all kinds of parameters internal to the CM through the shell. The shipping version of the firmware is not allowed to accept commands that influence the DOCSIS parameters, but the debug version that the engineers use in the lab in many cases can do all of that.
The uncapping scheme exploiting this "feature" is to get a shell-enabled cable modem somehow and then use the shell commands to modify some parameters. This may be the class-of-service (upstream cap etc.), the CM serial number and MAC address (stealing another users service) and blocking of the automatic firmware upgrades (something the MSO can command simply by putting a new binary on the TFTP server and setting the "Software Upgrade Filename" in the config file).
How users are able to actually get a shell-enabled CM is not well documented, but several possible methods exist. The debug shell may be enabled in some modems by pretty much the same mechanisms as described for the TFTP hack above. Information leaked from individuals working for (or laid off from) one of the cable modem vendors is most likely required in order to do this. The leak could be a binary for flashing into the CM.
The CM is not allowed to accept upgrades from the ethernet side, but this feature may be (almost always?) present during the development, so it may be possible to do this on some shipping modems. Given the right equipment, a flash device can be removed from the PCB of a cable modem, read out, reprogrammed and put back in. I have personally done this in the lab to check a returned CM for flash corruption.
Fake MAC's - By changing the cable side MAC address (often also the serial number) to that of another user (possible someone paying for premium service), the user will be able to effectively steal that users service. Two CM's online with the same MAC is not possible for an extended period of time, and will be logged at the CMTS. So the MSO may track this down fairly easily.
How would a user be able to change the cable-side MAC? One way could be to use a debug shell-enabled CM as described above. Another way could be to remove the non-volatile memory on the PC board holding the MAC address, and reprogram it. This does require special equipment, but in many cases an electronics hobbyist can easily do this. Most modems (if not all) will have a way to program the MAC address during the manufacturing process. This may be using an In-Circuit Tester (ICT) with a bed-of-nails fixture for the specific CM, it may be through the debug shell (that is then disabled before shipping) or some other approach.
The key here is, that the number of devices to look for is fairly small (flash or eeprom devices). Finding the MAC in the content of the storage device may also be fairly simple, as the MAC address is normally also shown on a sticker at the back of the CM.
IP Accumulation - Johannes B. Ullrich of DShield.Org explains "The idea is, that many cable ISPs do not validate IPs at the router and appear to limit bandwidth on a per IP basis. So if a user finds a set of unused IPs (or just DOS's the legitimate user), they can use their IP, forget about DHCP and pool bandwidth that way. I did hear from a number of people that did attempt this successfully.". You may prefer to call this something other than "uncapping", but the net effect is the same.
The normal (DOCSIS supported) way of imposing a cap on the individual users bandwidth is by setting this in the config file to make the CM rate limit it's own upstream bandwidth.
Using a service aggregation device (e.g. Nortel's Shasta, Redback Networks or Cisco's), the bandwidth can also be limited at the router. This is typically done by defining tunnels (PPPoE or similar) for each CM through the router, and then applying a bandwidth cap on each individual tunnel.
This uncapping scheme works only for the MSO's that use the router approach for bandwidth limiting.
Social Engineering - The idea behind the upstream cap is to allow the MSO to sell multiple tier service. A plain cable modem service at say $30 a month with a 256 kbit/s upstream cap and a premium service at say $60 monthly and a 1 Mbit/s cap. If you can make friends with the right individuals at the MSO, trick them into believing you are a higher paying customer or something like that, you may be able to have your class of service setting changed.
The scheme is entirely possible, but I have no documentation on the extent to which this is happening.
Fighting Back
The MSO's and cable modem vendors have a joint responsibility to help fight the illegal and unfair attempts at uncapping. There are actually a lot of things that the MSO's can do, but may not be doing for various reasons.
MIC Checking - The CMTS can enable MIC (Message Integrity Check), which is a feature designed to authenticate the config file in the modem through robust encryption techniques using a shared secret. There is a pretty good description of how this works on page 9 & 10 of this presentation (pdf format) by Wim de Ketelaere and Luc Martens of tComLabs. Even though this is a EuroDOCSIS specific presentation, the same mechanism exists in plain DOCSIS systems. This would prevent the TFTP scheme described above.
Should the shared secret of a cable modem ever be publicly known, this system will no longer be useful for this specific CM model. An attempt at a brute-force attack is not likely to reveal the secret, as the time to test a key is fairly long. But the secret may be revealed by other means - this includes social engineering or other attacks. The simplest attack seem to be to get a "golden" config file froma user paying for premium service, and just use that file unchanged. This situation is not unlike the situation with pay-TV smartcards, that seem to be cracked time and time again even though the (physical) security measures are much more elaborate.
MAC/IP Checking - The service aggreagtion device (router) can check that the IP addresses match the MAC addresses that were assigned to the CPE (end user PC) during DHCP (or statically). This would prevent the IP Accumulation attack described above.
DOCSIS 1.1 - With the BPI+ of DOCSIS 1.1 enabled, the Fake MAC scheme would be prevented. Most MSO's have not yet upgraded to v1.1, but that is expected to happen over time. Problems with theft of service may influence the decision to upgrade.
Other Checks - There are many other checks that the MSO can run as part of regular network monitoring. This may be logging anomalies in traffic patterns and similar techniques.
Some MSO's are reported to use special traffic analysis software to check for NAT, which is not allowed by some service contracts. I find this rather bizarre and prefer the policy adopted by the majority of MSO's, where home networks sharing a single IP are not supported but not banned either. This is not directly related to uncapping, but it shows something about the kind of things that are detectable by automated software analysis at the router. This "rumour" is unconfirmed - if you can confirm it, please let me know!
There are probably many other checks that can be run - feel free to tell me more if you have specific and detailed knowledge.
Who Are You?
Always check your sources. Including this one! For this article I used several sources, myself included. I have been working at two different CM/CMTS vendors for 3-4 years as lead hardware engineer and engineering manager, so that gave me a pretty good feel for what happens during development, test and deployment of cable modems. It also gave me very detailed knowledge of the DOCSIS protocol and some specific CM designs.
Other sources are mentioned in the text when possible - thanks for your help! The rumour mill is also working, but due to the nature of the subject this is mostly anonymous sources. Another source is the concerned users, that see uncapping happening at their "friends", but can't or don't want to do it themselves. Several such 100% "kosher" users have expressed their concern to me that their "friends" are actually stealing their bandwidth due to the shared nature of the cable modem system.
Conclusion
I hope this article demonstrates that uncapping is very likely possible in many cases, that other users are concerned and that the vendors and MSO's can do a lot to improve the situation. This is not meant as an uncapping tutorial, because it is not. The best way to deal with uncapping is to get it out in the open, so the vendors and MSO's can tighten up the security. This helps the majority of users, so all get fair and equal access.
Talking about uncapping is still very much okay to me, and I encourage you to tell me about new schemes and techniques that you hear of. Documented or well-described cases are of most interest. Actually stealing bandwidth is not okay and should have consequences for the user.
"Uncapping" refers to the concept of somehow lifting the bandwidth cap many cable modem service providers (MSO's) impose. Some users want to do this in order to improve the speed of their cable modem (CM), but this is obviously theft of service and may have seriously unpleasant consequences.
This article is my attempt at giving a snapshot of the world of uncapping DOCSIS 1.0 CM's as it looks in early 2002. I strongly discourage users from stealing bandwidth. At the same time I strongly recommend the MSO's and cable modem vendors to proactively and constantly improve security.
The Myths
FUCKUPC - "There once was a hack for the Lancity cable modems. A disgruntled client of Chello Netherlands created a program to remove the upstream limitation. Instead of 16Kb/s he had over 300Kb/s upstream. The hack doesn't work anymore." says a well known user as a comment in the Q&A section here on Cable-Modems.Org. According to other sources, that bug was fixed years ago. It is so well known that I doubt it will work on any Lancity installation. Notice the Lancity modem is not a DOCSIS modem, but is using a proprietary protocol - so it never worked for any DOCSIS modem.
easyspeed.exe - "I do see a program called 'easyspeed.exe' pop up once in a while. It is one of the more sophisticated trojan horses (full backdoor, IRC controlled) and frequently advertised as a cable modem 'uncapper' or dialup modem speed increase... (it is recognized by anti virus software)" says Johannes B. Ullrich of DShield.Org. You may find this software using P2P software like KAZAA or Limewire (Gnutella clients).
Tweaks - Changing Windows registry settings (specifically TCP Receive Window) to improve speed. This is not what we mean by "uncapping". This is absolutely legal and merely a way to fix/improve network performance in a specific OS. You can find speed tweaks on Cable-Modems.Org also. Many cable techs will do the tweaks during installation.
The Facts
The DOCSIS standard specifies how CM's are supposed to work in each and every detail. The boot sequence is fairly complex, but in order to understand the following ideas a short version is presented here.
* Offline.
* Scan for downstream channel.
* Receive Upstream Channel Descriptor (UCD).
* Ranging to find tx level and symbol timing.
* DHCP to get CM IP address and gateway.
* Use TFTP to get config file.
* Initialize Baseline Privacy (BPI).
* Receive Time Of Day (ToD).
* Online.
All this is happening on the cable side interface, before the users PC is doing anything. Cisco have a very detailed description on how a cable tech can debug this complex boot sequence on their uBR and CM.
The DOCSIS config file contains CM setting for most parameters like:
* Downstream channel identification
* Class of Service settings
* Baseline Privacy settings
* General operational settings
* Network management information
* Software upgrade fields
* Filters
* Vendor specific settings
The config file is a binary file in a well specified format that can be edited using a special config file editor. This software is not intended for the general public, but does not contain any secrets either. There is actually an open source project developing a DOCSIS config file editor, so anyone wanting to edit config files can easily do so.
The Schemes
A number of different schemes are being rumoured and proposed by various (often anonymous) sources on the internet. Let's take a look at them one by one. If you know of other schemes not covered here, let me know.
TFTP - One proposed scheme is to set up a modified DOCSIS config file on a TFTP server connected to the ethernet side of the CM and tricking it to read the config file from the ethernet side instead of the cable side. This is described in great detail by an anonymous source in this web board post and on a site set up for this purpose: www.TCNiSO.net, www.CableModemHack.net, www.CableModemHack.org or www.CableModemHack.us! (these sites may not stay on-line).
A CM is not allowed to do this by the DOCSIS specs. But according to several unrelated anonymous sources, this is possible on some of the very popular Motorola modems due to what must be described as a bug.
Is this likely to be possible? Yes. During development of cable modem firmware, it is very tempting - often necessary - to allow the CM to boot without the cable side connected. It allows debugging in cases that are otherwise not possible or practical in the lab. My guess is that all cable modems at some point in their development cycle have the ability to boot (and read the config file) from the ethernet side. This is obviously not a feature intended for the shipping version of the firmware.
There are various ways to switch between the debug version and the shipping version of the firmware. One approach is to have the debug features always present in the CM, but just blocking access to them in some way for the shipping CM's. This can be a special value in a non-volatile memory, a short on the PC board (maybe a 0R resistor that gets removed for the debug CM's) or some other proprietary scheme. Another approach is to have two different versions of the firmware, so the shipping firmware does not even include the debug features. Often the two versions would be compiled from the same source code set using various build time switches.
If a user somehow manages to switch in the debug part of the firmware, or trigger some bug to the same effect, this uncapping scheme is very likely possible on most CM's.
The authors of the open source DOCSIS config file editor, describes the situation like this: "By and large, the most popular method of uncapping is by tricking the modem into downloading a configuration file from the Ethernet port - taking advantage of the fact that some MSOs do not enable authentication checking (Message Integrity Check) at the CMTS. At least one popular brand of modem can be tricked into doing this but we suspect many more to be vulnerable."
Shell-enabled CM's - Most if not all cable modems have a shell for debug purposes. This is typically a simple command line interface, that you can connect to using either telnet or a serial terminal. Some CM's also provide a http server to allow a web browser to access some parameters.
There are usually two or three versions of the shell. One (web based) is intended for the end users. The cable techs may have access to a more detailed shell to get more information to help during the install, but still unable to modify any of the DOCSIS settings. During firmware development, the engineers will typically have control over all kinds of parameters internal to the CM through the shell. The shipping version of the firmware is not allowed to accept commands that influence the DOCSIS parameters, but the debug version that the engineers use in the lab in many cases can do all of that.
The uncapping scheme exploiting this "feature" is to get a shell-enabled cable modem somehow and then use the shell commands to modify some parameters. This may be the class-of-service (upstream cap etc.), the CM serial number and MAC address (stealing another users service) and blocking of the automatic firmware upgrades (something the MSO can command simply by putting a new binary on the TFTP server and setting the "Software Upgrade Filename" in the config file).
How users are able to actually get a shell-enabled CM is not well documented, but several possible methods exist. The debug shell may be enabled in some modems by pretty much the same mechanisms as described for the TFTP hack above. Information leaked from individuals working for (or laid off from) one of the cable modem vendors is most likely required in order to do this. The leak could be a binary for flashing into the CM.
The CM is not allowed to accept upgrades from the ethernet side, but this feature may be (almost always?) present during the development, so it may be possible to do this on some shipping modems. Given the right equipment, a flash device can be removed from the PCB of a cable modem, read out, reprogrammed and put back in. I have personally done this in the lab to check a returned CM for flash corruption.
Fake MAC's - By changing the cable side MAC address (often also the serial number) to that of another user (possible someone paying for premium service), the user will be able to effectively steal that users service. Two CM's online with the same MAC is not possible for an extended period of time, and will be logged at the CMTS. So the MSO may track this down fairly easily.
How would a user be able to change the cable-side MAC? One way could be to use a debug shell-enabled CM as described above. Another way could be to remove the non-volatile memory on the PC board holding the MAC address, and reprogram it. This does require special equipment, but in many cases an electronics hobbyist can easily do this. Most modems (if not all) will have a way to program the MAC address during the manufacturing process. This may be using an In-Circuit Tester (ICT) with a bed-of-nails fixture for the specific CM, it may be through the debug shell (that is then disabled before shipping) or some other approach.
The key here is, that the number of devices to look for is fairly small (flash or eeprom devices). Finding the MAC in the content of the storage device may also be fairly simple, as the MAC address is normally also shown on a sticker at the back of the CM.
IP Accumulation - Johannes B. Ullrich of DShield.Org explains "The idea is, that many cable ISPs do not validate IPs at the router and appear to limit bandwidth on a per IP basis. So if a user finds a set of unused IPs (or just DOS's the legitimate user), they can use their IP, forget about DHCP and pool bandwidth that way. I did hear from a number of people that did attempt this successfully.". You may prefer to call this something other than "uncapping", but the net effect is the same.
The normal (DOCSIS supported) way of imposing a cap on the individual users bandwidth is by setting this in the config file to make the CM rate limit it's own upstream bandwidth.
Using a service aggregation device (e.g. Nortel's Shasta, Redback Networks or Cisco's), the bandwidth can also be limited at the router. This is typically done by defining tunnels (PPPoE or similar) for each CM through the router, and then applying a bandwidth cap on each individual tunnel.
This uncapping scheme works only for the MSO's that use the router approach for bandwidth limiting.
Social Engineering - The idea behind the upstream cap is to allow the MSO to sell multiple tier service. A plain cable modem service at say $30 a month with a 256 kbit/s upstream cap and a premium service at say $60 monthly and a 1 Mbit/s cap. If you can make friends with the right individuals at the MSO, trick them into believing you are a higher paying customer or something like that, you may be able to have your class of service setting changed.
The scheme is entirely possible, but I have no documentation on the extent to which this is happening.
Fighting Back
The MSO's and cable modem vendors have a joint responsibility to help fight the illegal and unfair attempts at uncapping. There are actually a lot of things that the MSO's can do, but may not be doing for various reasons.
MIC Checking - The CMTS can enable MIC (Message Integrity Check), which is a feature designed to authenticate the config file in the modem through robust encryption techniques using a shared secret. There is a pretty good description of how this works on page 9 & 10 of this presentation (pdf format) by Wim de Ketelaere and Luc Martens of tComLabs. Even though this is a EuroDOCSIS specific presentation, the same mechanism exists in plain DOCSIS systems. This would prevent the TFTP scheme described above.
Should the shared secret of a cable modem ever be publicly known, this system will no longer be useful for this specific CM model. An attempt at a brute-force attack is not likely to reveal the secret, as the time to test a key is fairly long. But the secret may be revealed by other means - this includes social engineering or other attacks. The simplest attack seem to be to get a "golden" config file froma user paying for premium service, and just use that file unchanged. This situation is not unlike the situation with pay-TV smartcards, that seem to be cracked time and time again even though the (physical) security measures are much more elaborate.
MAC/IP Checking - The service aggreagtion device (router) can check that the IP addresses match the MAC addresses that were assigned to the CPE (end user PC) during DHCP (or statically). This would prevent the IP Accumulation attack described above.
DOCSIS 1.1 - With the BPI+ of DOCSIS 1.1 enabled, the Fake MAC scheme would be prevented. Most MSO's have not yet upgraded to v1.1, but that is expected to happen over time. Problems with theft of service may influence the decision to upgrade.
Other Checks - There are many other checks that the MSO can run as part of regular network monitoring. This may be logging anomalies in traffic patterns and similar techniques.
Some MSO's are reported to use special traffic analysis software to check for NAT, which is not allowed by some service contracts. I find this rather bizarre and prefer the policy adopted by the majority of MSO's, where home networks sharing a single IP are not supported but not banned either. This is not directly related to uncapping, but it shows something about the kind of things that are detectable by automated software analysis at the router. This "rumour" is unconfirmed - if you can confirm it, please let me know!
There are probably many other checks that can be run - feel free to tell me more if you have specific and detailed knowledge.
Who Are You?
Always check your sources. Including this one! For this article I used several sources, myself included. I have been working at two different CM/CMTS vendors for 3-4 years as lead hardware engineer and engineering manager, so that gave me a pretty good feel for what happens during development, test and deployment of cable modems. It also gave me very detailed knowledge of the DOCSIS protocol and some specific CM designs.
Other sources are mentioned in the text when possible - thanks for your help! The rumour mill is also working, but due to the nature of the subject this is mostly anonymous sources. Another source is the concerned users, that see uncapping happening at their "friends", but can't or don't want to do it themselves. Several such 100% "kosher" users have expressed their concern to me that their "friends" are actually stealing their bandwidth due to the shared nature of the cable modem system.
Conclusion
I hope this article demonstrates that uncapping is very likely possible in many cases, that other users are concerned and that the vendors and MSO's can do a lot to improve the situation. This is not meant as an uncapping tutorial, because it is not. The best way to deal with uncapping is to get it out in the open, so the vendors and MSO's can tighten up the security. This helps the majority of users, so all get fair and equal access.
Talking about uncapping is still very much okay to me, and I encourage you to tell me about new schemes and techniques that you hear of. Documented or well-described cases are of most interest. Actually stealing bandwidth is not okay and should have consequences for the user.
Comments