Can i obtain the original keyfile when i decode i file ( for re-encoding)?
Thanks a lot
No. The key is not in the file, only an HMAC-MD5 hash of the key and some of the data in the file.
supouse that i have a encoded file, y can`t decode it, change it and re-encode it because i haven't got the keyfile?
You are right. You cannot decode/encode the file because you don't have the keyfile. You can decode the file and encode it back with a whatever random key but it is not "authenticated".
When i decoded the file there where 2 md5 keys in it, can i use them to re-encode the decoded file?
can i use this ?
no, because they only provide information about the previous encoding.
your new configuration will have new MICs (still only the CTMS-MIC is key-dependant, and this is the one verified against the CTMS). the CM-MIC is used by the CM to test the config file integrity.
private keys can be upto 64-byte long. but does anyody know if CTMSops usally use 64-byte long random generated keys or just simple mnemonic alphanumeric keys?
They can use whatever they like ... I suppose they use random keys most of the time since this is not something you would need every day.
I was thinking of a brute-force attack with a reduced alphabet, but it seems that the attack would be infeasable... O(256^64) is quite alot...
MD5 benchmarks report 48 MB/S on a pentium (RFC 1810 and "Performance Analysis of MD5-Joseph D. Touch"). If we consider that the length of the data is 512 bytes aprox (bytes of the configuration setting fields plus CM-MIC), it will process about 100000 keys per second, taking 10^143 years!!!!
Wouldn't it seem plausable to generate a new Cm MIC corresponding to the edited file (a new hash), and repackage the old Cm Ts MIC? The Cm Ts MIC is the only hash that is key dependant and the CM doesn't touch it -- it doesn't have the CMTS key anyway, right?
When I tried directly transposing the two hashes from a file that worked onto one I edited, I got an as expected Failed Message Integrity Check on the modem diag. However, what would happen if we generated a new MD5 to describe the new file and transposed the old Cm Ts MIC?
The CM only sends one key, the Cm Ts MIC to the CMTS during a REG-REQ, right? So it should work??
The encoded file is a succession of TLVs (type-lenght-value) describing the desired cable modem (CM) configuration. The last two TLVs hold message integrity check: the CM-MIC and the CTMS-MIC respectively. The CM-MIC is used by the CM to test the config file integrity. The CTMS-MIC is key-dependant and verified against the cable modem terminal server (CMTS) during the registration process. The registration is needed to access the service.
The CMTS-MIC is calculated with the HMAC-MD5 (rfc2104) hash algorithm. The input data is: the key, the CM-MIC and some sensitive TLVs entries including the MaxCPE and MaxRates. All this information (including which TLVs are picked) is described in the DOCSIS 1.0 Radio Frequency Interface Specification by www.cablelabs.com.
During the REG-REQ process the CM sends to the CMTS the CMTS-MIC and ALL the information needed to recalculate it (i.e.: CM-MIC and TLVs). Then the CMTS recalculates the CMTS-MIC with this info and the key stored within the CTMS. The registration succeeds if the hashes match.
So if you encode your file properly and change the CMTS-MIC to a previous working one, it will still fail. Because the CMTS-MIC calculated by the CMTS won't match yours! (they may have the same key, but they won't have the same TLVs and the corresponding CM-MIC).
Thanks for the explanation. That clears up a lot; It seems pretty full-proof. I am wondering about your comments on a site www.surfboardhack.com. The guy there is writing a distributed MD5 cracking program and estimates it would take only a few days if he can recruit 100 computers with at least 1 GHz processing power, to crack a certain key via a brute force search of the key space. I'm going to load it on 20 computers I have access to with 500 MHz Alpha processors, and I am wondering if it's worth the investment.
there is no way to edit the file and chage the CmMic and the CmTsMic?
The last two TLV (mostly?) hold the CM-Mic and CMTS-Mic respectively. So you have to look for the hex string:
06 10 <CM-Mic=16 bytes> 07 10 <CMTS-Mic=16 bytes> FF 00 00 00
FF 00 00 00 is the file terminator
so how can we make the newly-encoded file 'authenticated', or fool the modem into believe it is authenticated?
where is the original keyfile stored?
There is no way to make the newly-encoded file authenticated unless that you have the key-file. And for those of you wondering, the key-file is not included within the previous file. Only the hash of the key-file rehashed with some data is included (MD5-MAC rfc2104). But there is no way to get it right from it, except for a quite infeasible brute-force attack (read my previous post).
Maybe you heard from someone that tried with any key-file and it worked successfully. It is due to the fact that some cable modem companies do not authenticate the file each time cablemodem is restarted (although nowadays most of them do!).
when i try to encode this using keyfile:
SnmpMibObject .184.108.40.206.220.127.116.11.6.3.0 = 2
SnmpMibObject .18.104.22.168.22.214.171.124.126.96.36.199.1 = 4
SnmpMibObject .188.8.131.52.184.108.40.206.220.127.116.11.1 = 1
SnmpMibObject .18.104.22.168.22.214.171.124.126.96.36.199.1 = 0
SnmpMibObject .188.8.131.52.184.108.40.206.220.127.116.11.1 = 3
SnmpMibObject .18.104.22.168.22.214.171.124.126.96.36.199.1 = 1
SnmpMibObject .188.8.131.52.184.108.40.206.220.127.116.11.1 = IpAddress: 0.0.0.0
SnmpMibObject .18.104.22.168.22.214.171.124.126.96.36.199.1 = IpAddress: 0.0.0.0
SnmpMibObject .188.8.131.52.184.108.40.206.220.127.116.11.1 = IpAddress: 18.104.22.168
SnmpMibObject .22.214.171.124.126.96.36.199.188.8.131.52.1 = IpAddress: 240.0.0.0
SnmpMibObject .184.108.40.206.220.127.116.11.18.104.22.168.1 = 256
SnmpMibObject .22.214.171.124.126.96.36.199.188.8.131.52.1 = 0
SnmpMibObject .184.108.40.206.220.127.116.11.18.104.22.168.1 = 65535
SnmpMibObject .22.214.171.124.126.96.36.199.188.8.131.52.1 = 0
SnmpMibObject .184.108.40.206.220.127.116.11.18.104.22.168.1 = 65535
/* EndOfDataMkr */
i get this error
docsis.exe: at line 6, MaxRateDown value 100000000 out of range 0-29952
the original decoded file had:
The MaxRateDown can be between 0 and 52000000. 100 Mbit/s is illegal (the maximum downstream rate on cable networks is 52 megs). The original file must have been illegal :).
If you want to increase the limit edit docsis_symtable.h and find the line with MaxRateDown and replace 52000000 with 0xFFFFFFFF for example (that would be the maximum of 4.2 Gbit/s :)).
Log in to post a comment.
Sign up for the SourceForge newsletter:
You seem to have CSS turned off.
Please don't fill out this field.