Keyspace List for WPA on Default Routers - Printable Version +- hashcat Forum (https://hashcat.net/forum) +-- Forum: Misc (https://hashcat.net/forum/forum-15.html) +--- Forum: User Contributions (https://hashcat.net/forum/forum-25.html) +--- Thread: Keyspace List for WPA on Default Routers (/thread-6170.html) |
RE: Keyspace List for WPA on Default Routers - philsmd - 07-16-2017 If I'm not totally (I mean completely!!!) mistaken you are totally looking at the wrong code. The code posted by mrfancypants here: https://repl.it/JMbi/4 is not (just) the key generator. This is a special code (specifically coded for a single check/situation) that was answering this post https://hashcat.net/forum/thread-6170-post-35744.html#pid35744 , e.g. to check if the pwgen () function can generate the correct password candidate if the first 8 letters are known ( mrfancypants even mentioned this here https://hashcat.net/forum/thread-6170-post-35743.html#pid35743). That means, your code does not need the pw_to_candidate_ints () function. Instead, it just needs a loop of all x values from 0 to 0x7FFFFFFF as an input for the pwgen(x) function. This actually should be very obvious. ... and the amount of memory needed (without the search for a specific known and truncated 8 letter password candidate, which was just a test!!!) will be very low (less than 1 KB for sure, it just does some mathematical computation and has a static string pw_charset). That said, the whole discussion about is return (y for y in cands if pwgen(y)[:l]==x) better than return [y for y in cands if pwgen(y)[:l]==x] makes no sense, because a password generator does not need pw_to_candidate_ints () at all. pw_to_candidate_ints () could probably also be replaced by just an external "grep"-like filter (that would have probably avoided this funny confusion, but it probably would have needed to call pwgen () way more often, therefore the decision to implement a search function like pw_to_candidate_ints () makes sense, but just to proof that a specific 8-letter-truncated password candidate is within the whole password candidate list). update: I attach here some example code such that you can get an idea of what *I think* is the actual password generator code: python code (file: nvg599.py): Code: #!/usr/bin/env python little optimized version, ANSI C with custom file I/O buffering (file: nvg599.c): Code: #include <stdio.h> (please do not blame me for the code, I can also not guarantee that it doesn't contain bugs, but hopefully there won't be any bugs in this small code) RE: Keyspace List for WPA on Default Routers - philsmd - 07-18-2017 Please be more specific at which code you are refering to. There are a lot of code snippets within this thread, e.g. 2 for different algorithms, one for searching a (8 char) substring of a specific password candidate etc Furthermore, counting the GB is not always a good idea because the code might create different "types of newlines" (carriage return and line feed vs just line feed etc). This could already "waste" several MB/GB of disk space. It's more clever to count the lines instead. According to Mrfancypants it should have 2.1 billion lines (ranging from 0 to 0x7fffffff, e.g 2147483648 lines). If you multiply 2147483648 * 13 (e.g. 12 char password + 1 new line) = 27917287424 ~ 26GiB (calculated like this: 27917287424 / 1024 / 1024 / 1024). Therefore, 26 GiB (or 28GB, calculate like this: 27917287424 / 1000 / 1000 / 1000) seems to be the correct file size (at least if Mrfancypants's statement about 2.1 billion possibilities is correct). update: writing the password candidates to disk might not be needed and maybe even be much more slower (depending on your disk speed), you could just pipe the output of the compiled version of nvg599.c to hashcat). Using a pipe you would avoid wasting disk space and too much disk I/O. It depends on many factors which of them is slower and which one is faster (or in general: which one has more advantages compared to the disadvantages). RE: Keyspace List for WPA on Default Routers - devilsadvocate - 07-23-2017 I don't know if anyone is looking at the algorithm for the 5268AC (another default device offering from AT&T), but I have noticed that it appears to be a variation on the 599 scheme. I have noticed that both the python and C code for the nvg599 are correctly calculating the first 6 characters for the 5268AC, but the last 6 characters are not. It seems that if you want to be able to brute force a default wifi password for the 5268AC, then you can get all of the output from the 599 python and/or C code, truncate every line to only the first 6 characters, sort, uniq, and then run a hybrid attack (mode 6, Hybrid Wordlist + Mask) with the applicable character set (37 characters). Number of characters ^ positions = 37 ^ 6 = 2565726409 This method is far from time efficient given the number of unique 6 character prefixes that would be produced (multiplied by the number above, a little over 2.5 billion), but could work if you have no functional password calculator. I welcome anyone to prove me wrong. Cross check the first 6 characters from passwords from 5268 devices with the output of the 599 code (both python and C) and see if this pattern is consistent. This pattern has a 100 percent hit rate for me. RE: Keyspace List for WPA on Default Routers - philsmd - 07-24-2017 it could be that for the 5268AC the formula is just a little bit different, e.g while we have the formula 2 ^ 32 + 2 for the 599, it could be that the formula for 5268AC is almost the same i.e. 2 ^ 32 + y with an y different from 2. If the formula is indeed still 2^32 + y also for the 5268AC, you could probably just find the x value (for the function pwgen (x) within my python code, within my C code I used the variable i) that generated the almost correct password candidate and adjust the y value accordingly such that it generates the correct password. RE: Keyspace List for WPA on Default Routers - mrfancypants - 07-25-2017 Since there are 2.1 billion 599-type passwords and 37^6 ~ 2.6 billion possible 6-character strings, odds are good that there's a 599-type password that starts at any randomly picked 6-char string. So, unless you get 100% hit rate for a large number of passwords, this may be completely coincidental. Also, if you used my python snippet to find extensions, some of your hits were invalid (I've just noticed that it does not check if 'cands' fall into 0..0x7FFFFFFF range). I haven't looked too hard into 5268s but I suspect that they are using a very different approach. I did discover that their SSIDs always start with a digit and they never have more than 3 letters in a row. I think that they construct the SSID by picking entries from a large chunk dictionary according to some unknown logic, concatenating them, and truncating to 7. Their passwords likewise always start with a digit. RE: Keyspace List for WPA on Default Routers - freeroute - 08-06-2017 Do you have any info about Tenda and Huawei Routers default wifi keyspace? SSID format (Tenda): Tenda_3B3E06 SSID format (Huawei): T-C82C87 (MAC: fc:e3:3c:c8:2c:94) Note: C82C is a part of MAC RE: Keyspace List for WPA on Default Routers - freeroute - 08-06-2017 TCT mobile ltd vendor, MY WIFI routers the WPA password is MYWIFI and four digits. The SSID: MY WIFI + the last 4 digits of the MAC (e.g. MY WIFI C057,) RE: Keyspace List for WPA on Default Routers - SarahBishop - 08-07-2017 I findĀ a list of the default key-space used by routers. Pay close attention to the char-sets used, some are UPPERCASE, some a lowercase. Code: SpeedTouchXXXXXX - [0-9a-f] Len: 10 (Broken algo!) BTHomeHub-XXXX - [0-9a-f] Len: 10 (Broken algo!) BTHomeHub2-XXXX - [2-9a-f] Len: 10 BTHub3 - [2-9a-f] Len: 10 BTHub4 - [2-9a-f] Len: 10 BTHub5 - [2-9a-f] Len: 10 BTHub6 - [0-9a-zA-Z] Len: 10 or 12 see here and here. ThomsonXXXXXX - [0-9a-f] Len: 10 PlusnetWireless-XXXXXX - [0-9A-F] Len: 10 PLUSNET-###### - [0-9a-f] Len: 10 MEO-###### - [0-9A-F] Len: 10 See image here. belkin.xxx - [2-9a-f] Len: 8 belkin.xxxx - [2-9a-f] Len: 8 Belkin.XXXX - [0-9A-F] Len: 8 Belkin_XXXXXX - [0-9A-F] Len: 8 BELL### - [0-9A-F] Len: 8 BELL#### - [0-9A-F] Len: 10 TP-LINK_###### - [0-9A-F] Len: 8 TP-LINK_#### - [0-9] Len: 8 (Easy!) TDC-#### - [0-9a-f] Len: 9 (Seen 2 and no 0 so maybe [1-9a-f] reduced key-space?) TNCAPXXXXXX - [0-9A-F] Len: 10 TRKASHI-###### - ?d?d###### [Broken] /topic-view.aspx?t=2715&m=64032#64032 ATTXXX - [0-9] Len: 10. Common AT&T DSL routers in the USA. WebCube#### - [0-9A-F] Len: 8 https://images.futurezone.at/cube_2.jpg/fuzo-slideshow-slide/24.549.231 3WebCube#### - [0-9a-fA-F] Len: 8 https://routerunlock.com/wp-content/uploads/2014/06/Huawei-B190-LTE-Wireless-Gateway.png WLAN1-XXXXXX - [0-9A-F] Len: 11 https://www.4gltemall.com/blog/wp-content/uploads/2013/10/Back-stick-of-HUAWEI-B593u-12.jpg TelstraXXXXXX - [0-9A-F] Len:10 https://s9.postimg.org/6nocruw5b/Telstra_XXXXXX_Technicolor_TG797nv3.png BigPondXXXXXX - [0-9A-F] Len:10 https://s22.postimg.org/w7qofyxj5/Big_Pond_XXXXXX_Technicolor_TG587nv3.png Useful info on TNCAP https://www.crack-wifi.com/forum/topic-9372-technicolor-td5130-0018e7.html https://help.demon.net/help-articles/troubleshooting-and-faqs/technicolor-router-support/ 2WIREXXX - [0-9] Len: 10. Common AT&T DSL routers in the USA. ONOXXXX - [0-9] Len: 10 DJAWEB_##### - [0-9] Len: 10 TIM_PN51T_XXXX - [0-9] Len: 8 - WPS pin is 12345670... and WPS can't be disabled... INFINITUM#### - [0-9] Len: 10 https://www.websec.ca/img/mac2wepkey/image12.png 192.168.1.1 [url=https://www.websec.ca/img/mac2wepkey/image12.png][/url] RE: Keyspace List for WPA on Default Routers - soxrok2212 - 08-09-2017 (07-30-2017, 02:06 AM)fart-box Wrote: It seems I've offended the Hashcat forum Gods, but all is well now. They've let me back in. My apologies to all. I'm working on merging all my code to one project, though I'm not experienced enough to do it modularly. Updates are being pushed as we speak. Code still functions the same but I still haven't completed the 599 code. Would like to wait for mrfancypants... and would also like to know where those 'magic' numbers came from. RE: Keyspace List for WPA on Default Routers - mrfancypants - 08-15-2017 I am not sure I even understand your difficulty. Let's take NVG589 specifically. We have an algorithm that takes in a 64-bit integer 'x' and spits out a 12-letter password: for n in range(0,6): pw=pw_charset[x%37] + pw x/=37 pw=chr(50+(x%8)) + pw x/=37 For whatever reason, AT&T people don't just pull an 'x' out of a RNG or something, instead they pull a 31-bit int and multiply it by a magic number that is approximately 465661287.5245797. (Or possibly do some slightly longer sequence of multiplications and additions which amounts to the same thing, because simply multiplying by that number does not always yield the exact result. But ignore that for now.) Now, where did they get 465661287.5245797? Beats me. All I know is: (1) if they are starting with a 31-bit number, they had to multiply by _something_ (to span the whole range of passwords), since feeding a 31-bit value direct into code above would always result in passwords that start with 2a2a2a..; (2) that exact value reproduces many of the passwords I see in the wild and that can't be a coincidence. (To calculate it, I basically had the computer run through all possible values until it found one that gave lots of hits.) for NVG599, they tweak the number->password conversion algorithm and replace the 465... value with 2^32+2. Again why 2^32+2? Not a clue. |