DSM-G600, DNS-3xx and NSA-220 Hack Forum

cyboc · 2007-07-14 07:40:29

Hello Gentlemen (and Ladies if there are any out there),

I'm new to this forum. I'm also new to the DNS-323. I just got it yesterday and I'm already getting busy hacking it with the funky fun_plug.

Has anyone else been bothered by the password restrictions enforced by the web interface in version 1.03 of the firmware (and I assume earlier versions too)? If you haven't heard yet, the web interface restricts you to passwords between 5 and 8 characters and alphanumeric only (i.e. symbols like $*#, etc, are not allowed). Bummer. Of course, I sent a complaint to D-Link right away. Weak passwords stink.

Anyway, I'm not going to wait around for them to fix it. I've been fiddling with workarounds and have been pretty successful so far. I'm going to share what I have learned and what I have done so far. I'm sure someone smarter than me can build on this.

Some of you may know this information already but in doing some searches of this forum and the wiki, I couldn't find it in writing. So I thought it might be a good idea to share it here.

First, the web pages are located at /sys/crfs/web_page. This directory is symlinked from /web/web in the script /etc/rc.sh. The webpage that enforces the password policy is /sys/crfs/web_page/advanced/user_account.asp. The actual enforcement is done by some JavaScript functions. To fix it, I simply commented out the offending code. Specifically, I commented out the if statement the checks for password > 8 characters and the if statement that checks for symbol characters (I left the minimum 5 character check):

Code:

/*
        if (document.form.f_WEB_PASSWD.value.length > 8)
        {
                alert("The password length cannot exceed 8 characters.");
                document.form.f_WEB_PASSWD.select();
                document.form.f_WEB_PASSWD.focus();
                return;
        }
*/

/*
        var text=document.form.f_WEB_PASSWD.value;
        re=/^[a-zA-Z0-9]{1,8}$/;
        if(!re.test(text))
        {
                alert("The password can not include the following characters:  \ / : * ? \" < > | . ; + = ~ \' [ ] { } @ # ( ) ! ^ $ % & , _ -");
                document.form.f_WEB_PASSWD.select();
                document.form.f_WEB_PASSWD.focus();
                return false;
        }
*/

IMPORTANT: I did not edit the original file. I have read that some firmwares for devices such as this have a checksum in the header and if you modify any of the files in the flash, the checksum can fail and the device will fail to boot. I have no idea if this applies to the DNS-323, but I thought I would play it safe. I don't want to make a brick.

What I did was I recursively copied all of the files in /sys/crfs/web_page to /mnt/HD_a2/, thereby creating /mnt/HD_a2/web_page. Next, I deleted the symlink from /web/web to /sys/crfs/web_page. Next, I symlinked /web/web to /mnt/HD_a2/web_page. After that, I made my changes to /mnt/HD_a2/web_page/advanced/user_account.asp. Then, voila, the check was removed.

(Note, I manually unsymlinked and symlinked in a telnet session but you can certainly automate it in fun_plug)

There IS a limitation with this, however. When you change the password with the web interface, it gets stored correctly in smbpasswd (for network access - i.e. samba access). However, it gets truncated to a maximum of 8 characters in passwd (for telnet and ftp access).

This truncating "feature" might be hard to fix without replacing the firmware. The truncating seems to be done by the crypt() function in uClibc. In other words, it seems to be hardcoded right into library. Apparently, the firmware uses a version (an old version?) of uClibc that has this limitation. In other versions, the limitation has been removed. I can't see a way around this without getting the newer crypt() code, recompiling the library and rebuilding the firmware. By all means, please correct me if my assumptions are wrong.

Anyway, my fix is good enough for my needs at the moment. I wanted to synchronize the samba passwords in smbpasswd with my Windows passwords which are all longer than 8 characters and contain many symbols. Now I can easily connect to samba shares on the DNS-323 from my windows boxes in Explorer instead of having to use a funky "net use" command. I'm somewhat pleased.

Hope this helps someone else. Any comments?

(BTW, yes I realize that I can also set the passwords from the command prompt with passwd and smbpasswd but some of the people who are using this device wanted to be able to set the passwords with the web interface.)

Last edited by cyboc (2007-07-14 08:16:52)

Emacs · 2007-07-14 20:43:48

Hi cyboc,

that's cool - but a little overkill, isn't it?

I just telnet'ed into the box and changed the passwords with "passwd" - no restrictions.

Cheers,

Emacs

cyboc · 2007-07-15 00:06:43

Emacs wrote:
Hi cyboc,

that's cool - but a little overkill, isn't it?

Of course it's overkill! Hehe! Didn't you read the last paragraph of my post?:

cyboc wrote:
(BTW, yes I realize that I can also set the passwords from the command prompt with passwd and smbpasswd but some of the people who are using this device wanted to be able to set the passwords with the web interface.)

Some of the other people that will be administering this device are NOT very comfortable with the command line. They only want to use the web interface. :-P

Anyway, some good side effects of this technique is that I can easily change the other web pages, if the need should arise.

Ultimately, I'd like to upgrade the version of the library that has crypt() so that we aren't limited to 8 characters for passwd passwords.

Last edited by cyboc (2007-07-15 00:09:24)

fonz · 2007-07-15 00:24:23

cyboc wrote:
Ultimately, I'd like to upgrade the version of the library that has crypt() so that we aren't limited to 8 characters for passwd passwords.

I think that's uclibc - the heart of the whole firmware. AFAIK, the only reasonable way to upgrade uclibc is to boot your own system.

transstilben · 2007-07-15 00:24:44

Cyboc, i see one more advantage of your method compared with EMACS method:

Maybe i'm wrong but as far as i understood the problem after using passwd in a telnet session
for the admin account i would not be able to use the web interface any more
because you cannot enter passwords longer than eight characters there, right ?

So if for some reason one would loose the telnet access there is no way to get
into the box again (exept factory reset) because telnet doesn't work and the web interface
doesn't allow longer passwords than eight characters ?

fonz · 2007-07-15 00:27:01

cyboc wrote:
Anyway, some good side effects of this technique is that I can easily change the other web pages, if the need should arise.

User and group management pages suck really bad (at least in fw 1.02)

cyboc · 2007-07-15 00:45:25

fonz wrote:
I think that's uclibc - the heart of the whole firmware. AFAIK, the only reasonable way to upgrade uclibc is to boot your own system.

Yes, I believe you are probably correct.

cyboc · 2007-07-15 00:47:43

fonz wrote:
User and group management pages suck really bad (at least in fw 1.02)

Still sucks in 1.03 too! Hehe.

cyboc · 2007-07-15 01:01:19

transstilben wrote:
Cyboc, i see one more advantage of your method compared with EMACS method:

Maybe i'm wrong but as far as i understood the problem after using passwd in a telnet session
for the admin account i would not be able to use the web interface any more
because you cannot enter passwords longer than eight characters there, right ?

So if for some reason one would loose the telnet access there is no way to get
into the box again (exept factory reset) because telnet doesn't work and the web interface
doesn't allow longer passwords than eight characters ?

transstilben,

I'm not exactly sure what you are getting it but let me try to explain what seems to happen behind the scenes when you create users with the web interface. When you create a user with the web interface, it puts that user in both the passwd file and the smbpasswd file. With my web page hack, you can enter a password longer than 8 characters and also you can use symbol characters. If the password is longer than 8 characters, it gets truncated to 8 characters by uClibc's crypt() function before it is stored in passwd. In contrast, the entire password seems to get stored in smbpasswd.

For example, if the password is 1234567890, that's what gets stored in smbpasswd. However only 12345678 gets stored in passwd. So, you can still telnet in but you only use the first 8 characters of the password (8 characters would also be used for ftp). For samba access, you would use all 10 characters.

If you use the passwd and smbpasswd commands directly, you get the same results (i.e. truncation for passwd passwords). Note that from the command line, you must run TWO commands. From the web-if, it's a two for one deal.

The nice thing about my hack is that I have eliminated the javascript that prevents you from using symbol characters in the password. Note that from the command line, it allows symbols without a hack.

Until someone finds a way to upgrade crypt(), if you want exact passwd and smbpasswd synchronization, you'll have to limit your passwords to 8 characters. But you can still comment out the symbol character check in the javascript so that you can at least use some symbols.

Last edited by cyboc (2007-07-15 01:04:08)

hennemtk · 2007-07-16 12:47:45

Hi,

if you change passwords with smbpasswd directly the new passwords don't survive a reboot of the DNS. Any quick idea how to get around that?

Tom

cyboc · 2007-07-17 02:24:06

hennemtk wrote:
Hi,

if you change passwords with smbpasswd directly the new passwords don't survive a reboot of the DNS. Any quick idea how to get around that?

Tom

hennemtk,

Good catch. With firmware 1.03, I can reproduce the same problem. That is, changing passwords with smbpasswd does not seem to survive a reboot. I also tried it with passwd and I see the same behavior. That sucks.

So, it seems that when you use the web interface to change passwords, it does some extra step that passwd and smbpasswd don't do. Naturally, I spent some time trying to figure what that extra step is.

The first place is looked was modify_user.asp, which is the web page you use to change an existing user's password. Looking at the code, you can see that the "action" for that form is "/goform/modify_user". goform? What is that all about? Read on!

I found a pretty good explanation of goform in this forum. It turns out that the DNS uses the GoAhead webserver to implement the web interface. Apparently, actions of the form "/goform/some_action" get mapped to a handler function (written in C, I believe) at compile time and are compiled right into the webserver's binary. Thus, it is difficult to determine exactly what the DNS does when you try to change a user's password with the web interface.

Having said that, using other techniques, you can indirectly figure out what is happening behind the scenes. Let me explain. I created a dummy file on the hard drive called foobar.txt. Then I changed a user's name with the web interface and immediately ran this command afterwards:

Code:

find / -newer foobar.txt | grep -v proc | more

That command shows you any files that have a modification time more recent that foobar.txt, except for any files in proc, which I think would just be noise really. Here's what it returned:

Code:

/dev/console
/dev/ptyp0
/etc
/etc/mtab
/etc/samba/smbpasswd
/etc/shadow
/tmp

I think the only ones that matter are /etc/samba/smbpasswd and /etc/shadow. Next I touched foobar.txt to update the mod time and then manually set passwords with passwd and smbpasswd. Then I re-ran the find command. The results were the same!

I knew something else was probably going on. I figured the web interface must be writing some other shadow and smbpasswd files, besides the ones in etc. I found some clues in rc.sh:

Code:

----snip----
echo "** copy mtd1 files"
cp -f /sys/mtd1/hosts /etc/hosts
cp -f /sys/mtd1/rc.init.sh /etc/rc.d/rc.init.sh
cp -f /sys/mtd1/resolv.conf /etc/resolv.conf
cp -f /sys/mtd1/passwd /etc/passwd
cp -f /sys/mtd1/shadow /etc/shadow
cp -f /sys/mtd1/group /etc/group
cp -f /sys/mtd1/sib.conf /web/sib.conf
cp -f /sys/mtd1/sib2.conf /web/sib2.conf
cp -f /sys/mtd1/sib_ap.conf /web/sib_ap.conf
cp -f /sys/mtd1/smbpasswd /etc/samba/smbpasswd
----snip----

Hmn, what's this /sys/mtd1? Perhaps the flash memory? I found some more clues in the forum. A-ha! It's probably, writing the changes to /sys/mtd1 in addition to /etc. Sure enough, when I changed the passwords and then mounted /sys/mtd1 before running find, I noticed that the web interface affects a few more files than doing it from the command line:

Code:

/sys/mtd1/group
/sys/mtd1/passwd
/sys/mtd1/shadow
/sys/mtd1/smbpasswd

So, mystery solved, perhaps. Unless I'm doing something wrong, it looks like you MUST change passwords with the web interface (f/w 1.03 anyway) if you want them to survive a reboot (unless you want to muck around with trying to write files on /sys/mtd1 -- but I suspect this might be a dangerous thing to do).

As a side note, I have opened a case with D-Link about the lame password restrictions. Their reponse was:

"Currently, we do not have a work around for this limitation. It will, however, be forwarded to the engineering and testing department for review. I don't have a timeline yet, though, of when a fix would be uploaded for public use."

I also sent an email to GoAhead.com asking them a few questions about their license. I'm not a lawyer but I'm not entirely sure if D-Link is fully complying with GoAhead's license. According to the license, D-Link is supposed to display some sort of GoAhead logo on the main web page ("You agree to promote the Original Code by prominently and visibly displaying a graphic of the GoAhead WebServer mark on the initial Web page of Your product that is displayed each time a user connects to it"). Also, if D-Link changes GoAhead's original files (as opposed to making new files), they have to send the changes to GoAhead (but not necessarily to us, the end users -- I'm not sure if I have interpreted things correctly).

fonz · 2007-07-17 02:40:07

Well done. A script doing all the steps would definitely be useful.
Btw, the GoAhead source code is available from the CH3SNAS GPL package. See http://dns323.kood.org/forum/t683-CH3SNAS.html.

cyboc · 2007-07-18 22:21:43

fonz wrote:
Well done. A script doing all the steps would definitely be useful.

Here's what I added to my fun_plug to script the web page customizations.

Code:

#
# Override standard webpages with some custom ones. 
#

# copying standard web pages
cp -R /sys/crfs/web_page /mnt/HD_a2
rm -r /mnt/HD_a2/website_root
mv /mnt/HD_a2/web_page /mnt/HD_a2/website_root

# overriding standard web pages with custom ones
cp -R /mnt/HD_a2/custom_web_pages/* /mnt/HD_a2/website_root

# removing original /web/web symlink
rm /web/web

# creating new /web/web symlink
ln -s /mnt/HD_a2/website_root /web/web

Notice that I start by copying ALL of the standard (i.e. stock D-Link) web pages from flash (well, I assume /sys/crfs is mapped to flash) to /mnt/HD_a2/website_root. Then I copy over any custom web pages from /mnt/HD_a2/custom_web_pages, which overrides any of the standard web pages that have the same name in /mnt/HD_a2/website_root.

I finish by relinking /web/web to /mnt/HD_a2/website_root, which gives the web server a new website root to use.

The script seems to work for me. Please let me know if you see any glaring errors or improvements that can be made. I'm not the best at shell scripting.

cyboc · 2007-07-19 21:38:57

My solution for creating passwords with symbols (e.g. !@#$%^&*) using the web interface is not yet complete. Recall that my solution involved removing the symbol check from the Javascript in the asp pages. Well, that worked fine for some passwords such as foo!bar but not for other passwords such as (foobar) or &&&&&.

So, what would happen when I tried to create a user with a password like &&&&&? When I clicked the Save Settings button, the values were submitted to the web server and a few seconds later, the page would refresh. However, the new user would NOT appear in the user list. Furthermore, there was NO error message! (BTW, if you are running the Firefox browser, a handy tool for seeing the HTTP conversation between the browser and the web server is Live HTTP Headers).

Hmn, no wonder D-Link checked for symbol characters in the Javascript! Well, as you will soon see, that symbol check was just a workaround for an inferior (IMHO) implementation of the action handler for the forms on the user_account.asp and modify_user.asp pages.

Okay, as I said in an earlier message in this thread, the DNS uses the embedded web server GoAhead WebServer. GoAhead features "in-process CGI forms processing". This "in-process" feature seems to be achieved by compiling the action handlers right in the web server binary. Unfortunately, although D-Link allows you to download the GoAhead source code, they don't include the code for the action handlers. Apparently, according to GoAhead's license FAQ, D-Link does not have to release the action handler code if it is in a separate source code file. You only have to release code if you modify the original source code files.

Note: To be fully compliant with the license, D-Link is supposed to put a GoAhead Mark (i.e. the GoAhead WebServer Logo) on the initial web page delivered by the DNS's web server. Sadly, D-Link does not do this (I could be wrong, but I don't see the logo on any pages).

So, what's a hacker to do in this situation? Well, as Fonz pointed out above, there is FULL source code available for Conceptronic's CH3SNAS, which appears to be pretty much a clone of the DNS. I downloaded that code last night. If you unzip CH3SNAS_GPL.tgz, you'll find goahead.tar.gz in there. If you unzip goahead.tar.gz you'll find that it has many of the same files as D-Link's goahead.tgz, PLUS a whole bunch of extra files. The most interesting extra file is web_api.c. That is the file I have been looking for! It has the implementation of all of the action handlers.

I saw some interesting things in web_api.c. For example, I saw #ifdef DLINK in several places! That makes me think that a third party implemented the action handlers and then handed off the code to Conceptronic and D-Link. For setting passwords, the important procedures in that file are modify_user (line 6740 in the version of the code I downloaded) and adduser (line 6174 in the version of the code I downloaded). When you look at how they are implemented, you can clearly see why the Javascript on the asp pages didn't want to allow symbol characters. Rather than using password API's (I think they exist, I could be wrong), the implementation builds a shell command string and then call the system() function in the C Standard Library to get the shell to execute it.

The problem is, some of the symbol characters have special meaning to the shell (e.g. & ( ) < > ; ' ` " |) and will not be interpreted as part of the password unless the password is wrapped by double quotes (e.g. mypassword should be changed to "mypassword" before sending the command to the shell). Furthermore, any double quotes that are in the password, must be escaped with the backslash (e.g. " should be changed to \"). Unfortunately, the implementation does NOT do any wrapping or escaping of the password! IMHO, this is just plain careless. Call me crazy. Furthermore, the implementation does not even check the return value of system() to see if an error occurred. That is why you don't get an error message when trying to save a password with those symbol characters. Again, IMHO, this is careless.

Here is a code snippet from adduser(), where you can clearly see what I mean:

Code:

//------------snip------------
if(strcmp(group,"NONE")==0)
{
    sprintf(buf,"adduser %s -p %s -h %s", name, passwd,FTPSERVER_PATH);
    system(buf);            
}
else
{
    UpdateFTPGroup();
    //ftp server had share group 
    if ( CheckFTPUserInGroup(group) == -1 )
    {
        strcpy(ftp_one_group_data.GroupName , group);
        GetOneGroupInfo(&ftp_one_group_data);
        GroupSetting = 1;
    }
    
    //add group of user to samba session

    checkUserInSmbconf(group,name);
    sprintf(buf,"adduser %s -g %s -p %s -h %s", name, group , passwd,FTPSERVER_PATH);
    system(buf);
    
    strcpy(GroupUser.group_name , group );
    GetGroupOfUserList( &GroupUser);
    if ( ( GroupSetting == 1 ) && ( GroupUser.NumOfUser > 1 ) )
    {
        add_ftp_user(name , ftp_one_group_data.SharePath , ftp_one_group_data.ReadWrite , 1 );
    }
    
}
sprintf(buf,"smbpasswd -a %s %s", name, passwd);
system(buf);
//------------snip------------

A workaround (combined with removing the Javascript checks -- see above message) is to manually wrap the password with doubles quotes and escape any embedded double quotes when you type the password on the HTML form. I tested this and it seems to work. The one place where you do NOT wrap and escape is the Old Password field on the modify_user.asp page. In that field, just enter the password as-is.

A better solution is to add some javascript to automatically do the wrapping and escaping. I'll work on that today and post the relevant snippets here when I'm done.

Ultimately, it would be great if one of us hackers could fix the C code ourselves, recompile the webserver (webs is the binary) and use fun_plug to replace the original. I'm not sure if this is difficult or even feasible (well, changing the code is easy enough but compiling and replacing webs might be trickier).

If you have any doubts about whether the shell command strings are built in webs, telnet to your DNS and do this grep:

Code:

/ # grep adduser /sys/crfs/web/webs
adv_adduser
adduser %s -p %s -h %s
adduser %s -g %s -p %s -h %s

Yup, the strings are there alright.

Okay, here is something else that is interesting in web_api.c. Check out CP_passwd_MTD1() on line 11348. That procedure gets called near the bottom of adduser() and modify_user() (and other procedures too) to commit the changes to flash. Heres the code:

Code:

static void CP_passwd_MTD1(void)
{
    system("mount -t minix /dev/mtdblock0 /sys/mtd1");
    system("cp -f /etc/passwd /sys/mtd1/.");
    system("cp -f /etc/group /sys/mtd1/.");
    system("cp -f /etc/shadow /sys/mtd1/.");
    system("cp -f /etc/samba/smbpasswd /sys/mtd1/.");

#ifdef DLINK
    if  ( del_ftp_flag == 1 )
    {
        system("cp -f /etc/ftp_tbl /sys/mtd1/.");
        system("cp -f /etc/ftpgroup /sys/mtd1/.");
    }
#endif    
    system("sync");
    system("umount /sys/mtd1");
    
    //+eve10122006
    system("mount -t minix /dev/mtdblock1 /sys/mtd2");
    system("cp -f /etc/passwd /sys/mtd2/.");
    system("cp -f /etc/group /sys/mtd2/.");
    system("cp -f /etc/shadow /sys/mtd2/.");
    system("cp -f /etc/samba/smbpasswd /sys/mtd2/.");
    #ifdef DLINK
    if  ( del_ftp_flag == 1 )
    {
        system("cp -f /etc/ftp_tbl /sys/mtd2/.");
        system("cp -f /etc/ftpgroup /sys/mtd2/.");
    }
    #endif
    system("sync");
    system("umount /sys/mtd2");
}

As I mentioned in a previous message in this thread, I suspected that this sort of commit must have been happening during processing of those HTML forms. You can clearly see the mount of the flash, the copying of various password related files (passwd, smbpasswd, shadow, etc) and the unmount. Perhaps this shows us the technique we need to safely write files on the flash!!!! I know that several people on this forum were wondering how to do that. I think this may help.

fonz · 2007-07-19 22:12:07

Very nice. Having your findings in a carefully coded shell script should greatly simplify ssh and telnet (with password) configurations.

Have you an idea why the files are copied to both mtd1 and 2? Are these two separate flash memories?

cyboc · 2007-07-19 23:18:19

fonz wrote:
Very nice. Having your findings in a carefully coded shell script should greatly simplify ssh and telnet (with password) configurations.

Hehe, are you volunteering to do that? :-)

fonz wrote:
Have you an idea why the files are copied to both mtd1 and 2? Are these two separate flash memories?

No idea. That looked strange to me too. Maybe it's a failsafe?

catohagen · 2007-07-20 01:14:26

omg! you guys are tearing this box apart i had a great read, kudos to you all

cyboc · 2007-07-20 06:51:26

cyboc wrote:
A better solution is to add some javascript to automatically do the wrapping and escaping. I'll work on that today and post the relevant snippets here when I'm done.

I have attached a zip file with my Javascript fixes to workaround some of the password bugs. The zip file contains:
* The original version of user_account.asp and modify_user.asp from D-Link's 1.03 firmware.
* My fixed version of user_account.asp and modify_user.asp.
* Patch files

Sorry if my Javascript style stinks. I'm not really a Javascript developer. In addition to my new asp files, you'll also need my fun_plug commands to install the new pages. See the message above that contains the text "Here's what I added to my fun_plug to script the web page customizations."

Keep in mind that this does not solve all password problems related to the web interface. Here is what is DOES solve:
* It will let you create passwd and smbpasswd passwords with symbol characters.
* It will let you create smbpasswd passwords that are longer than 8 characters

Here is what it does NOT solve: passwd passwords will still be truncated to 8 characters. To solve this, I think we will need to get the web server to use either a newer version of busybox for handling shell invocations of passwd and adduser. Perhaps Fonz can think of a way to do this? :-)

Last edited by cyboc (2007-07-20 06:55:06)

fonz · 2007-07-20 22:19:14

Copying passwd files to the flash seems to work fine. Haven't tested much, though.

The attached script only copies the files. Run it after "passwd" or "smbpasswd" to make the changes permanent.

trevoryour · 2007-08-09 18:05:37

I am certainly no expert when it comes to hacking hardware. I just purchased this device and it works great as designed except for the password limitations. It it extremely annoying that I can't change this. Our company has a password policy that the passwords must be at least 8 characters. I was hoping that somone out there has a simple step by step guide on how to fix this. I have seen a few suggestions in this forum but all of them make me uncomfortable. I don't have experience with this type of thing and I don't want to make a brick. Can someone give me a hand with this?

cyboc · 2007-08-09 19:27:16

trevoryour wrote:
I just purchased this device and it works great as designed except for the password limitations. It it extremely annoying that I can't change this. Our company has a password policy that the passwords must be at least 8 characters.

Yes, the password limitations TOTALLY suck. Weak passwords are totally unacceptable in a corporate environment. Some people may argue that the DNS should only be used in the home. But how many home users use RAID? It seems to mean that this device has an identity problem. The weak passwords suggest that it is for home use only but the RAID features (hehe...if they worked reliably) suggest it is for small office use.

It you dig through the source code, you'll realize that the weak passwords are due to D-Link using an EXTREMELY old version of the Busybox package that had to use the password functionality of the now deprecated Tinylogin package.

I mean, seriously, it is a JOKE that D-Link uses a PRE-RELEASE version of BusyBox (1.00-pre1, released in July 2003). The latest version available is 1.6.1, released in June 2007; it has much better password support and no longer needs Tinylogin (Tinylogin features were rolled into Busybox a few years ago). And, oh yeah, D-Link uses Samba 2.2.8a, released March 2003. Countless bugs and security holes have been fixed since then. The latest version is 3.0.25, released May 2007.

Shall I go on? In my extensive testing of this device, even with fw version 1.03, I have come to the conclusion that you can't count on this device to reliably store your data. I have seen numerous example of corrupted data. I'm not sure if the corruption is due to a bad RAID1 implementation or perhaps a bug in the pathetically old version of Samba they use. It's doesn't matter.

As far as an embedded Linux platform goes, I think this device has potential. It really does have some decent hardware. Maybe one day, someone like Fonz will find a way to completely replace the firmware. Until then, I would NOT recommend using this device in a corporate, mission critical environment. It is a fun little toy for hobbyists.

trevoryour wrote:
I was hoping that somone out there has a simple step by step guide on how to fix this. I have seen a few suggestions in this forum but all of them make me uncomfortable. I don't have experience with this type of thing and I don't want to make a brick. Can someone give me a hand with this?

This forum thread is about the closest thing to a step by step guide you will find. If you are not comfortable using it, I wouldn't. Either send the device back for a refund (that's what my company did) or keep it in storage until someone makes a decent firmware. You can end up wasting a lot of the company's time trying to workaround the password restrictions.

Just my two cents.

trevoryour · 2007-08-09 23:12:42

I am willing to give it a shot. If I brick it, I can always just return it anyway. The step I seem to be missing is the how exactly I am able to telnet to the device. I tried "telnet 192.168.0.32" but it doesn't respond. I also tried using SSH as well and that didn't work either. Is there something that needs to be done before I can successfully telnet to this thing? Yes I am on the same subnet. I can ping the device just fine.

trevoryour · 2007-08-09 23:24:36

Instructions on how to use this "fun_plug" and how to execute these scripts would be very helpful. It looks like the zip file "Passwordfix.zip" is the answer. I just need some instructions of the simplest way to implement it. Please keep in mind that while I have some linux experience I am certainly not anywhere close to being comfortable with it. I appreciate any help that anyone can give me with this.

cyboc · 2007-08-10 01:45:45

trevoryour wrote:
Instructions on how to use this "fun_plug" and how to execute these scripts would be very helpful.

Instructions for latest version of fun_plug are here: http://www.inreto.de/dns323/fun-plug/0.3/. You will find a link to the fun_plug package on that same page. If you can't find it, here is the direct link: http://www.inreto.de/dns323/fun-plug/0. … 0.3.tar.gz. Fonz's instructions are excellent so all but the most neophyte of Linux users should be able to follow it.

One important caveat is that the fun_plug script will not run (at all) if it has Windows line endings (CR + LF) instead of Unix line endings (LF)!

The fun_plug script inside funplug-0.3.tar.gz should have Unix line endings. However, when you "unpack funplug-0.3.tar.gz to the root of the first volume" as the instructions call for, you will get Windows line ending in that file if you use Winzip to unpack it. There are three fixes for that problem:
1) Use a Linux/Unix version of tar to unpack, or
2) Use a Windows implementation of tar from GnuWin32, or
3) Use Winzip but then use a program like EditPlus to convert the line endings back to Unix after unpacking.

MiK · 2007-08-10 02:14:24

cyboc wrote:
There are three fixes for that problem:

..or use WinRAR

/MiK

DSM-G600, DNS-3xx and NSA-220 Hack Forum

Announcement

#1 2007-07-14 07:40:29

Removing password restrictions

Code:

#2 2007-07-14 20:43:48

Re: Removing password restrictions

#3 2007-07-15 00:06:43

Re: Removing password restrictions

Emacs wrote:

cyboc wrote:

#4 2007-07-15 00:24:23

Re: Removing password restrictions

cyboc wrote:

#5 2007-07-15 00:24:44

Re: Removing password restrictions

#6 2007-07-15 00:27:01

Re: Removing password restrictions

cyboc wrote:

#7 2007-07-15 00:45:25

Re: Removing password restrictions

fonz wrote:

#8 2007-07-15 00:47:43

Re: Removing password restrictions

fonz wrote:

#9 2007-07-15 01:01:19

Re: Removing password restrictions

transstilben wrote:

#10 2007-07-16 12:47:45

Re: Removing password restrictions

#11 2007-07-17 02:24:06

Re: Removing password restrictions

hennemtk wrote:

Code:

Code:

Code:

Code:

#12 2007-07-17 02:40:07

Re: Removing password restrictions

#13 2007-07-18 22:21:43

Re: Removing password restrictions

fonz wrote:

Code:

#14 2007-07-19 21:38:57

Re: Removing password restrictions

Code:

Code:

Code:

#15 2007-07-19 22:12:07

Re: Removing password restrictions

#16 2007-07-19 23:18:19

Re: Removing password restrictions

fonz wrote:

fonz wrote:

#17 2007-07-20 01:14:26

Re: Removing password restrictions

#18 2007-07-20 06:51:26

Re: Removing password restrictions

cyboc wrote:

#19 2007-07-20 22:19:14

Re: Removing password restrictions

#20 2007-08-09 18:05:37

Re: Removing password restrictions

#21 2007-08-09 19:27:16

Re: Removing password restrictions

trevoryour wrote:

trevoryour wrote:

#22 2007-08-09 23:12:42

Re: Removing password restrictions

#23 2007-08-09 23:24:36

Re: Removing password restrictions

#24 2007-08-10 01:45:45

Re: Removing password restrictions

trevoryour wrote:

#25 2007-08-10 02:14:24

Re: Removing password restrictions

cyboc wrote:

Board footer