I just recently got a Linkstation Pro and after a little trouble updated it with Firmware 1.03 got telnet w/o root password going. I logged the session with ethereal.

Some information about the Version 1.03 updater that is on the NA site as part of the 1.03 firmware update.In the lsupdater.ini file changing VersionCheck under the Flags section from 1 to 0 will disable the version check so an updated box will show up in the inital scan. The box can not be updated again as the program still checks the dates on the box.

Code:

[Flags] VersionCheck = 0

The following dump is mixed hex and text. xx 23 5b... are hex and 2006/08 or LS-GL are text.The sequence:

This appears to be a status information query and response. More fields could be figured out by changing settings on the LS Pro, and then use the firmware updater to generate the query while logging with ethereal.

13. TCP Session starts from the Computer IP Port nnn to LSP IP Port 22936 Appears to be the kernel

After the TCP session ends, there are a couple more UDP packets between the computer and LSP, then another TCP session to upload the next file. At the end there are some more UDP packets. After the LSP is rebooted the computer sends a query ocassionally until the LSP responds.

I do not know if the focus is to modify the existing windows exe or build a new one.

Depending on how difficult the steps, ideally, we would probably just modify the Buffalo updater exe...then again, it looks as if we'd have a lot of stuff to change, so we might have to just build our own "linkstationwiki updater". Basically, we're trying to bypass the version checks and make it optional to save/restore settings. Obviously, some of that will depend on the flasher on the box itself. Nice info, it's much appreciated.

@jonli, thanks for the special @Eric, thanks for the details of the update process!

Well, with Heinz script I think, understanding the updater becomes less important. The standard updater works for our needs (we know how to enable telnet and get our own updates on the box). On the other side. There's no harm to get and understand as much information as possible. Anyway without a box there is little that I can acutally do at the moment. So another look at the updater:

At 0040c480 starts the routine readint the lsupdater.ini file. At least most of it (given are the standard values that are used if the value is not defined in the ini).

[Target] Password = password #string; could that be the root-pswd?? Or is it for the (scrambled) rsync Name = LS-GL # string; name shows up in searching respective not found message window; Must it ma tch the device name?

I was looking at the debug entry and only got as far as noting that it also disabled the version check during the find phase, I did not think of checking the context menu.

I approached it by breakpointing the readprivateprofile function entry points in the debugger and seeing what was passed. I have 0x3c as the default value for wait change.

If an user can force upload of the same version of files then it eliminates the need for a custom uploader. Although it would be nice to have a tool under linux to query and update the box. I hate to have to switch between linux and windows.

I finally got ftp setup on my LSP and use it like it was intended. It is fast on my gigabit network. I was thinking of getting wget going on the box so I can use it as an personal mirror site of SuSE updates. So I am looking at setting up cross compiling on my notebook.

Having the debug option - is there anything left we *need* from an updater? If all that works as the debug dialog suggests, the update process should be pretty that what we need: Selection of what to update and bypass of version checking (but I've only a quite rough idea of uboot/kernel development - so forgive me if I'm wrong).

The other side is further understanding the update process maybe for a linux/mac updater as Eric suggests?

As far as I understand it at the moment, the udp traffic is handled by /usr/local/sbin/lsprcvd. That seems to initiate a rsfwds-session on port 8873. Somewhere I read that this seems to be a rsyncd with openssh encryption. Strings shows that also lsprcvd uses openssh. As these are using openssh - shouldn't be there gpl-sources (maybe from the other *stations)?

\usr\local\bin\ls_sonar seems to be the linux scanner for linkstations see also BufBackupSonar.pm in www section.\usr\local\bin\rsbackup.pl is the backup script used by the web-interface. Guess prinicipially the updater works similar for the tcp-part Eric describes. In line 332 the script seems to read a passwd from a temp-file. Could be interesting - or is it a passwd you have to enter in the web-interface?

in my personal opinion it should be the goal to create a telnet enabled ramdisk (which implements EM Mode).

I've read your thread about this; I think that's a good idea too. I think though that we must have a backup prog for updating the custom firmware should the ramdisk fail for users. But, like I said, you are right in that a telnet enabled ramdisk should be the #1 goal as it would pull all of our objectives into one method (gaining remote EM acess, simple updating procedure, and simple and almost transparent way to reset root passwords).

Had a look at some of the programs in the file system - mostly by running strings on them. Hoped to gather some more information how the update process works, but didn't stick to only that. Compiled the information collected so far in a small doc that I uploaded to

Guess that most of the information is already available in another place...Some of the programs seem to have a debug mode. The strings ls_sonar and clientUtil_server seem to confirm Erics analysis of the network traffic.

Guys (especially Georg), I'd greatly appreciate if you could document any efforts made here in my wiki page under Custom Updater. I am trying to consolidate all of the development information so that the development team can easily sort the stuff out.

@Georg, I'm sorry that I spawned the idea of a custom updater (actually mindbender gave me the idea) and haven't been able to help you dissassemble the updater. I've been extremely busy w/ my wife, school, work, and computer crisis. I'll will look at your work in my spare time. Any time will you have to add your info to the wiki page will definately help me, mindbender, and others to sort all of this out. Again, sorry, but thanks.

I got a chance to do some more work with the LSP. In particular I wanted to use debug mode to dump the comunications on the LSP side.

I found that lsprcvd does not have anything to do with updating. I can stop it and the unit will be discovered and updated.

I looked at clientUtil_server. It is watched by daemonwatch so at first it kept restarting when I stopped it. After I stopped daemonwatch then I was able to stop clientUtil_server. With it stopped the box was not discovered. I then ran it with the -i eth0 -f -d parameters and got debug dumps off the console.

Eric, great that should help us to understand the traffic much better! I guess that the procedure to open the TCP-port is the same for the updater and the backup (rsync maybe with ssl) between two LS. Hope to get my box by end of the month.

Who is online

Users browsing this forum: No registered users and 1 guest

You cannot post new topics in this forumYou cannot reply to topics in this forumYou cannot edit your posts in this forumYou cannot delete your posts in this forumYou cannot post attachments in this forum