LS-GL Custom Updater Thread - ACP-Commander

jonli447 · **Posted:** Fri Nov 03, 2006 7:23 pm

Per Georg requests...

He're is the thread for creating a custom firmware updater. This is an continuation of the thread http://buffalo.nas-central.org/forums/index.php?action=vthread&forum=16&topic=1501 that sort of divided into two subtopics: telnet/root-enabled fw and custom updater. So the updater portion is continuing here. Thanks

EricC · **Posted:** Sat Nov 04, 2006 9:11 pm

Hello,

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:

Code:

1. Computer broadcasts UDP packet to 255.255.255.255 port 22936 
20 00 00 00 08 00 01 00 20 80 
00 00  = Payload Size (No Payload) 
00 00 00 00 
00 c0 9f xx xx xx Source Mac Address 
ff ff ff ff ff ff     Destination Mac Address 
00 00 00 00 
 
 
2. LinkStation Pro responds with UDP packet to 255.255.255.255 (Port is the port used by the computer query) 
20 00 00 00 09 00 01 00 20 c0 
20 01   = Payload Size 
00 00 00 00 
00 16 01 xx xx xx  =  Source Mac Address 
00 c0 9f xx xx xx   = Destination Mac Address 
00 00 00 00 
--Payload-- 
xx xx a8 c0   = IP Addess of the box with most significant byte last   01 02 a8 c0 is 192.168.2.1 
00 ff ff ff       = Net Mask with most significant byte last 
00 00 00 00 64 fe aa 48 
xx xx xx xx xx xx xx xx xx xx xx xx xx xx xx xx = Host Name (16 bytes) Null Terminated String 
00 
xx xx xx xx xx xx xx xx xx xx xx xx xx xx xx = Workgroup (15 bytes) Null Terminated String 
00 
LS-GL(IESADA)  = Product ID Null Terminated String 
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 
00 00 00 00 00 25 02 00 00 00 00 00 00 00 00 d6 
07 0b 00 04 00 0c 00 2f 00 08 00 
xx xx a8 c0  = Default Gateway 
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 
01   = Major Version? 
00   = Minor Version? 
00 00 
09 00 00 00 = Product ID Number? 00000009 
2006/06/28 09:42:00   = Root FS Timestamp Null Terminated String 
00 00 00 00 00 
HDD 0.42  = Hard Disk Driver or Hardware Detection Driver Version?  Second part of Version string (1.00-0.42) 
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 
00 00 00 00 00 00 00 08 01 
FLASH 0.00  = Firmware Subversion Null Terminated String 
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 
2006/06/11 14:33:21 = Kernel Timestamp Null Terminated String 
00 00 00 00 00 
00 16 01 xx xx xx  LSE Mac Address 
 00 00 00 
 
After update the LinkStation Pro sent: 
20 00 00 00 09 00 01 00 20 c0 
20 01 = Payload Size 
00 00 00 00 
00 16 01 xx xx xx  = Source Mac Address 
00 c0 9f xx xx xx  = Dest Mac Address 
00 00 00 00 
-- Payload -- 
xx xx a8 c0   = IP Addess of the box with most significant byte last   01 02 a8 c0 is 192.168.2.1 
00 ff ff ff       = Net Mask with most significant byte last 
00 00 00 00 19 f6 8f 1e 
xx xx xx xx xx xx xx xx xx xx xx xx xx xx xx xx = Host Name (16 bytes) Null Terminated String 
00 
xx xx xx xx xx xx xx xx xx xx xx xx xx xx xx = Workgroup (15 bytes) Null Terminated String 
00 
LS-GL(IESADA)  = Product ID Null Terminated String 
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 
00 00 00 00 00 25 02 00 00 00 00 00 00 00 00 d6 
07 0b 00 03 00 16 00 35 00 11 00 
xx xx a8 c0  = Default Gateway 
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 
01   = Major Version? 
03   = Minor Version? 
00 00 
09 00 00 00 = Product ID Number? 00000009 
2006/10/16 16:03:19   = Root FS Timestamp Null Terminated String 
00 00 00 00 00 
HDD 0.47  = Hard Disk Driver or Hardware Detection Driver Version?  Second part of Version string  (1.03-0.47 ) 
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 
00 00 00 00 00 00 00 00 00 08 01 
FLASH 0.00   = Firnware Subversion Null Terminated String 
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 
00 00 00 00 00 00 
2006/08/08 17:16:01   = Kernel Timestamp Null Terminated String 
00 00 00 00 00 
00 16 01 xx xx xx  MAC Address 
00 00 00 

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.

73 Eric

EricC · **Posted:** Sun Nov 05, 2006 1:51 am

Hello,

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

I looked at the ethereal log file some more. The LinkStation Pro (LSP) listens on Port 22936.
This port seems to be used for everything dealing with updating.

Find Phase
1. Computer sends an UDP Packet from Computer IP Port nnn to 255.255.255.255 Port 22936
Appears to be an information query

2. LSP sends an UDP Packet from LSP IP Port 22936 to 255.255.255.255 Port nnn (same as computer)
Contains information structures (Network and version)

Update Phase
1. Computer sends an UDP Packet from Computer IP Port nnn to LSP IP Port 22936
Appears to be an information query

2. LSP sends an UDP Packet from LSP IP Port 22936 to Computer IP Port nnn
Contains information structures (Network and version)

3. Computer sends an UDP Packet from Computer IP Port nnn to LSP IP Port 22936
Appears to be a sending data structure Possibly a password

4. LSP sends an UDP Packet from LSP IP Port 22936 to Computer IP Port nnn
Appears to be an ack, possibly indicating Password is good)

5. Computer sends an UDP Packet from Computer IP Port nnn to LSP IP Port 22936
Structure that has a command string "cat /proc/buffalo/firmware"

6. LSP sends an UDP Packet from LSP IP Port 22936 to Computer IP Port nnn
Output of command:
PRODUCTNAME=LS-GL(IESADA)
VERSION=0.08
SUBVERSION=FLASH 0.00
PRODUCTID=0x00000009
BUILDDATE=2006/06/11 14:33:21
BOOTVER=1.01

7. Computer sends an UDP Packet from Computer IP Port nnn to LSP IP Port 22936
Structure that has a command string "cat /etc/initrd_ver"

8. LSP sends an UDP Packet from LSP IP Port 22936 to Computer IP Port nnn
Output of command:
VERSION=0.09
SUBVERSION=RAM 0.00
PRODUCTID=0x00000009
BUILDDATE=2006/06/11 14:51:39

9. Computer sends an UDP Packet from Computer IP Port nnn to LSP IP Port 22936
Mostly 00 bytes

10. LSP sends an UDP Packet from LSP IP Port 22936 to Computer IP Port nnn
Appears to be an ack

11. Computer sends an UDP Packet from Computer IP Port nnn to LSP IP Port 22936
Data structures including string "!/boot/uImage.buffalo"

12. LSP sends an UDP Packet from LSP IP Port 22936 to Computer IP Port nnn
Appears to be an ack

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.

73 Eric

jonli447 · **Posted:** Sun Nov 05, 2006 4:54 am

EricC wrote:

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.

Georg · **Posted:** Sun Nov 05, 2006 8:37 pm

@jonli, thanks for the special Wink

@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).

Code:

 
[Application] 
Title = Buffalo LS-GL updater 
WaitReboot = 180 (0xB4) #Int 
WaitFormat = 180 (0xB4) #Int 
WaitChange = 180 (0xB4) #Int 
 
[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? 
 
[Flags] 
VersionCheck = 0 #Int 
 
[SpecialFlags] 
Debug = 0    #Int; enables debug-mode in the updater (via context-menu in title bar) 

So three new values (WaitFormat, WaitChange and Debug). If you set Debug to 1 you get a nice new entry in the context menu at the title-bar of the updater. There you can choose if you want to

- update: Kernel, Boot, initrd, rootfs (separately)
- config: version check, rebuild partitition table, delete user config, force update
- destination of firmware: /boot
- IP-Address/DHCP

The first two set of options might make live somewhat easier.

lb_worm · **Posted:** Sun Nov 05, 2006 8:50 pm

This is rather neat. Updating the kernel ,initrd and rootfs is good. To remove any un-necessary flashing of the flash is a good choice. This will aid development.

EricC · **Posted:** Sun Nov 05, 2006 9:59 pm

Hello,

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.

73 Eric

Georg · **Posted:** Mon Nov 06, 2006 9:28 pm

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?

mindbender · **Posted:** Mon Nov 06, 2006 10:00 pm

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

then we need a failsave way to get into EM mode.....with a telnet + ftp enabled EM Mode we can simply upload the custom hddrootfs & untar it there.....

thats the exact thing i am working on all other boxes.

jonli447 · **Posted:** Tue Nov 07, 2006 5:40 am

mindbender wrote:

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).

mindbender · **Posted:** Tue Nov 07, 2006 7:01 am

and having no weird untaring of any config files over our rootfs.

-> thats the main reason why i want to create this....we had severe problems with OpenLink/FreeLink where /etc/passwd was restored also beside much other stuff.

Georg · **Posted:** Wed Nov 08, 2006 8:37 pm

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

http://buffalo.nas-central.org/download/uploads/LS_Pro_temporary/LSPro_Softw.rtf

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.

Miconapl is quite interesting. As lb_worm and mindbender explain it is used for communication with the hardware
http://buffalo.nas-central.org/forums/index.php?action=vthread&forum=19&topic=1556&page=0#msg15075

@mindbender: good luck for your exam!

jonli447 · **Posted:** Sat Nov 11, 2006 6:09 am

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.

EricC · **Posted:** Sun Nov 12, 2006 4:25 am

Hello,

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.

Code:

root@LS-GLFDC:/etc/init.d# clientUtil_server -f -d -i eth0 
no fork 
start at debug mode 
clientUtil_server Ver.1.01 
--- no fork 
listen device name = eth0 
>RecvFromSocket: --> cli=192.168.57.111 len=32 
==========< ACPHeader >========== 
0x22400: --<DumpAcphPacket>-- len=64 
000: 20 00 00 00 08 00 01 00 
008: 20 80 00 00 00 00 00 00 
010: 00 C0 9F D9 B7 1D FF FF 
018: FF FF FF FF 00 00 00 00 
020: 00 00 00 00 00 00 00 00 
028: 00 00 00 00 00 00 00 00 
030: 00 00 00 00 00 00 00 00 
038: 00 00 00 00 00 00 00 00 
 
header_size=0x20        packet_version=0x10008 
option_size=0   command=0x8020 
connection_id=00:C0:9F:D9:B7:1D 
destination_id=FF:FF:FF:FF:FF:FF 
result=0 
 
4555e5e7: ***** ACP_Discover_Reply 
 
4555e5e7: ***** FillDiscoverReplyPacket 
  gateway = 0x139a8c0 
>SendDiscoverReply:0 
>SendReplyPacket:cmd[c020] result[0] ip[ffffffff] datalen[288] 
  host_name  = LS-GLFDC 
  group_name = TEST 
  product    = LS-GL(IESADA) 
  flag       = 0 
  IP Address = 0xe39a8c0 
  optlen     = 288 
==========< ACPHeader >========== 
0x3bad0: --<DumpAcphPacket>-- len=64 
000: 20 00 00 00 09 00 01 00 
008: 20 C0 20 01 00 00 00 00 
010: 00 16 01 41 0F DC 00 C0 
018: 9F D9 B7 1D 00 00 00 00 
020: C0 A8 39 0E FF FF FF 00 
028: 00 00 00 00 76 94 19 38 
030: 4C 53 2D 47 4C 46 44 43 
038: 00 00 00 00 00 00 00 00 
 
header_size=0x20        packet_version=0x10009 
option_size=288 command=0xC020 
connection_id=00:16:01:41:0F:DC 
destination_id=00:C0:9F:D9:B7:1D 
result=0 
----< ACPHReply >---- 
ip=192.168.57.14        mask=255.255.255.0 
flag=       0 [] 
key=38199476 
hostname=[LS-GLFDC] 
product=[LS-GL(IESADA)] 
hardware_info=   0 
capacity_high=       0 
capacity_low=       0 
y/m/d/h/m/s=2006/11/11 10:1:59 
gateway=0139a8c0 
DNS1=00000000 DNS2=00000000 
WINS1=00000000 WINS2=00000000 
VERSION=1.3 
product_id=9 
build_date=[2006/11/10 16:03:19] 
sub_verion=[HDD 0.47] 
FLASH_VERSION=0.8       FLASH_SUBVERSION=[FLASH 0.00] 
FLASH_BUILDDATE=[2006/11/06 13:47:08] 
starting_mode=1 
eth0_mac=00:16:01:41:0F:DC 
>SendPacket:src=5998 dst=450 ip=ffffffff len=320 

73 Eric

Georg · **Posted:** Sun Nov 12, 2006 9:43 am

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.

Buffalo NAS-Central Forums

LS-GL Custom Updater Thread - ACP-Commander

Who is online