Kitz ADSL Broadband Information
adsl spacer  
Support this site
Home Broadband ISPs Tech Routers Wiki Forum
 
     
   Compare ISP   Rate your ISP
   Glossary   Glossary
 
Please login or register.

Login with username, password and session length
Advanced search  

News:

Pages: [1] 2

Author Topic: about to test a SBG3300-N000 but dissapointed re the chipset and firmware  (Read 2292 times)

les-70

  • Kitizen
  • ****
  • Posts: 1254

  I recently purchased Zyxel VBG3300-N000 from the bay for about £20 to see if the 6368 chip noted to be in it did better than either a Hg612 or a VMG1312.  All seems to be OK I have cleared rom-D reset and loaded the latest firmware and reset again.  sh gets a # so no obvious need for a supervisor password but I get to that later.  I have to say I dissapointed that it does not look like the 6368 info is correct. 
 I get
 > cat /proc/cpuinfo
system type             : 963168MXH_17A
processor               : 0
cpu model               : Broadcom4350 V8.0
BogoMIPS                : 399.36
etc.........
this looks like a 63168! is this a reliable test?

 and the dsl firmware is A2pv6F039n which is an old version if for a 63168.   I will test it but the unit may well be up for sale later as the 63168 with older firmwares has not previously done at all well on my line.

   Returning to the supervisor account (which I may not need but I wondered if it would give added gui options) I was seeking the password, zyad1234 did not work.  With cat /var/csmu I get

supervisor cGpPbTNsVkpydndyLnp5YWQxMjM0MDM4MzQ1NjgyOAA=  pjOm3lVJrvwr.zyad12340383456828
support c3VwcG9ydAA=                                                                   support
user dXNlcgA=                                                                                user
admin ZmlkZ2l0MQA=                                                                     fidgit1
zyuser MTIzNAA=                                                                           1234

where I have added along side the base 64decode.   I tried all sorts of parts of the supervisor decode but they don't work and whole decode is too long with some obvious components.

alternatively
cat /etc/passwd
supervisor:dpJNRD7c6NAdo:0:0:Administrator:/:/bin/sh
admin:hVhgDj95zgB1o:1:0:Administrator:/:/bin/sh
zyuser:T6Af3MxPdOhmk:2:2:User:/:/bin/sh

  which I don't really know how to decode.   The admin password is currently fidgit1.  Any advice most welcome!

« Last Edit: February 27, 2020, 10:53:07 AM by les-70 »
Logged

johnson

  • Reg Member
  • ***
  • Posts: 838
Re: about to test a SBG3300-N000 but dissapointed re the chipset and firmware
« Reply #1 on: February 27, 2020, 12:52:42 PM »

Not sure if it will work as the hashes in /etc/passwd are sometimes truncated, but:

dpJNRD7c6NAdo
Gives:
dlwzztgb

As a descrypt, DES (Unix), Traditional DES hash.
Logged

les-70

  • Kitizen
  • ****
  • Posts: 1254
Re: about to test a SBG3300-N000 but dissapointed re the chipset and firmware
« Reply #2 on: February 27, 2020, 01:37:23 PM »

 I am now most puzzled.  The supervisor password is different every boot.
  I now get
 > cat /etc/passwd
supervisor:On2YY/J2896G.:0:0:Administrator:/:/bin/sh
admin:uAJKqXIY9yCNM:1:0:Administrator:/:/bin/sh
zyuser:qEe2Nd4v/adTc:2:2:User:/:/bin/sh
 > cat var/csamu
supervisor TkRWTVJiQS5ydVRxZ3p5YWQxMjM0MDM4MzQ1NjgyOAA=
support c3VwcG9ydAA=
user dXNlcgA=
admin ZmlkZ2l0MQA=
zyuser MTIzNAA=

 @johnson

     Many thanks for that decode.  For info your decode matches the first 8 characters of decode of the corresponding cat /var/csamu command so I guess it is correct even if it does not work.  I had not noticed that suppervisor info was changing each boot and the first post does not have matching outputs.  In the current boot up I have tried all the obvious parts of the long cat /var/csamu  supervisor password.  i.e. NDVMRbA.ruTqgzyad12340383456828.  ps is there an online tool for such des decodes?

Maybe it is  time to just see how it performs on the line. I am still puzzled re. whether it is a 63168 device or as many posts suggest 6368.
« Last Edit: February 27, 2020, 03:40:20 PM by les-70 »
Logged

johnson

  • Reg Member
  • ***
  • Posts: 838
Re: about to test a SBG3300-N000 but dissapointed re the chipset and firmware
« Reply #3 on: February 27, 2020, 01:54:28 PM »

Ah ok, no dice on the supervisor password then.

As for the chipset, for reference a VMG1312 gives:
Code: [Select]
~ # cat /proc/cpuinfo
system type             : 963168VX
processor               : 0
cpu model               : Broadcom4350 V8.0
BogoMIPS                : 398.33

So 963168VX vs 963168MXH_17A from your device, maybe the MX rather than VX denotes a different version, eg 63138?
Logged

burakkucat

  • Respected
  • Senior Kitizen
  • *
  • Posts: 38300
  • Over the Rainbow Bridge
    • The ELRepo Project
Re: about to test a SBG3300-N000 but dissapointed re the chipset and firmware
« Reply #4 on: February 27, 2020, 05:24:12 PM »

The DES crypt() function will return a 13 character string, of which the first two characters are the salt. The salt is exactly 2 characters and the key is no more than 8 characters.

Looking at the problem from the other direction, I take the known key ,"dlwzztgb", the two salts, "dp" & "On", and create the two individual 13 character strings. Those two strings should match what les-70 has observed.

Sample code, named check.c --

Code: [Select]
#define _XOPEN_SOURCE
#include <unistd.h>
#include <stdio.h>

/*
 * char *crypt(const char *key, const char *salt);
 *
 * Link with -lcrypt.
 *
 */

int main()
{
const char *key = "dlwzztgb";

/* dpJNRD7c6NAdo */
const char *salt1 = "dp";

/* On2YY/J2896G. */
const char *salt2 = "On";

printf("\ncrypt(\"%s\", \"%s\") returns \"%s\"\n", key, salt1, crypt(key, salt1));

printf("crypt(\"%s\", \"%s\") returns \"%s\"\n\n", key, salt2, crypt(key, salt2));

return 0;
}

Compiled --

Code: [Select]
[bcat ~]$ cc -lcrypt -o check check.c
[bcat ~]$

Executed --

Code: [Select]
[bcat ~]$ check

crypt("dlwzztgb", "dp") returns "dpJNRD7c6NAdo"
crypt("dlwzztgb", "On") returns "On5VNc9bUa/v."

[bcat ~]$

The above confirms that "dlwzztgb" is, indeed, correct for the first salt/key pair but not for the second.  :o

[Edited to adjust the last sentence.]
« Last Edit: February 27, 2020, 07:59:52 PM by burakkucat »
Logged
:cat:  100% Linux and, previously, Unix. Co-founder of the ELRepo Project.

Please consider making a donation to support the running of this site.

meritez

  • Content Team
  • Kitizen
  • *
  • Posts: 1627
Re: about to test a SBG3300-N000 but dissapointed re the chipset and firmware
« Reply #5 on: February 27, 2020, 06:15:23 PM »

@les-70 what firmware version are you running, as I'm reading the changelog and it states:

Modifications in V1.01(AADY.5)b3 01/11/2017:
[Feature Change]
1. [ITS 160401064][SPR 170111231] Warwicknet - SBG3500-N -
A2pvbF039n DSL modem code version

Though further down I see:
Modifications in V1.00(AADY.4)b3 | 03/14/2014
[FEATURE CHANGE]
1. Update DSL driver to A2x024m; Update bonding mode modem
code to A2pvbF039g1

Modifications in V1.00(AADY.3)b5 | 12/10/2013
[FEATURE CHANGE]
1. [FEATURE ENHANCEMENT] : Upgrade the ModemCode to
"A2pv6F038n" and "AdslDrv_linux4.02_A2x024i"

ftp://ftp.zyxel.com/SBG3300-N000/firmware/SBG3300-N000_1.01(AADY.9)C0_2.pdf
Logged

les-70

  • Kitizen
  • ****
  • Posts: 1254
Re: about to test a SBG3300-N000 but dissapointed re the chipset and firmware
« Reply #6 on: February 27, 2020, 06:55:23 PM »

 I think it is the latest, it is V1.01(AADY.9)C0.bin.
Logged

les-70

  • Kitizen
  • ****
  • Posts: 1254
Re: about to test a SBG3300-N000 but dissapointed re the chipset and firmware
« Reply #7 on: February 27, 2020, 07:02:37 PM »

The above confirms that "dlwzztgb" is, indeed, correct.

  Unfortunately I had no luck using dlwzztgb but given that result.  I will persist and try it again tomorrow. It is not convenient to have a go this evening.
Logged

johnson

  • Reg Member
  • ***
  • Posts: 838
Re: about to test a SBG3300-N000 but dissapointed re the chipset and firmware
« Reply #8 on: February 27, 2020, 07:03:23 PM »

@bcat

Scratched my head for a bit but:
Code: [Select]
crypt("dlwzztgb", "On") returns "On5VNc9bUa/v."

Should be On2YY/J2896G.

As I tried to crack On2YY/J2896G. and exhausted the search space with the same all lower case 8 char parameters.
Logged

burakkucat

  • Respected
  • Senior Kitizen
  • *
  • Posts: 38300
  • Over the Rainbow Bridge
    • The ELRepo Project
Re: about to test a SBG3300-N000 but dissapointed re the chipset and firmware
« Reply #9 on: February 27, 2020, 07:56:54 PM »

@bcat

Scratched my head for a bit but:
Code: [Select]
crypt("dlwzztgb", "On") returns "On5VNc9bUa/v."

Should be On2YY/J2896G.

As I tried to crack On2YY/J2896G. and exhausted the search space with the same all lower case 8 char parameters.

Hmm . . . I saw what i wanted to see and not what was shown.  :-[  Something is definitely not right.  :paperbag:
Logged
:cat:  100% Linux and, previously, Unix. Co-founder of the ELRepo Project.

Please consider making a donation to support the running of this site.

johnson

  • Reg Member
  • ***
  • Posts: 838
Re: about to test a SBG3300-N000 but dissapointed re the chipset and firmware
« Reply #10 on: February 27, 2020, 11:43:00 PM »

Hmm . . . I saw what i wanted to see and not what was shown.  :-[  Something is definitely not right.  :paperbag:

I did it too looking at the post! Starts right, ends right, has a slash in, seems right to me...
Logged

les-70

  • Kitizen
  • ****
  • Posts: 1254
Re: about to test a SBG3300-N000 but dissapointed re the chipset and firmware
« Reply #11 on: February 28, 2020, 04:09:55 PM »

 Still no luck re the supervisor account but not to worry.  I have the  SBG3300 up and running now.  All seems fine the gui is not brilliant in response but it responds a lot quicker than a VMG1312.  The sync has proved very similar to an HG612 in speed.  Compared with the VMG1312 running with the 39x firmware the SBG330 is about 0.3Mb/s slower downstream but 0.3Mb/s faster upstream i.e. similar.  I have noticed that speed advantage of 63168 modems seems to have much diminished over time, presumably due to cross talk.  It is too soon to make a call on error rates but my hope is that like the HG612 it will not show the odd really big crc ses peaks that 63168 modems seem prone to on my line.

    If I don't find a way soon I will probably start a separate post on how to get ping restricted to specific IP adresses.  The DoS option in the firewall let you turn the WAN ping on and off.  With it on I have an access control entry which turns ping off when used on own and two entries to allow specific ip's to have access.  However no matter the order they don't allow the specific pings.   I will continue to see if there is another way or what is wrong.  any advice would be most welcome!!! ICMP is not included under remote management as on the vmg1312.

The current rules are
                from     to              source                   destination
1 tbb         WAN ROUTER     80.249.99.164/32     Router          ICMP  ACCEPT      
2 uno        WAN   ROUTER   95.215.174.0/24   Router      ICMP   ACCEPT   
3 block      WAN   ROUTER   Any                           Router        ICMP   DROP
Logged

burakkucat

  • Respected
  • Senior Kitizen
  • *
  • Posts: 38300
  • Over the Rainbow Bridge
    • The ELRepo Project
Re: about to test a SBG3300-N000 but dissapointed re the chipset and firmware
« Reply #12 on: February 28, 2020, 04:34:47 PM »

The current rules are
                from     to              source                   destination
1 tbb         WAN ROUTER     80.249.99.164/32     Router          ICMP  ACCEPT      
2 uno        WAN   ROUTER   95.215.174.0/24   Router      ICMP   ACCEPT   
3 block      WAN   ROUTER   Any                           Router        ICMP   DROP

That snippet of the IPv4 firewall rules looks good, to me.
Logged
:cat:  100% Linux and, previously, Unix. Co-founder of the ELRepo Project.

Please consider making a donation to support the running of this site.

les-70

  • Kitizen
  • ****
  • Posts: 1254
Re: about to test a SBG3300-N000 but dissapointed re the chipset and firmware
« Reply #13 on: February 28, 2020, 06:51:36 PM »

 It is all very odd.  I have enabled logging on the rules and firewall in general.  Shields up pings show as they should as blocked with drop rule.  There is then no sign of the TBB and uno pings being blocked by the drop rule. 

 Oddly if I disable the the tbb and uno rules there is no log of them being then blocked.

 If I disable the WAN ping under DoS there is as expected no sign of any rule blocking. 

 With WAN ping enabled and no rules enabled ping works from all IP but uno and ttb!!

 I can reproduce the issue with shields up.  I created a rule to accept shields up IP and it worked with pings working from shields up.  I then changed that to a drop rule and got a passed stealth test.  However returning the rule to accept or even deleting that rule it remained in stealth. 

 Assuming the rules are not in permanent memory it looks like I need a reboot to get rid of what I did before.  This seems a dissapointing feature!

Logged

burakkucat

  • Respected
  • Senior Kitizen
  • *
  • Posts: 38300
  • Over the Rainbow Bridge
    • The ELRepo Project
Re: about to test a SBG3300-N000 but dissapointed re the chipset and firmware
« Reply #14 on: February 28, 2020, 09:20:09 PM »

GRC's ShieldsUP! is a useful and quick to use utility. However it does, at times, return wrong information.

In the past, I have run an nmap scan for forum members, and am prepared to do so for anyone who wishes. I just have to be trusted with the knowledge of a member's IPv4 address.
Logged
:cat:  100% Linux and, previously, Unix. Co-founder of the ELRepo Project.

Please consider making a donation to support the running of this site.
Pages: [1] 2