Broadband Related > Broadband Hardware
VMG1312-B10D new Web GUI 2.0 on V5.13(AAXA.8)C0?
burakkucat:
--- Quote from: jelv on November 02, 2018, 08:38:30 PM ---Wrap it in code tags (the # button in the toolbar)
--- End quote ---
Or use [tt][/tt] tags. ;)
tiffy:
--- Quote from: jelv on November 02, 2018, 08:38:30 PM ---Wrap it in code tags (the # button in the toolbar)
--- Code: ---$ 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
--- End code ---
--- End quote ---
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.
burakkucat:
--- Quote from: tiffy on November 02, 2018, 08:42:13 PM ---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.
--- End quote ---
Here follows the NOTES section from the crypt manual page --
--- Quote ---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).
--- End quote ---
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.
tiffy:
@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 ?
tiffy:
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.
Navigation
[0] Message Index
[#] Next page
[*] Previous page
Go to full version