Kitz Forum
Broadband Related => Broadband Hardware => Topic started by: meritez on November 01, 2018, 06:44:01 PM
-
Hi,
anyway, just reading through the new firmware revision stuff:
Versions:
Bootbase version: V1.61 | 05/25/2018 17:08:36
Firmware version : V5.13(AAXA.8)C0
Kernel version: 3.4.11
DSL modem code version: A2pvI042r
DSL driver version: d26s
WLAN code version: 7.14.164.20.cpe4.16L05.0-kdb
3G WWAN package version: 1.18
nothing wow and came across:
Modifications in V5.13(AAXA.8)b1
Based on V5.13(AAXA.7)C0 to release V5.13(AAXA.8)b1 [Feature Modification]
5. [GUI] New GUI 2.0 design.
The GUI is actually functional, it does not take forever to do anything..
-
You may already be aware, the previous (current) FW revision V.5.13(AAXA.7) of 25/12/17 had to be avoided if Busybox access was required (such as running DSLStats) as this was disabled with this revision, 1312-B10D users had to stick with the previous (previous) FW revision V.5.13(AAXA.5) of 20/07/17 if running DSLStats was a requirement.
Will be interesting to see if this feature has now been re-enabled in FW revision V.5.13(AAXA.8), I do have a spare 1312-B10D where I can try the new FW out when I get some time.
The GUI is actually functional, it does not take forever to do anything..
Not sure what you mean ref. the GUI being non-functional / slow ?
I generally find it to be just the same speed as my 1312-B10A, certainly not slow.
I did have an unusal issue with my 1312-B10D where the GUI was completely non-functional, just sat at the first page with the busy icon churning away for ever, eventually found that this was only using Win 10 with MS Edge browser combination, any other browser on Win 10 and any browser on my Win 8.1 desktop PC worked perfectly !
This is documented here:
https://forum.kitz.co.uk/index.php/topic,22543.msg385504.html#msg385504
Edit: Apologies for not noticing earlier, welcome to the kitz forum
-
Decided to try out the new 1312-B10D FW, V.5.13(AAXA.8)C0 on my spare unit, not line commected.
Yes, completely different GUI appearance which I took an instant dislike to, all the same features are still there, just different access navigation, certainly not an improvement in my opinion.
Before hurriedly "trying" to get back to FW rev. V.5.13(AAXA.5) made the following observations:
Telnet/Busybox access is available.
None of my PW's had changed, still had full supervisor access.
The "passwd" file appears to no longer contain the crypted PW character strings, "cat /var/passwd" produces this:-
BusyBox v1.20.1 (2018-08-24 13:58:33 CST) built-in shell (ash)
Enter 'help' for a list of built-in commands.
$ cat /var/passwd
nobody:x:99:99:nobody:/nonexistent:/bin/false
root:x:0:0:root:/home/root:/bin/sh
supervisor:x:12:12:supervisor:/home/supervisor:/bin/sh
admin:x:21:21:admin:/home/admin:/usr/bin/zysh
Tried to roll back FW to revision V.5.13(AAXA.5)
Warning appeared advising that some "feature may be different", OK to continue or Cancel to go back, only problem being there were no OK or Cancel links/buttons in the window, enter or escape wouldn't work either !
On aborting and re-trying the same revision, this time advised that the (same) file was now an "illegal image, failed".
Decided to try rolling back to the previous FW revision, V.5.13(AAXA.7)
Did not display any errors as such but just sat with the busy icon continually spinning, gave up after considerable waiting time and closed the window.
Much to my surprise when re-connecting, had gone back to V.5.13(AAXA.7)
Checked Telnet/Busybox access on this revision and found that this now worked, no Busybox access had been a known issue with this revision, the "passwd" file content still looked the same as V.5.13(AAXA.8)C0.
Now was able to roll back to revision V.5.13(AAXA.5) without any issues.
The new 1312-B10D GUI interface is not for me, I much prefer the existing ZyXEL GUI appearance and functionality.
There certainly appears to be some bugs associated with V.5.13(AAXA.8)C0 FW upgrading/rolling back operations.
Location of encrypted PW's appears to have changed, perhaps the PW encryption policy/method has changed ?
Edit: Typo corrected.
-
The "passwd" file appears to no longer contain the crypted PW character strings, "cat /var/passwd" produces this:-
BusyBox v1.20.1 (2018-08-24 13:58:33 CST) built-in shell (ash)
Enter 'help' for a list of built-in commands.
$ cat /var/passwd
nobody:x:99:99:nobody:/nonexistent:/bin/false
root:x:0:0:root:/home/root:/bin/sh
supervisor:x:12:12:supervisor:/home/supervisor:/bin/sh
admin:x:21:21:admin:/home/admin:/usr/bin/zysh
The x in the second field of each line indicates that a shadow file is now being used. Where will it be located? Probably in the /var/ directory, along with the passwd file.
-
The x in the second field of each line indicates that a shadow file is now being used. Where will it be located? Probably in the /var/ directory, along with the passwd file.
Ahh, something else I've learned, I would have been surprised if you had not come up with an answer !
I still have the 1312-B10D running off line but have reverted back to the original FW I was using, V.5.13(AAXA.5) as explained, the latest FW revision although enabling Busybox again still appears to be very much a "work in progress" and the GUI in my opinion is awful, much prefer the existing GUI, hope ZyXEL don't intend pushing the new GUI out to other models with FW updates.
When I get some time, I will temporarily re-load revision V.5.13(AAXA.8)C0 again and have a poke around in the file structure to see if I can find the "shadow" file you mention and report back.
Did you note that the Busybox access appeared to be enabled in FW revision V.5.13(AAXA.7) as reported while migrating back from V.5.13(AAXA.8)C0 towards V.5.13(AAXA.5), strange, as this was known not to be the case when this revision was released and all DSLStats users had to remain on (AAXA.5) revision ?
Also the passwd file listing in revision V.5.13(AAXA.7) is the same format as V.5.13(AAXA.8)C0, ie., neither being the same as V.5.13(AAXA.5) where the PW strings are displayed.
-
Went ahead and re-loaded V.5.13(AAXA.8)C0 FW.
Listing of /var directory: (apologies for the format, just a copy from Win cmd window)
$ chdir /var
$ ls
cache log ppp spool
cert mcpd_igmp.conf ptmx state
dhcp6s.conf mcpd_mld.conf public_key.pem syslog-ng.conf
dnsmasq mdkshell_sock radvd_br0.conf tmp
fuse modules.alias run tx
fw modules.dep samba udhcpd
group modules.symbols shadow url_list
home mount shadow- usb
iproute2 net-snmp shm_size wwan
lib passwd siproxd zebra
lock passwd- snmpd.conf
There is indeed a "shadow" file (and a shadow- file) but I can't cat/open as per the "passwd" file, permission denied.
I did login to Busybox as "supervisor", perhaps "root" access would work ?
-
Wrap it in code tags (the # button in the toolbar)
$ chdir /var
$ ls
cache log ppp spool
cert mcpd_igmp.conf ptmx state
dhcp6s.conf mcpd_mld.conf public_key.pem syslog-ng.conf
dnsmasq mdkshell_sock radvd_br0.conf tmp
fuse modules.alias run tx
fw modules.dep samba udhcpd
group modules.symbols shadow url_list
home mount shadow- usb
iproute2 net-snmp shm_size wwan
lib passwd siproxd zebra
lock passwd- snmpd.conf
-
I've tried to upgrade mine but got the attached. I'm currently on .7.
Any ideas?
-
There is indeed a "shadow" file (and a shadow- file) but I can't cat/open as per the "passwd" file, permission denied.
I did login to Busybox as "supervisor", perhaps "root" access would work ?
To answer my own question, yes, root access did permit listing of the "shadow" file, as below:
# cat /var/shadow
root:$6$xLQ5LS29AWQ3PFyY$xx/.yhjeBLVjz5hnZWekoEB/RyOWlOgX26gEBYML.C2D7TglGub7ibZ
F.1R.YVxFP5YdqDg.DxQ/FediPQ7Ip.:0::::::
supervisor:$6$ockB3m/vx9pPP0lf$BY6lRm1W9.hDMzVtDZPxdI40Oo.Wr.P.ybMrtrd4MJOwpEEFW
LtO/EGjbcPsjG/ANwomEiJnBrsO.mPFh/KPH/:0::::::
admin:$6$xstsmqPExqn6Omf7$mj0Ty1xsy88MMU7FJs/5u9U9nrniZlfUGjw6CXbwIMAwnk.Pl0xBx4
FYoa4UWwJS0gfeWtpigD60/IA2SbwtG.:0::::::
The encrypted character string format looks different to me from that produced by FW revision V.5.13(AAXA.5), I'am sure b*cat can give a more informed opinion on that.
-
There is indeed a "shadow" file (and a shadow- file) but I can't cat/open as per the "passwd" file, permission denied.
I did login to Busybox as "supervisor", perhaps "root" access would work ?
The permissions on that file will be 0000 and that explains why only root wil be able to read its contents. The shadow- file is the immediate chronological predecessor of the shadow file.
You might be interested to see what a ls -l /var/*- command discloses. :)
On a system using a Linux kernel, I see the following (in the /etc/ directory) --
[Duo2 etc]$ ls -l passwd* group* *shadow*
-rw-r--r--. 1 root root 938 Oct 13 2017 group
-rw-r--r--. 1 root root 949 Oct 13 2017 group-
----------. 1 root root 776 Oct 13 2017 gshadow
----------. 1 root root 784 Oct 13 2017 gshadow-
-rw-r--r--. 1 root root 1654 Oct 13 2017 passwd
-rw-r--r--. 1 root root 1689 Oct 13 2017 passwd-
----------. 1 root root 1134 Oct 13 2017 shadow
----------. 1 root root 1256 Oct 13 2017 shadow-
[Duo2 etc]$
-
Wrap it in code tags (the # button in the toolbar)
Or use [tt][/tt] tags. ;)
-
Wrap it in code tags (the # button in the toolbar)
$ chdir /var
$ ls
cache log ppp spool
cert mcpd_igmp.conf ptmx state
dhcp6s.conf mcpd_mld.conf public_key.pem syslog-ng.conf
dnsmasq mdkshell_sock radvd_br0.conf tmp
fuse modules.alias run tx
fw modules.dep samba udhcpd
group modules.symbols shadow url_list
home mount shadow- usb
iproute2 net-snmp shm_size wwan
lib passwd siproxd zebra
lock passwd- snmpd.conf
Thanks for the tip, showing my ignorance of the system again.
Ref. your next post and error displayed.
Yes, I got this error also but only when trying to roll back from (AAXA.8) to (AAXA.5), had to roll back in two stages as explained earlier, have upgraded twice now from (AAXA.5) to (AAXA.8)C0 without any issues.
-
The encrypted character string format looks different to me from that produced by FW revision V.5.13(AAXA.5), I'am sure b*cat can give a more informed opinion on that.
Here follows the NOTES section from the crypt manual page --
NOTES
Glibc Notes
The glibc2 version of this function supports additional encryption algorithms.
If salt is a character string starting with the characters "$id$" followed by a string terminated by "$":
$id$salt$encrypted
then instead of using the DES machine, id identifies the encryption method used and this then determines how the rest of the password
string is interpreted. The following values of id are supported:
ID | Method
---------------------------------------------------------
1 | MD5
2a | Blowfish (not in mainline glibc; added in some
| Linux distributions)
5 | SHA-256 (since glibc 2.7)
6 | SHA-512 (since glibc 2.7)
So $5$salt$encrypted is an SHA-256 encoded password and $6$salt$encrypted is an SHA-512 encoded one.
"salt" stands for the up to 16 characters following "$id$" in the salt. The encrypted part of the password string is the actual com-
puted password. The size of this string is fixed:
MD5 | 22 characters
SHA-256 | 43 characters
SHA-512 | 86 characters
The characters in "salt" and "encrypted" are drawn from the set [a–zA–Z0–9./]. In the MD5 and SHA implementations the entire key is
significant (instead of only the first 8 bytes in DES).
So looking at the contents of your shadow file --
root:$6$xLQ5LS29AWQ3PFyY$xx/.yhjeBLVjz5hnZWekoEB/RyOWlOgX26gEBYML.C2D7TglGub7ibZF.1R.YVxFP5YdqDg.DxQ/FediPQ7Ip.:0::::::
supervisor:$6$ockB3m/vx9pPP0lf$BY6lRm1W9.hDMzVtDZPxdI40Oo.Wr.P.ybMrtrd4MJOwpEEFWLtO/EGjbcPsjG/ANwomEiJnBrsO.mPFh/KPH/:0::::::
admin:$6$xstsmqPExqn6Omf7$mj0Ty1xsy88MMU7FJs/5u9U9nrniZlfUGjw6CXbwIMAwnk.Pl0xBx4FYoa4UWwJS0gfeWtpigD60/IA2SbwtG.:0::::::
-- we see that the second field of each line begins with $6$. That is the "fingerprint" of SHA-512 crypt.
Let's look at the second field of the second line --
$6$ockB3m/vx9pPP0lf$BY6lRm1W9.hDMzVtDZPxdI40Oo.Wr.P.ybMrtrd4MJOwpEEFWLtO/EGjbcPsjG/ANwomEiJnBrsO.mPFh/KPH/
The segment in green is the salt and the segment in red is the encrypted (password) string.
-
@b*cat
Many thanks for the excellent explanation of the "new" crypt format, font of knowledge as always.
My previous experience obtaining the supervisor PW when running FW revision V.5.13(AAXA.5) this used MD5 (22 character format) encrypted string, it would now appear that from FW revision V.5.13(AAXA.7) onwards that SHA-512 (86 character format) has been adopted.
With respect to any future PW decrypt attempts using Hashcat, with a lot of help from yourself I have just about got to grips with the MD5 (22 character) format and Hashcat search command line options using different operating systems / hardware, would I be correct in assuming that a SHA-512 crypt will be more difficult / time consuming to decrypt ?
-
Having now rolled back from FW revision V.5.13(AAXA.8)C0 to V.5.13(AAXA.7) I can confirm that the location and the format of the encrypted PW's is the same as V.5.13(AAXA.8)D0, ie., /var/shadow & SHA-512 format.
For reference, have found that to get back to FW revision V.5.13(AAXA.5) from V.5.13(AAXA.8)C0, this must be done in two steps to avoid fatal error windows appearing, ie., roll back to V.5.13(AAXA.7) first.
This initial roll back does appear to "lock up" and never complete, however, on closing the browser window and re-logging have found that the migration has completed successfully.
The roll back from FW revision V.5.13(AAXA.7) to V.5.13(AAXA.5) does complete normally with the router re-booting and displaying the login page again.
Have completed these FW revisions "up-down" migrations twice and the results are repeatable.
The initial reason for avoiding FW revision V.5.13(AAXA.7) was that Busybox access was disabled, now appears to be available again on this revision !
Edit: Still hate the new (AAXA.8) GUI won't be going there.
Apologies to meritez for appearing to take over this thread.
-
Has anyone managed to do a V.5.13(AAXA.7) to V.5.13(AAXA.8) upgrade?
-
. . . would I be correct in assuming that a SHA-512 crypt will be more difficult / time consuming to decrypt ?
In theory, yes. But in practice not necessarily so. What do I mean? Clearly, from a read of the crypt() manual page, there is the possibility of using a significantly longer (plain-text) password. That, in turn, would therefore require the usage of a significantly longer mask . . . However as you have confirmed that the supervisor (and root) plain-text password is the same as with MD5 crypt, you will know its length.
Hashcat (legacy hashcat) documentation shows --
* Mask-attack attack-mode specific:
--increment Enable increment mode
--increment-min=NUM Start incrementing at NUM
--increment-max=NUM Stop incrementing at NUM
Those three flags are quite useful, at times.
Finally, the required argument to follow the "-m" flag --
500 is md5crypt
1500 is DEScrypt
1800 is SHA512crypt
If I was experimenting with the data for the supervisor login, harvested from your shadow file, I would first try the following command line (legacy hashcat) --
hashcat -a 3 -m 1800 --custom-charset1=?dabcdef --increment VMG1312-B10D.hash ?1?1?1?1?1?1de
-
Has anyone managed to do a V.5.13(AAXA.7) to V.5.13(AAXA.8) upgrade?
For convenience, I will refere to the FW revisions by single digit numbers 5, 7 & 8:
Have previously just updated from rev. 5 to 8 without any issues.
To answer your question, I tried an update from rev. 5 to 7, no problems encountered.
Then a further update from rev. 7 to 8, no problems encountered.
For all operations, logged in to router GUI @ supervisor level, never tried admin level, likely not significant.
As previously reported, I find there is an issue trying to roll back revisions 8 to 5, have to complete in 2 steps 8 to 7 then 7 to 5, only way it will work for me.
Will be interesting to get your opinion on the new rev. 8 GUI, I was glad to leave it behind and scurry back to rev. 5.
-
If all else fails, the firmware could be upgraded/downgraded via ftp.
-
@ b*cat
Thanks for the further information.
Yes, will have a further play with Hashcat and the SHA-512 format, I can carry out a direct time comparison with MD5 format on my very limited Intel based system supplying some of the known answers as you suggest to get the time down to something reasonable.
Of course it's easy to experiment with the Hashcat command line parameters when we already know the decrypted PW format, in our case the actual PW's, in the absence of this information I can see why we would require the services of a benefactor with very extensive (and expensive) GPU resources.
-
I finally managed to upgrade: used the laptop instead of the PC - different browser and different antivirus software. Not sure which was the difference but it is done.
Will be interesting to get your opinion on the new rev. 8 GUI, I was glad to leave it behind and scurry back to rev. 5.
It's different but everything is there under the same menu options. Have you looked at the new GUI using your mobile phone? It's 1000% better than the old GUI if you look at it using a mobile device as it is now fully responsive.
BUT...
Telnetting in I'm still only presented with the ZySH so no RouterStats! :(
-
I have asked Zyxel for the gpl source for research purposes, but have been informed its internal only at present :o
-
I finally managed to upgrade: used the laptop instead of the PC - different browser and different antivirus software. Not sure which was the difference but it is done.
Yes, can be very temperamental, I've had some further difficulties tonight getting back to revision 5, finally downloaded a fresh FW copy and that went through ?
It's different but everything is there under the same menu options. Have you looked at the new GUI using your mobile phone? It's 1000% better than the old GUI if you look at it using a mobile device as it is now fully responsive.
Yes, it certainly is different, just not to my liking.
I would never have thought of a mobile phone interface, never had occasion to try this.
Telnetting in I'm still only presented with the ZySH so no RouterStats!
Wonder if it's actually RouterStats or DSLStats program you refer to ? (same principal regarding router data collection)
In my ignorance, I made the assumption that if I could Telnet/Busybox into the router then DSLStats would work, having this afternoon actually tried pointing DSLStats (running on a RPi 3B) at the router found that it won't work on FW revisions 7 & 8 but does on rev. 5 as indeed was always reported.
Apologies for any confusion.
Is there an easy / positive way to identify if DSLStats / RouterStats will communicate with a router other than trying a connection to the utility ?
-
If all else fails, the firmware could be upgraded/downgraded via ftp.
Out of interest, how is this achieved ?
-
You would need to use an ftp client and have it transfer the firmware to the device using the admin credentials. It would be best done with the device reset to the factory defaults, so that "admin" and "1234" are used.
An alternative method is to open up the device, connect to the serial console header pins on the PCB, interrupt the boot process and upload the firmware from the CFE> prompt.
Here are the commands recognised at the CFE> prompt for a ZyXEL VMG1312-B10D --
CFE> ATHE
Available commands:
ATMB Use for multiboot.
ATBB Mark/unmark the Block X to be bad block.
ATCMP Compare the contents at start address X and Y with
Length Z
ATLD Download data with file name X to memory address Y
from PC via TFTP
ATRB Load the CFERAM to run by TFTP or UART!
ATDS Dump data of spare area in block X`s page Y
ATRF Read/Dump flash data
ATER Erase NAND flash from block X to block Y
ATWF Write data from RAM to flash
ATRT Test memory.
ATCR reset to default, erase Data partition
ATCD Erase ROM-D partition
ATWZ write (a)MAC addr, (b)Country code, (c)EngDbgFlag,
(d)FeatureBit, (e)MAC Number to NVRAM
ATCO set Country Code to NVRAM.
ATSN set Series Number to NVRAM.
ATSH dump manufacturer related data from NVRAM
ATGO Run program from flash image or from host depend on
[f/h] flag.
ATSE show the seed of password generator
ATEN set BootExtension Debug Flag
ATBT block0 write enable
ATPH Set/Get PHY`s registers.
ATWW Set memory or registers.
ATDU Dump memory or registers.
ATBL Print boot line and board parameter info
ATIP Change booline parameters
ATAF Change board AFE ID
ATBP Change board parameters
ATSR System reboot
ATUD Upload ROM-D to flash from TFTP
ATUB Upload bootloader to flash from TFTP
ATUR Upload router firmware to flash from TFTP
ATUW Write the whole image start from beginning of the flash from TFTP
ATHE print help
For more information about a command, enter 'help command-name'
*** command status = 0
CFE>
-
Sorry - I meant DSLStats.
Is there an easy / positive way to identify if DSLStats / RouterStats will communicate with a router other than trying a connection to the utility ?
If when you telnet in you get the busybox it will work. If you get ZySH it won't.
-
@ b*cat
You would need to use an ftp client and have it transfer the firmware to the device using the admin credentials. It would be best done with the device reset to the factory defaults, so that "admin" and "1234" are used.
An alternative method is to open up the device, connect to the serial console header pins on the PCB, interrupt the boot process and upload the firmware from the CFE> prompt.
Many thanks for the comprehensive reply, much appreciated.
I've been down the serial connection route before to unlock the 1312-B10D, biggest issue I found was getting the case open without damaging the plastic catches, could not master the "plastic card" technique !
Hope I never have to go down this route which I would imagine would be required if a device was "bricked" however, the information is certainly filed away just in case.
-
For the serial-console, CFE> prompt method, the required command is --
ATUR Upload router firmware to flash from TFTP
(TFTP = trivial file transfer protocol (https://www.google.com/url?sa=t&rct=j&q=&esrc=s&source=web&cd=12&cad=rja&uact=8&ved=2ahUKEwiB-L7k-7reAhVJI8AKHXO5C2YQFjALegQIBxAB&url=https%3A%2F%2Fen.wikipedia.org%2Fwiki%2FTrivial_File_Transfer_Protocol&usg=AOvVaw2h-CiYAYnc-Qd62xdpZl7U).)
-
Sorry - I meant DSLStats.
If when you telnet in you get the busybox it will work. If you get ZySH it won't.
Yes, that certainly was my understanding, however, I'am now confused !
If you get ZySH it won't.
Sorry, I don't understand this bit ?
Set up my off line 1312-B10D running FW revision V.5.13(AAXA.5), DSLStats V.6.5.9 running on my RPi 3B configured to suit the 1312-B10D router, communicating perfectly (obviously showing no DSL connection)
Updated router FW to V.5.13(AAXA.7) and repeated exercise, unable to collect stats from router via DSLStats.
In both cases full Telnet/Busybox access (as I understand it) was available from Win cmd window.
Did not take the trouble to repeat the exercise with FW revision 5.13(AAXA.8) as you have already reported that DSLStats would not work and I found previously that Telnet/Busybox access was still possible from Win cmd window with this FW revision.
-
What login are you using?
I only get ZySH which if I key ? shows the available commands - no stats available!
VMG1312-B10D login: admin
Password:
ZySH>
cfg - DAL command line interface
dns - ZYXEL command line
ethwanctl - ZYXEL command line
exit - Close an active terminal session
history - Display or clear CLI history
ifconfig - Show network interface configuration
ping - Send ICMP ECHO_REQUEST to network hosts
pppoectl - ZYXEL command line
sys - ZYXEL command line
tcpdump - Text based packet capture utility
traceroute - monitor each routed node during whole routing path to <host>
vcautohuntctl - ZYXEL command line
voicedbgcli - ZYXEL command line
wan - ZYXEL command line
wlan - ZYXEL command line
xdslctl - ZYXEL command line
zycli - ZYXEL command line
This is the same as I was seeing with .7
-
For the serial-console, CFE> prompt method, the required command is --
ATUR Upload router firmware to flash from TFTP
(TFTP = trivial file transfer protocol (https://www.google.com/url?sa=t&rct=j&q=&esrc=s&source=web&cd=12&cad=rja&uact=8&ved=2ahUKEwiB-L7k-7reAhVJI8AKHXO5C2YQFjALegQIBxAB&url=https%3A%2F%2Fen.wikipedia.org%2Fwiki%2FTrivial_File_Transfer_Protocol&usg=AOvVaw2h-CiYAYnc-Qd62xdpZl7U).)
Many thanks for the further informat.
Regarding our earlier subject in this thread, applying Hashcat to decrypt a SHA-512 format character string, tried the following experiment:
From previous 1312-B10D FW revision V.5.13(AAXA.5) when the crypt character string was MD5 encoded, this Hashcat search line worked on my very modest Intel GUI desktop PC producing the correct result in under a minute.
hashcat64 -O -m 500 -a 3 -w 3 --force -D 1,2 root.hash ?h?h?h?h?h?hde
(last 2 characters were given to achieve a reasonable time on my system)
Now ran with SHA-512 format selected and new character string in root.hash:
hashcat64 -O -m 1800 -a 3 -w 3 --force -D 1,2 root.hash ?h?h?h?h?h?hde
(-m 500 changed to -m 1800 for SHA-512 format)
This command line was accepted by Hashcat but the PC "locked up" (tried twice) while initialising.
Concluded that the SHA-512 format Hashcat operation requires resources well beyond my PC's capabilities.
-
@jelv
What login are you using?
I only get ZySH which if I key ? shows the available commands - no stats available!
Ahh, I'am using Windows 8.1 command window (as administrator) on my desktop PC and I certainly don't get a ZySH> prompt hence the confusion !
From Win cmd prompt, telnet, open (IP address), login, pw, arrive @ Busybox command prompt as below:
BusyBox v1.20.1 (2017-04-20 00:36:56 CST) built-in shell (ash)
Enter 'help' for a list of built-in commands.
#
Same story with Windows 10 on my laptop PC..
-
Doing exactly the same as you I get the ZySH prompt not the # for the BusyBox.
What login are you using?
-
Doing exactly the same as you I get the ZySH prompt not the # for the BusyBox.
Beats me, can't explain, very confusing !
However it works, the tests I have carried out today would seem to confirm that DSLStats won't work with FW revisions later than 5.13(AAXA.5)
-
After you enter telnet 192.168.1.1 and it prompts for the login do you use "admin" or a different user?
-
Something I didn't spot!
On V.5.13(AAXA.7) DSLStats couldn't be used. This is because on telnetting in as admin, instead of the BusyBox you got the ZySH. ? lists the commands available:
cfg - DAL command line interface
dns - ZYXEL command line
ethwanctl - ZYXEL command line
exit - Close an active terminal session
history - Display or clear CLI history
ifconfig - Show network interface configuration
ping - Send ICMP ECHO_REQUEST to network hosts
pppoectl - ZYXEL command line
sys - ZYXEL command line
tcpdump - Text based packet capture utility
traceroute - monitor each routed node during whole routing path to <host>
vcautohuntctl - ZYXEL command line
voicedbgcli - ZYXEL command line
wan - ZYXEL command line
wlan - ZYXEL command line
zycli - ZYXEL command line
on V.5.13(AAXA.8) you still get ZySH but the commands available are now this:
cfg - DAL command line interface
dns - ZYXEL command line
ethwanctl - ZYXEL command line
exit - Close an active terminal session
history - Display or clear CLI history
ifconfig - Show network interface configuration
ping - Send ICMP ECHO_REQUEST to network hosts
pppoectl - ZYXEL command line
sys - ZYXEL command line
tcpdump - Text based packet capture utility
traceroute - monitor each routed node during whole routing path to <host>
vcautohuntctl - ZYXEL command line
voicedbgcli - ZYXEL command line
wan - ZYXEL command line
wlan - ZYXEL command line
xdslctl - ZYXEL command line
zycli - ZYXEL command line
Spot the difference?
:thumbs:
-
It was mentioned in an earlier thread that Zyxel were adding back access to the xdslctl commands.
So you simply need to tell DslStats to use the xdslctl command?
-
I'd not remembered the post about it being added back.
As DSLStats was working before I upgraded to .7, it just started working without any config changes when I fired it up.
-
Funny enough, I did notice when re-configuring DSLStats from 1312-B10A to 1312-B10D to test access that choosing the config. paramaters by XyXEL model did change the CLI Command Prefix from "adsl" to "xdslctl", ie. Eric has updated the model parameters, didn't think this was significant at the time.
Don't want to mess about with my RPi 3B (DSLStats) any more to further test access as it's just gone back into service after a memory card failure today, so, are you saying that you can now access DSLStats on revision V.5.12(AAXA.7) & 8 using the "xdslctl" command prefix ?
Still can't explain why I get Busybox login from Win command prompt and you get ZySH prompt when using the same operating system.
I've been logging in as root not admin, could that be the answer ?
-
Logging in as root will be why you got the BusyBox. How did you get the root password?
xdslctl is available to admin in versions up to 6, not available on 7 and available again on 8 so DSLstats will work on everything but 7 if configured to use the admin login.
If you have a login on 7 that allows the xdslctl command you could configure DSLstats to use that.
-
Logging in as root will be why you got the BusyBox. How did you get the root password?
xdslctl is available to admin in versions up to 6, not available on 7 and available again on 8 so DSLstats will work on everything but 7 if configured to use the admin login.
If you have a login on 7 that allows the xdslctl command you could configure DSLstats to use that.
Thanks for the additional information.
The recent rather long saga on the supervisor & root PW's is here:
https://forum.kitz.co.uk/index.php/topic,22543.msg385504.html#msg385504
Short answer being, with a lot of help from my friends.
-
Funny enough, I did notice when re-configuring DSLStats from 1312-B10A to 1312-B10D to test access that choosing the config. paramaters by XyXEL model did change the CLI Command Prefix from "adsl" to "xdslctl", ie. Eric has updated the model parameters, didn't think this was significant at the time.
I recall, from the few months when I used a VMG1312-B10D, that adsl was just a symbolic link to xdslctl and routinely used the latter command.
In fact that is also true for the VMG1312-B10A --
~ # ls -l /bin/adsl
lrwxrwxrwx 1 supervis root 7 Nov 23 2017 /bin/adsl -> xdslctl
~ # ls -l /bin/xdslctl
-rwxr-xr-x 1 supervis root 133748 Nov 23 2017 /bin/xdslctl
~ #
(Colours as seen when viewing the listing output.)
-
The upgrade to .8 broke my SIPgate VoIP! Voicemail was fine but on a normal call the person at the other end could hear me but I couldn't hear them.
I struck lucky with the SIPgate help and found this: https://basichelp.sipgate.co.uk/hc/en-gb/articles/204152672
In the router settings under network settings, NAT select the ALG tab. SIP ALG and NAT ALG were turned on. Turning those off fixed the issue.
-
Interesting, don't currently use VoIP but information noted should the occasion ever arise.
Noted on my on line 1312-B10A that the options are enabled.
Also enabled on my spare 1312-B10D running V.5.13(AAXA.5) FW, would appear to be XyXel default options.
-
Logging in as root will be why you got the BusyBox. How did you get the root password?
xdslctl is available to admin in versions up to 6, not available on 7 and available again on 8 so DSLstats will work on everything but 7 if configured to use the admin login.
If you have a login on 7 that allows the xdslctl command you could configure DSLstats to use that.
Temporarily changed the 1312-B10D to FW revision V.5.13(AAXA.7) and can confirm that when logging in as "admin" from Windows command prompt I do indeed get the "ZySH" prompt while as already reported, logging in as "root" proceeds to the BusyBox prompt.
At least that clears up the confusion on my part.
Have not yet tried a DSLStats "root" login using either CLI command prefix so can't comment on that at present, will be interesting to see if it does work.
-
Completed the DSLStats operational checks on FW revision V.5.13(AAXA.7) and established the following:
With DSLStats running on RPi 3B, logging in to 1312-B10D as "root" using associated PW and using adsl or xdslctl CLI command prefix, data collection works normally without any issues.
Edit: Added RPi information.
-
Just received this.
The below link is V5.13(AAXA.8)C0 open source code for VMG1312-B10D.
Please get the open source code from following link:
https://www.dropbox.com/sh/8wp0p78ko83yjrl/AADqEIrm0Bsm4pQ5D4jD61Xna?dl=0
Note: This open source code link would be expired on November 12 2018.
Thanks a lot.
Anyone interested in building a MTU 1508 firmware out of this?
-
Anyone interested in building a MTU 1508 firmware out of this?
I thought that the VMG1312-B10D was MTU mini-jumbo frames capable with all the default ZyXEL firmware images? :-\
-
Hmm... the AAISP wiki has the baby jumbo frame support crossed out:
https://support.aa.net.uk/Category:ZyXEL_VMG1312_B10D
VDSL (FTTC) or ADSL as a bridging modem to a third-party PPPoE router (e.g. FireBrick). (with baby jumbo frame support, therefore supporting 1500 byte MTU)
So I guess not?
If anyone has a USB serial adapter, or if someone can make sure the recovery firmware flash page can be accessed just with a long hold of the reset button on boot then I dont mind trying to make a 1508 firmware, but do not have a B10D device to test.
-
Hmm... the AAISP wiki has the baby jumbo frame support crossed out:
https://support.aa.net.uk/Category:ZyXEL_VMG1312_B10D
So I guess not?
Thank you for pointing out that amendment.
. . . if someone can make sure the recovery firmware flash page can be accessed just with a long hold of the reset button on boot . . .
I no longer have a VMG1312-B10D, so I am unable to re-check, but I believe that facility does not exist. :-\
-
@johnson & b*cat:
If anyone has a USB serial adapter, or if someone can make sure the recovery firmware flash page can be accessed just with a long hold of the reset button on boot then I dont mind trying to make a 1508 firmware, but do not have a B10D device to test.
I no longer have a VMG1312-B10D, so I am unable to re-check, but I believe that facility does not exist.
I currently have a 1312-B10D "on the bench", not line connected and running FW revision V.5.13(AAXA.5) to suit DSLStats compatability and disliking the new GUI in FW revision 8, see earlier posts in this thread.
I can check the point in question if someone explains exactly what is required, I do have a USB/Serial TTL adaptor which I deployed in the initial unlocking of this unit but to be honest I don't really wish to open the case again to access the serial header pins as I have already damaged the case plastic catches, not quite mastered the "credit card" tecnique !
-
I can check the point in question if someone explains exactly what is required, . . .
When convenient, start with the VMG1312-B10D in a powered-off state. Connect an Ethernet patch cable to the LAN1 port and the other end to a computer. Set the interface of the latter to use a static IPv4 address, say 192.168.1.100 . . . anything in that sub-net will do, other than the 192.168.1.0, 192.168.1.1 or 192.168.1.255 IPv4 addresses.
Now depress the reset switch of the VMG1312-B10D and keep it held in the operated state. With the other free hand, power-on the device. Wait for as long as you can . . . at least more than 10 seconds. Release the reset switch. Wait one to two minutes and then point your web-browser to the 192.168.1.1 IPv4 address.
Do you see a firmware update page? If yes, :) If not, :( Then please report your findings.
[Edit: typo.]
-
@ b*cat:
Configured everything exactly as you advised, have been accessing the router on my LAN with IP add. of 192.168.0.200, results as follows:
After procedure, could not access router on IP add. 192.168.1.1, ie., default.
Router accessed on IP add. 192.168.0.200 (after changing PC to static IPv4 add. of 192.168.0.100)
Nothing in the router config. had changed, admin & supervisor access PW's were the same as previous.
Repeated exercise to ensure repeatability, results were the same.
So, short answer to " did you see a FW update page ? " is no.
Hope this helps.
-
Thank you for trying. So it seems as if usage of the serial console will be the only method available to recover from a defective firmware image flash.
-
@johnson & b*cat:
I currently have a 1312-B10D "on the bench", not line connected and running FW revision V.5.13(AAXA.5) to suit DSLStats compatability and disliking the new GUI in FW revision 8, see earlier posts in this thread.
I can check the point in question if someone explains exactly what is required, I do have a USB/Serial TTL adaptor which I deployed in the initial unlocking of this unit but to be honest I don't really wish to open the case again to access the serial header pins as I have already damaged the case plastic catches, not quite mastered the "credit card" tecnique !
Well I had a stab this evening at making a B10D baby jumbo frames firmware. The build package appears to be similar to the VMG3925 so I applied the changes jhm used seen here (https://github.com/trejan/VMG3925-B10B). It built without warnings, but as I have no device to test it requires someone brave who is certain they can recover from a bad flash through serial console. It shouldnt be any more complicated than interrupting the boot with a keypress from a serial adapter and reflashing from the recovery page, but who knows, it could be more difficult than that.
So if anyone is so inclined:
https://www.dropbox.com/s/twc2b5o5ww0rc79/1312-B10D-AAXA8-jumbo.bin?dl=0
-
@ johnson:
Many thanks for your time & efforts modifying the 1312-B10D FW with respect to baby jumbo frames via the source code as supplied by meritez.
I don't have the time to test at present due to other commitments but have downloaded the FW bin file for future reference, as you have said, with the "long press reset" not being an option on this model (see earlier posts) could get quite involved and time consuming if the "serial interrupt @ boot" + reflash option didn't work.
Have not really bothered trying the baby jumbo FW modification on my 1312-B10A which I believe is available, I assume the 1312-B10D would have to be put on line post FW upgrade to test ?
-
No worries tiffy!
Not much point trying something out if you have no need for it. Indeed the recovery from a bad flash might be quite involved, I feel like I should add a B10D and maybe a 3925 to my addiction collection of devices. ;D
-
@ johnson,
Thank you, I will get round to testing this week
-
@ johnson,
Thank you, I will get round to testing this week
As I said, you need to be certain you can recover from a bad flash if you want to try it. I have no device so the supplied image is completely untested. This means you need a USB to serial adapted and no problems using it in anger.
-
@ johnson
Works fine thank you:
root@pi:~# ping -s 1472 cloudflare.com
PING cloudflare.com (198.41.215.162) 1472(1500) bytes of data.
1480 bytes from 198.41.215.162: icmp_seq=1 ttl=57 time=18.4 ms
1480 bytes from 198.41.215.162: icmp_seq=2 ttl=57 time=18.5 ms
1480 bytes from 198.41.215.162: icmp_seq=3 ttl=57 time=18.2 ms
1480 bytes from 198.41.215.162: icmp_seq=4 ttl=57 time=18.1 ms
-
Another success. :)
-
Well done to johnson for successfully modifying the FW with respect to baby jumbo frames capability and to meritez for having the courage to test despite the possibility of a "bad flash" and the associated recovery issues.
Have not loaded the modified FW on my spare 1312-B10D as it's based on the V.5.13(AAXA.8) revision with modified GUI which I don't like and I don't currently intend to put the router on line, however, the ping test method as supplied by meritez prompted further research ref. usage in a Windows environment, found this information:
https://interworks.com/blog/tlester/2010/12/29/test-jumbo-frames-how-tell-if-9000-mtu-working/
This command line worked on my 1312-B10A which is not baby jumbo frames FW modified:
C:\WINDOWS\system32>ping -f -l 1472 198.41.215.162
(the second command line option is lower case "-L", upper case "-L" won't work)
For reference, ping on 1312-B10A with 1464 bytes requested:
C:\WINDOWS\system32>ping -f -l 1464 198.41.215.162
Pinging 198.41.215.162 with 1464 bytes of data:
Reply from 198.41.215.162: bytes=1464 time=30ms TTL=58
Reply from 198.41.215.162: bytes=1464 time=30ms TTL=58
Reply from 198.41.215.162: bytes=1464 time=29ms TTL=58
Reply from 198.41.215.162: bytes=1464 time=29ms TTL=58
Ping statistics for 198.41.215.162:
Packets: Sent = 4, Received = 4, Lost = 0 (0% loss),
Approximate round trip times in milli-seconds:
Minimum = 29ms, Maximum = 30ms, Average = 29ms
For comparison, ping on 1312-B10A with 1465 bytes requested:
C:\WINDOWS\system32>ping -f -l 1465 198.41.215.162
Pinging 198.41.215.162 with 1465 bytes of data:
Request timed out.
Packet needs to be fragmented but DF set.
Packet needs to be fragmented but DF set.
Packet needs to be fragmented but DF set.
Ping statistics for 198.41.215.162:
Packets: Sent = 4, Received = 0, Lost = 4 (100% loss),
Probably very much stating the obvious here to the better informed forum members, however, I was not aware of the packet frame size ping testing method so hopefully this will act as a guide to lesser informed parties (such as myself) who may wish to implement / test the FW modification on their 1312-B10D's and are running in a Windows environment.
-
@ johnson
Works fine thank you:
Great stuff! :drink:
tiffy if you ever feel the itch to have jumbo frames on your B10D just request the source for the older GUI firmware from zyxel and post the link. Its no trouble.
-
Great stuff! :drink:
tiffy if you ever feel the itch to have jumbo frames on your B10D just request the source for the older GUI firmware from zyxel and post the link. Its no trouble.
Many thanks for your kind offer, most appreciated, didn't realise that ZyXEL would actually release their source code until meritez's post, will certainly keep that in mind as I have such a dislike for the latest ZyXEL FW GUI.
-
AAXA.10 has just been released.
AAXA.9 has been skipped because they broke the WPS button according to the changelog. :lol:
AAXA.8 is worth upgrading from as it dropped ipsec vpn connections.
-
@meritez
Many thanks for the update information.
I presume that FW revision AAXA.10 still permits DSLStats interface remembering that rev. AAXA.7 did not ?
Wonder if rev. AAXA.10 still uses the "new" GUI format which was changed post rev. AAXA.5 from the more familiar and fairly standard ZyXEL GUI used across all models ?
I took an instant dislike to the later GUI revision and as such have stayed on FW revision AAXA.5.
My "spare" VMG1312-B10D has been in service on my daughters VDSL-2 line for quite some time now and as such I can't easily try the FW upgrade, if the GUI remains the "new" format I certainly won't be upgrading anyway.