Authors note:

I may have gotten off track, but i think i have covered what it all means...This started out as a small quick tutorial, and turned into a 2 hour ordeal...I just semi prof read it, but I may have made some
errors, so be cool with me as its 1:00am. I hope we can grasp something from this. Now, by me posting this, the wheels of security will move much faster now. My intent isn't to bypass or harm any
ISP's current security, but to expose some flaws/weakness's and what methods can be used right now. This will help to seal those holes. So, in a sense, here are some pretty clear cut
answers/solutions. But the sword has two edges, and your ISP's will read this, along with the MFC's of the Head End equipment, and work to "enhance" their firmware to stop what is said here.

If this doesn't get me a few + rep's, I don't know what to do for you...

Peace

Read below

TLV-11 and docsDevResetNow are more common now with enhanced security.

After seeing the countless questions as to "read my log" or "I cant get an IP"...rather than me rip into some of you for being lazy (which you are), I decided to write a small tutorial. I am using
COMCAST as my reference study, but you can just adapt the config and BPI settings slightly for other ISP's.

First

Let me explain 2 things

In Haxorware, we have 2 references of BPI (base Line Privacy) We actually have 3, but I am not including BPI disabled, as most ISP's in 2010 use BPI+.

Basically, encryption (BPI+ 1.1 enabled/+) between your modem (CM=cable modem) and the CMTS (Head End=HE Cable Company/ISP), and BPI 1.0.

BPI 1.0 was the first level of encryption between you (CM) and the CMTS (HE).

BPI 1.1 was the same but with Quality -of-Service (QOS).

All ISP's use a min. of BPI compliancy 1.0, but more are moving to BPI+ 1.1.with Certificates.

BPI 1.1 or BPI + is encryption with QOS features, but uses the Verisign generated certificate (we call them "Certs"). Which means this.... 

When you went and bought your Motorola (5100/5101/5101U/5120/6120/6220 etc) or Scientific-Atlanta (DPC2100 DPC2100R2 and others) cable modem (CM), your flash chip (Intel/ST/MX/AMD)
was programmed with an HFC MAC, Ethernet MAC and a USB MAC (for those that do not have it, then disregard this). Also a reference serial number was given, and later models had a customer
number put on a label on the bottom.

When you wrote Haxorware over the original flash (putting the firmware over the FATSH) you now have a GUI (Graphical User Interface) to make commands between the shell and you easier.
Basically a CLI interpreter, but the interpreter is the GUI interface.And this makes it easy as you dont have to telnet in and do CLI (command line interface) inputs like in a dos enviornment.

Now, when some of you opened up Haxorware, you may have been told to "change the last two digits of your MAC (HFC of course)" to get on line. The second you did this, and didnt' write down
what these were originally or make a back up of this "flash", you"killed" your Verisign made certificates (CERTS) inside the BIN/Flash of your modem. You basically invalidated, annulled, quashed,
void, voided, nullified these "Certificates". Thus meaning, now follow me.., you could never use BPI + 1.1 as the HFC MAC doesnt verify/authenticate with the certificates that were generated by
Verisign/Motorola/Scientific-Atlanta when your modem was flashed/programmed in the factory. So, its important to keep a copy of the original flash at all times.

O.K...
Now,you take your modem and throw it online, or it has been on-line for a while, but now your getting TLV errors. Basically, BPI or some form of it is being forced. TheTLV-11 error means it's "type-
Length-value" error. This is a small byte (1-4) that is added into the handshaking process between you , the CM, and the CMTS (the ISP).

Now, since the MAC address you have is or isn't on the system, the CMTS will check this. If it is, it will continue the handshaking protocol right up until "Registration Complete" then "Operational".
Presto! You have an IP, but it maybe invalid or you are "walledgardened".

There are really 3 scenarios here, with some options for each..

A TLV-11 error is basically telling you that BPI 1.1 is being enforced. See the 11 in TLV and notice the 1.1 in BPI 1.1? Coincidence, I think not. Big clue right there Boys and Girls.But, we have 2
flavors of BPI 1.1, we have BPI + and BPI + Bypass. 

Now lets define these 2 flavors

BPI + 1.1 is the certificate (Verisign's Certs) must be validated to the HFC MAC and Serial Number ( I also have another idea that the Production run of the board also plays into the certs being
generated), meaning, we haven't fucked with changing these to "get on-line". They are in their original form, not altered. Remember, I said to keep these address's and write them down or make a
back up copy of your flash/Bin.
.
BPI+ Bypass using BPI 1.1 compliancy, but we are not validating our internal certificates. We can use a d11 config now also.

There is BPI disabled where we use a D10 config, but this is being killed as we write this. If your using this, its just a matter of weeks before you won't. And after I write this tutorial, it will be much
quicker thanks to me.

Now, since these certificates are good and the HFC mac is good, we still cant get on line. That is because now, we have to have the HFC MAC provisioned into the cable companies database of
users. And since it isnt or never has, we wont get on-line. basically, we are screwed. A few months back, when we were an "open" system, meaning you could go to Best Buy or Fry's or MY BIG
Electronics STORE, you could take the modem out of the box, hook it up to that cable in your wall, and see a COMCAST or an ISP activation page. This was all done with the idea that the cable
company didn't have to spend the man power and mileage/fuel cost to send a tech out. In a sense, you were the tech as you called up and Boom!, you were on-line with the Customer Service Babe
and now surfing the web...All done in a night and no waiting a week for Mr Cable Service Tech to visit you. See, nice and fast. And the CC (Cable Company) never spent a dime to send a man out
there. You did it all. Hell, they even sell installation boxes (rip-off) that have some splitter and a few pieces of white Rg-6 cable. A nice idea, but dangerous for a person with a pre-mod, as he can
basically by-pass's the whole "Activation" screen.Thus the beginning of the S.Florida mass orgy party that lasted for 5 years. This made Woodstock look like a weekend sabbatical for Born-Again-
Christians.

Now, since we have good certs, but cant get on-line. We have a dilema. maybe the ISP is enabling BPI+ now (1.1). And the problem is, we have never been provisioned on the system. So we will
be sent into the "DNS Dead End". You have all had this, your "operational" but no web or outside world. That lovely walledgarden has some neat DNS re-directs , and basically blocks you from
hosting your own DNS re-direct (Google/Open DNS Level3 etc).

The clue here is you need another MAC that's already on and active (provisioned) in the system. Thats why we need to sniff (CMSNIFF/DHCP/Force/Solarwinds etc..) OUTSIDE our NODE/CMTS.
And we need a MAC thats on another NODE so we wont have a MAC collision on our NODE and knock us and them' off every 3 minutes as we both try to handshake and fuck each other up. Doing
this will get the immediate attention of your Senior ISP Engineers, as they have to keep their valid/paying customers on-line. So the solution? Send out a tech and replace the customers modem
with another, which stops the MAC collisions and kills you. But you were dead as you and the valid MAC were on the same NODE. As I have said, move away...and sniff for some MACS. Once you
have some, head back and use each one but remember to spoof your computers NIC each time, as we don't want to bind our NIC to each "MAC" we try...As each MAC trys to handshake, look at
the config that is pushed for it. This is important as you will have to spoof this string in the stealth settings, or un check "Disable Firmware updates" and allow the new Firmware to be pushed, then
re-write/program Haxorware. I dont recommend this, Only if you know what your doing and you have alot of time on your hands...

So, try and watch the log and see what errors , if any, are occuring. I imagine BPI+ wont fly, as your new MAC doesn't have matching certs inside. So , now we try BPI + Bypass and we should be
golden using that d11 config...

This should work.

Now, there is one more thing, and its the last thing. 

Take this scenario. You know a friend over on the other side of town and he has a paid/valid account. its a 5100 or 5101 or whatever. You ask him if you can dump his flash. Now, you re-flash your
pre-mod with his flash, and also find out what his NIC/Router's MAC is and you spoof that also. Now, you can use BPI+ as your certs match. In a sense a true 1:1 "clone". Now, this will work, but the
feature of enabling MAC Cloning/killing will be implemented much faster if this scenario is played out wide scale.

So...there you go.

As for looking to see what the current firmware version is, save the config file being given by the TFTP server. Save it in a folder, Use Vultureware to open it. remembering to tell Vultureware to use
"all files" when "looking" in the search box.

Then Open it up, and look all the way towards the bottom. thats the firmware your CMTS expects to see from you ...

I used an older 6120 cm..So its not current as for what is being used today.

The config will be in the TFTP filename.I have erased a few things as to not allow my location to be known. Save it and then open it up. the firmware will be towards the bottom.
See the config I opened up
Resized to 94% (was 1023 x 523) - Click image to enlarge

Scroll all the way to the bottom

o 94% (was 1023 x 549) - Click image to enlarge

Now, the firmware I have posted is what is shown here, but as you can see, in Vultureware, use the firmware string up to NOSH. nothing else after that.
Footnote:

Use this as a technical reference related to TLV-11

CM Configuration Files, TLV-11 and MIB OIDs/Values

The following sections define the use of CM configuration file TLV-11 elements and the CM rules for translating TLV-
11 elements into SNMP PDU (SNMP MIB OID/instance and MIB OID/instance value combinations; also referred to as
SNMP varbinds).
This section also defines the CM behaviors, or state transitions, after either pass or fail of the CM configuration process.
For TLV-11 definitions refer to [DOCSIS 5; Appendix C].
3.4.1 CM configuration file TLV-11 element translation (to SNMP PDU)
TLV-11 translation defines the process used by CM to convert CM configuration file information (TLV-11 elements)
into SNMP PDU (varbinds). The CM MUST translating CM configuration file TLV-11 elements into a single SNMP
PDU containing (n) MIB OID/instance and value components (SNMP varbinds). Once a single SNMP PDU is
constructed, the CM will process the SNMP PDU and determine CM configuration pass/fail based on the rules for CM
configuration file processing, described below. However, if a CM is not physically capable of processing a, potentially
large, single CM configuration file generated SNMP PDU, then the CM must still behave as if all MIB OID/instance and
value components (SNMP varbinds), from CM configuration file TLV-11 elements, are processed as a single SNMP
PDU.
In accordance with [RFC-3416], the single CM configuration file generated SNMP PDU will be treated “as if
simultaneous” and the CM must behave consistently, regardless of the order in which TLV-11 elements appear in the
CM configuration file, or SNMP PDU. The singular CM configuration file generated SNMP PDU requirement is
consistent with SNMP PDU packet behaviors, received from an SNMP manager; SNMP PDU varbind order does not
matter, and there is no defined MAX SNMP PDU limit.
The CM configuration file MUST NOT contain duplicate TLV-11 elements (duplicate means SNMP MIB object has
either identical OID or OID from the old and new MIB that actually point to the same SNMP MIB object). If duplicate
TLV-11 elements are received by the CM, from the CM configuration file, then the CM MUST fail CM configuration.