My Cloud PR4100 Firmware Analysis


#131

In the case of the EX4100 you appear to be correct. Based on the examples you posted, the EX4100 uses a UBI file system, likely stored on partitioned NAND flash memory.

The PR4100 is very different, using ordinary files, stored on partitioned eMMC flash memory. Unfortunately, I do not own an EX4100, and only have a PR4100 for analysis and testing.


#132

I wasn’t having a go or anything :slight_smile: Sorry if I came across a bit harsh.


#133

No problem, I could have worded it better, and just wanted to highlight the differences between the two NAS boxes.


#134

Firmware version 2.30.172 was released yesterday (11/16/2017), so I extracted the root filesystem (image.cfs) from the firmware bin file and used WinMerge to do a full comparison with firmware version 2.30.165. The linux kernel and the intrid appear to be identical, so I didn’t bother comparing them.

Here are the results, showing files that are different.

bin\winbindd
default\config.xml
etc\init.d\onbrdnetloccommd
files\static_crond_list
language\cs-CZ\english_cs-cz.xml
language\de-DE\english_de-de.xml
language\es-ES\english_es-es.xml
language\fr-FR\english_fr-fr.xml
language\hu-HU\english_hu-hu.xml
language\it_IT\english_it-it.xml
language\ja-JP\english_ja-jp.xml
language\ko-KR\english_ko-kr.xml
language\nl-NL\english_nl-nl.xml
language\no-NO\english_no-no.xml
language\pl-PL\english_pl-pl.xml
language\pt-BR\english_pt-br.xml
language\ru-RU\english_ru-RU.xml
language\sv-SE\english_sv-se.xml
language\tr-TR\english_tr-tr.xml
language\zh-CN\english_zh-cn.xml
language\zh-TW\english_zh-tw.xml
lib\libcrypto.so.1.0.0
lib\liblber-2.4.so.2.10.2
lib\libldap-2.4.so.2.10.2
lib\libpython2.7.so.1.0
lib\libsmbd-base-samba4.so
localbin\onbrdnetloccomm
localorion\communicationmanager\communicationmanager
rest-api\api\Core\src\Core\NasController.php
rest-api\api\Version\src\Version\ComponentVersion\build-number
script\system_init
usrsbin\e2igrow
usrsbin\logwdmsg
usrsbin\random_chk_central

#135

So basically 2/5ths of f#$% all and pretty much what was in the Release Notes only. Pretty disappointing :frowning:


#136

While examining the source code, I kept coming across references to something called the REST SDK, but never bothered to investigate because it looked like more of the same stuff I’d like to eventually remove for a custom local-only NAS firmware build. Eventually, I’d like to incorporate VPN functionality, in lieu of cloud-based functionality, but I’d rather focus on the basics first.

Curiosity got the best of me, so I looked up the REST SDK to see what it is. The words “cloud-based” were all I needed to see. However, portions of the dashboard UI may depend on the REST SDK, so removing it may not be possible.


#137

To see if the REST SDK is critical to basic dashboard functionality, I decided to perform a simple test.

First, I killed the restsdk-server process, which is started from the /usr/sbin/system_init file.

System Init:

#restsdk-server start according to Ed +20150721.VODKA
if [ -f /etc/init.d/restsdk-serverd ]; then
	/etc/init.d/restsdk-serverd start
fi

REST SDK Server:

# /usr/local/restsdk/restsdk-server --help
Usage of /usr/local/restsdk/restsdk-server:
  -device-kind string
        Device kind, 'sequoia' or 'alpha'
  -port int
        Port for the http server. (default 8181)

The dashboard continued to function normally, so I took it a step further, just to be certain. The directory /var/www/ is the root of the Apache web server, and the bulk of the REST API seems to reside in the /var/www/rest-api/ folder.

# mv /var/www/rest-api /var/www/rest-api-x

The dashboard continued to function normally, so it’s likely safe to assume that the REST SDK is only required for cloud-based functionality.


#138

With the goal of modifying the PR4100 firmware to operate as a basic local-only file server in mind, I’ve begun compiling a list of things to remove. This is a risky process, and everything to be removed is contained within the image.cfs file, which will make performing tests relatively easy. The paths shown originate within the firmware GPL source code file.

Keep in mind that cloud-based functionality, and many other “features” are of no interest to me.

Startup Scripts:

	firmware\module\crfs\etc\init.d
		AddVolumes.py
		atop
		commgrd
		onbrdnetloccommd
		restsdk-serverd
		wdmcserverd
		wdphotodbmergerd
		wdnotifierd
		
	firmware\module\crfs\etc\sysinit.d
		admin-rest-api
		comm-manager
		onbrdnetloc-comm
		restsdk
		wdlog
		wdmcserver
		wdnotifier

Cron Jobs:

	firmware\module\crfs\etc\cron.d
		rescan_internal_volumes
		wdlog

Configuration Files:

	firmware\module\crfs\etc\apache2\conf.d
		orionversion.conf
		
	firmware\module\crfs\etc\apache2\sites-available
		wdnas-rest-api.conf
		wdnas-rest-api-trusted.conf
		wdnas-ui.conf
		
	firmware\module\crfs\etc\rsyslog.d
		wddispatcher.conf
		wdlog.conf
		
	firmware\module\crfs\etc
		smtp.conf
		
	firmware\module\crfs\etc\nas
		wdlog.ini
		wdnotifier.conf
		
	firmware\module\crfs\etc\nas\notify.d
		wddispatcher.conf
		wdmcserver.conf
		
	firmware\module\crfs\etc\nas\log-filters
		kern.log.filter

Binary Files:

	firmware\module\crfs\bin
		rotatelogs
	
	firmware\module\crfs\sbin
		elephantdrive
		elephantdriveDaemon
	
	firmware\module\crfs\usrsbin
		elephant_drive
		s3
		
	firmware\module\crfs\usrsbin
		ganalytics
		
	firmware\module\crfs\cgi\backup_mgr
		s3.cgi

Scripts:

	firmware\module\crfs\script
		media_analytics.sh
		traceroute_wd.sh
		twonky_analytics.sh
		twonky_rebuild.sh
		twonky_reset.sh
		wd_crontab.sh
		wd_rotate.sh
		wdappmgr_log_stats.py
		
	firmware\module\crfs\sysinit.d
		admin-rest-api
		
	firmware\module\crfs\usrsbin
		ga_cron.sh

Remove All:

	firmware\module\crfs\etc\nas
	firmware\module\crfs\etc\wdcomp.d
	firmware\module\crfs\firefly
	firmware\module\crfs\localnas\orion
	firmware\module\crfs\localonboarding
	firmware\module\crfs\localorion
	firmware\module\crfs\localrestsdk
	firmware\module\crfs\localwddirect
	firmware\module\crfs\localwdmcserver
	firmware\module\crfs\rest-api
	firmware\module\crfs\twonky
	firmware\module\crfs\wdcomp.d

#139

Success! However, there were some unexpected surprises.

First, I removed everything listed and created/uploaded a new image.cfs file, but rebooting resulted in the Linux kernel being erased, and the NAS being rebooted into the rescue firmware. The dmesg logs showed few clues, so I decided to edit the system_init script and add some echo messages to help narrow things down.

init started: BusyBox v1.20.2 (2014-10-30 15:29:55 CST)
starting pid 1152, tty '': '/etc/rc.sh'
initramfs: mount all in /etc/fstab
sh: hotPlug.sh: not found
sh: hotPlug.sh: not found
initramfs: wait for EMMC being setup . . . .
umount: can't umount /usr/local/tmp/image.cfs: No such file or directory
[   10.140929] random: nonblocking pool is initialized
[   10.449630] EXT4-fs (mmcblk0p4): recovery complete
[   10.455976] EXT4-fs (mmcblk0p4): mounted filesystem with ordered data mode.
image len = 26 , image checksum = 0
f_stat.st_size = 101316608
file size not match
Erase kernel

Some unknown process appears to be checking the image.cfs file, and if the file has been altered (or is damaged), the Linux kernel is erased to trigger booting into the rescue firmware. However, editing the system_init script seems to have stopped the Linux kernel from being erased, but I don’t know why. Currently, I believe the process checks the timestamp of the system_init script, but it’s just a working theory.

After editing the system_init script, the NAS booted normally, except that the dashboard didn’t work, which was traced back to the Apache httpd service failing to start. Through trial and error, I was able to trace the Apache httpd problem back to the rotatelogs process. Further investigation is required, but for whatever reason, the Apache httpd service will not run if rotatelogs is deleted.

Regardless of the issues encountered, the deletion process has resulted in a fully functional NAS, with a fraction of the junk that plagued it previously. And this is only the beginning…


#140

I believe I’ve found the process responsible for checking the image.cfs file and erasing the Linux kernel. The process is called chk_image and it’s located in the rc.sh file, which is part of the uRamdisk (initramfs) file.

# This one need the mount from util-linux, busybox's one can't handle LABEL
#echo "initramfs: mounting label=image.cfs partition"
#mount -t ext4 LABEL=image.cfs /usr/local/tmp

chk_image

#echo "initramfs: mounting squashfs'd image.cfs"
#${MOUNT_CMD} -t squashfs -o loop /usr/local/tmp/image.cfs /usr/local/modules

The rc.sh file is a script that’s ran just before the system_init script.

echo "initramfs: running realworld system_init"
/usr/local/modules/script/system_init

#141

It was an epic battle, but I finally have the firmware “almost” entirely functional from a USB flash drive. I say almost, because it still depends on the eMMC config and backup partitions, but I’m not certain I can change that because of the stupid WD compiled binary files. It doesn’t mean I won’t try however.

Regardless, the firmware now boots using the uImage, uRamdisk, and image.cfs files on the USB stick, which makes building and testing firmware a snap.

I also learned that the firmware ABSOLUTELY must be built on a Linux ext4 formatted partition, or the firmware will appear to function correctly, when in fact it does not. In addition, closer examination revealed that the dashboard does, at least in part, rely on portions of the REST SDK. Further investigation is required.


#142

While reviewing the boot process output to see the effect of changes I’ve been making, I noticed something which didn’t seem right. The full boot process output can only be seen while connected to the UART port via a serial console.

initramfs: checking integrity of system partitions (/dev/mmcb)

Having become quite familiar with the hardware of the PR4100, I was reasonably certain that the /dev/mmcb device didn’t exist, so I located the code behind the message to see what was going on. The code is contained within the uRamdisk initial ramdisk file. Specifically, it’s located within the /etc/rc.sh script, which is executed every time the system boots.

Original Code:

echo -n "initramfs: checking integrity of system partitions "
ucpd="$(blkid | grep 'wdnas_efi' | awk -F: '{ print $1}')"
ucpd="${ucpd:0:9}"
echo "($ucpd)"
# 1st: vfat EFI
if stat "${ucpd}1" >/dev/null 2>&1; then
	dosfsck -p ${ucpd}1 2>/dev/null
else
	echo "initramfs: cannot find devnode: ${ucpd}1"
fi
# all others ext4
for i in $(seq 2 9); do
	if stat "${ucpd}$i" >/dev/null 2>&1; then
	  if [ "$i" = "6" ] || [ "$i" = "9" ]; then
	    e2fsck -p "${ucpd}$i" 2>/dev/null || e2fsck -f -y "${ucpd}$i"
	  else
		  e2fsck -p "${ucpd}$i" 2>/dev/null
	  fi
	else
		echo "initramfs: cannot find devnode: ${ucpd}$i"
	fi
done

Original Code Output:

initramfs: checking integrity of system partitions (/dev/mmcb)
initramfs: cannot find devnode: /dev/mmcb1
initramfs: cannot find devnode: /dev/mmcb2
initramfs: cannot find devnode: /dev/mmcb3
initramfs: cannot find devnode: /dev/mmcb4
initramfs: cannot find devnode: /dev/mmcb5
initramfs: cannot find devnode: /dev/mmcb6
initramfs: cannot find devnode: /dev/mmcb7
initramfs: cannot find devnode: /dev/mmcb8
initramfs: cannot find devnode: /dev/mmcb9

As it turns out, the programmers had made a very simple mistake, which caused the code to fail to check the system partitions as it was intended to do. In the following code snippet, the first line assigns the result of commands to a variable, and the second line returns a portion of the string within the original variable. Specifically, it returns the first 9 characters of the string.

ucpd="$(blkid | grep 'wdnas_efi' | awk -F: '{ print $1}')"
ucpd="${ucpd:0:9}"

The following command returns a list of all system partitions, each of which has a label starting with “wdnas_”, making them easier to identify.

blkid | grep 'wdnas_' | awk -F: '{ print $1}'

/dev/mmcblk0p1
/dev/mmcblk0p2
/dev/mmcblk0p3
/dev/mmcblk0p4
/dev/mmcblk0p5
/dev/mmcblk0p6
/dev/mmcblk0p7
/dev/mmcblk0p8
/dev/mmcblk0p9

The first 9 character of each of them are “/dev/mmcb”, which explains the /dev/mmcb1 to /dev/mmcb9 results returned by the loop within the code.

ucpd="$(blkid | grep 'wdnas_efi' | awk -F: '{ print $1}')";
ucpd="${ucpd:0:9}";
echo "($ucpd)"

(/dev/mmcb)

To fix the code, one simply has to change the 9 to 13 so that the correct portion of the string is returned for processing by the loop.

ucpd="$(blkid | grep 'wdnas_efi' | awk -F: '{ print $1}')";
ucpd="${ucpd:0:13}";
echo "($ucpd)"

(/dev/mmcblk0p)

Afterwards, the code correctly identifies each of the system partitions, using dosfsck to check the first vfat partition, and e2fsck to check the remaining ext4 partitions.

Fixed Code:

echo -n "initramfs: checking integrity of system partitions "
ucpd="$(blkid | grep 'wdnas_efi' | awk -F: '{ print $1}')"
ucpd="${ucpd:0:13}"
echo "($ucpd)"
# 1st: vfat EFI
if stat "${ucpd}1" >/dev/null 2>&1; then
	dosfsck -p ${ucpd}1 2>/dev/null
else
	echo "initramfs: cannot find devnode: ${ucpd}1"
fi
# all others ext4
for i in $(seq 2 9); do
	if stat "${ucpd}$i" >/dev/null 2>&1; then
		if [ "$i" = "6" ] || [ "$i" = "9" ]; then
			e2fsck -p "${ucpd}$i" 2>/dev/null || e2fsck -f -y "${ucpd}$i"
		else
			e2fsck -p "${ucpd}$i" 2>/dev/null
		fi
	else
		echo "initramfs: cannot find devnode: ${ucpd}$i"
	fi
done

Fixed Code Output:

initramfs: checking integrity of system partitions (/dev/mmcblk0p)
fsck.fat 3.0.26 (2014-03-07)
/
  Bad short file name ().
  Auto-renaming it.
  Renamed to
/dev/mmcblk0p1: 6 files, 1118/70544 clusters
wdnas_kernel: clean, 11/2560 files, 7091/10240 blocks
wdnas_initramfs: clean, 11/2560 files, 5204/10240 blocks
wdnas_image.cfs: clean, 11/65536 files, 37774/262144 blocks
wdnas_rescue_fw: clean, 15/10240 files, 34900/40960 blocks
wdnas_config: recovering journal
wdnas_config: clean, 84/5136 files, 2659/20480 blocks
wdnas_reserve1: clean, 10/2560 files, 1433/10240 blocks
wdnas_reserve2: clean, 11/2560 files, 1434/10240 blocks
wdnas_backup: clean, 84/5136 files, 2621/20480 blocks

The “Bad short file name ()” message is the result of a bug in dosfstools-3.0.26 which was fixed in dosfstools-3.0.27.


#143

The following is a list of everything I’ve removed from the PR4100 firmware to date, loosely categorized. With the exception of Cloud functionality, Twonky, etc, the NAS functions normally.

I’m certain more can be removed, but everything is so interconnected that it takes time. I also plan to eventually modify the dashboard after a good foundation has been laid. Like the old saying goes, start at the bottom and work your way up.

Miscellaneous:

firmware/module/crfs/default/onbrd.ini
firmware/module/crfs/default/orion.db
firmware/module/crfs/etc/apache2/conf.d/orionversion.conf
firmware/module/crfs/etc/init.d/AddVolumes.py
firmware/module/crfs/etc/init.d/atop
firmware/module/crfs/etc/init.d/commgrd
firmware/module/crfs/etc/init.d/onbrdnetloccommd
firmware/module/crfs/etc/nas/wdlog.ini
firmware/module/crfs/etc/sysinit.d/comm-manager
firmware/module/crfs/etc/sysinit.d/onbrdnetloc-comm
firmware/module/crfs/etc/sysinit.d/wdlog
firmware/module/crfs/etc/sysinit.d/wdnotifier
firmware/module/crfs/etc/rsyslog.d/wdlog.conf
firmware/module/crfs/localnas
firmware/module/crfs/localonboarding
firmware/module/crfs/localorion
firmware/module/crfs/localsbin/wd2go.sh
firmware/module/crfs/localwddirect
firmware/module/crfs/script/getHddWhiteList.sh
firmware/module/crfs/script/wdappmgr_log_stats.py
firmware/module/crfs/script/wd_rotate.sh

Cron Jobs:

firmware/module/crfs/script/wd_crontab.sh
firmware/module/crfs/etc/cron.d/rescan_internal_volumes
firmware/module/crfs/etc/cron.d/wdlog
firmware/module/crfs/files/static_crond_list

Services and Apps:

firmware/module/crfs/sbin/elephantdrive
firmware/module/crfs/sbin/elephantdriveDaemon
firmware/module/crfs/usrsbin/elephant_drive
firmware/module/crfs/usrsbin/s3
firmware/module/crfs/default/s3.conf
firmware/module/crfs/cgi/backup_mgr/s3.cgi

Tracking and Analytics:

firmware/module/crfs/localsbin/wdLogUploader.sh
firmware/module/crfs/usrsbin/ga_cron.sh
firmware/module/crfs/script/media_analytics.sh
firmware/module/crfs/script/traceroute_wd.sh
firmware/module/crfs/usrsbin/ganalytics

Twonky:

firmware/module/crfs/script/twonky_analytics.sh
firmware/module/crfs/script/twonky_rebuild.sh
firmware/module/crfs/script/twonky_reset.sh
firmware/module/crfs/twonky

Media Scanning:

firmware/module/crfs/etc/nas/notify.d/wdmcserver.conf
firmware/module/crfs/etc/init.d/wdphotodbmergerd
firmware/module/crfs/etc/init.d/wdmcserverd
firmware/module/crfs/etc/sysinit.d/wdmcserver
firmware/module/crfs/localsbin/wdmc_rescan_volume.py
firmware/module/crfs/localwdmcserver
firmware/module/crfs/firefly

#144

Not if you know how…


#145

That will only remove the symbolic link, wouldn’t you also need to remove /mnt/HD/HD_b2/Public as well ? I suspect that link in /shares will come back after a reboot of the unit.


#146

Good catch, I wondered if anyone would see it. Honestly, I didn’t catch it myself until after the image was posted. I occasionally use the Public folder to move files between devices, so I never actually executed the command.


#147

Now this is interesting…

Source (/usr/sbin/system_init):

echo "sysinit: check mfg_mode"
if [ -e /tmp/mfg_mode ]; then
	touch /tmp/boot_finished
	touch /tmp/system_ready
	# for mfg
	mfg_start
else
	touch /tmp/boot_finished
	# restore rebuild speed to default
	echo "sysinit: md_sync_speed.sh max"
	md_sync_speed.sh max
fi

Output (/usr/sbin/mfg_start):

mfg_start version 1.01

root@MyCloudPR4100 root # Fri Nov 24 12:33:41 2017

filename_mfg [mfg_MyCloudPR4100]
count of USB volume= 1
mfg_start check [ 1 ]
mnt pnt [/mnt/USB/USB1_d1]
usb_dir [/mnt/USB/USB1_d1]
check /mnt/USB/USB1_d1/mfg_MyCloudPR4100 file
open  /mnt/USB/USB1_d1/mfg_MyCloudPR4100 file failed
mfg_start abnormal exit

The file /usr/sbin/mfg_start is a compiled binary, that when executed, looks for a file named mfg_MyCloudPR4100 on an attached USB flash drive. I suspect it’s a special firmware bin file, but have no way to confirm this.

Interestingly, the mfg_start executable contains strings like sn00py and fun_plug. It’s only a guess, but sn00py looks like a password, but to what? A backdoor maybe?

The fun_plug file is referenced earlier in the system_init script, and I believe it’s either a script or an empty file, who’s presence (or absence) is used as a flag.

echo "sysinit: check usb devices for fun_plug"
for i in `ls /mnt/USB/`
do
	#echo "/mnt/USB/${i}/mfg_${nas_model_name}"
	#echo "/mnt/USB/${i}/fun_plug"
	if [ -e /mnt/USB/${i}/mfg_${nas_model_name} -a -e /mnt/USB/${i}/fun_plug ]; then
		#echo "Into MFG mode"
		touch /tmp/mfg_mode
	fi
done

I hadn’t noticed it before, but the RAID rebuild speed is set back to maximum near the end of the system_init script, after previously having been set to the minimum. I suspect the speed is altered to reduce the CPU load and/or HDD activity for faster booting.

md_sync_speed.sh min
md_sync_speed.sh max


#148

Lets give the /usr/sbin/mfg_start file what it’s looking for and see what happens.

# /usr/sbin/mfg_start

mfg_start version 1.01

root@MyCloudPR4100 root # Fri Nov 24 12:33:41 2017

filename_mfg [mfg_MyCloudPR4100]
count of USB volume= 1
mfg_start check [ 1 ]
mnt pnt [/mnt/USB/USB1_d1]
usb_dir [/mnt/USB/USB1_d1]
check /mnt/USB/USB1_d1/mfg_MyCloudPR4100 file
open  /mnt/USB/USB1_d1/mfg_MyCloudPR4100 file failed
mfg_start abnormal exit

Create an empty mfg_MyCloudPR4100 file and try again.

# touch /mnt/USB/USB1_d1/mfg_MyCloudPR4100
# /usr/sbin/mfg_start

mfg_start version 1.01

root@MyCloudPR4100 USB1_d1 # Fri Nov 24 13:12:18 2017

filename_mfg [mfg_MyCloudPR4100]
count of USB volume= 1
mfg_start check [ 1 ]
mnt pnt [/mnt/USB/USB1_d1]
usb_dir [/mnt/USB/USB1_d1]
check /mnt/USB/USB1_d1/mfg_MyCloudPR4100 file
Can't find "mfg_MyCloudPR4100" string
mfg_start abnormal exit

Append a “mfg_MyCloudPR4100” string to the mfg_MyCloudPR4100 file and try again.

# echo "mfg_MyCloudPR4100" >> /mnt/USB/USB1_d1/mfg_MyCloudPR4100
# /usr/sbin/mfg_start

mfg_start version 1.01

root@MyCloudPR4100 USB1_d1 # Fri Nov 24 13:13:49 2017

filename_mfg [mfg_MyCloudPR4100]
count of USB volume= 1
mfg_start check [ 1 ]
mnt pnt [/mnt/USB/USB1_d1]
usb_dir [/mnt/USB/USB1_d1]
check /mnt/USB/USB1_d1/mfg_MyCloudPR4100 file
Can't find magic "sn00py" string
mfg_start abnormal exit

Append a “sn00py” string to the mfg_MyCloudPR4100 file and try again.

# echo "sn00py" >> /mnt/USB/USB1_d1/mfg_MyCloudPR4100
# /usr/sbin/mfg_start

mfg_start version 1.01

Fri Nov 24 13:14:16 2017

root@MyCloudPR4100 USB1_d1 # filename_mfg [mfg_MyCloudPR4100]
count of USB volume= 1
mfg_start check [ 1 ]
mnt pnt [/mnt/USB/USB1_d1]
usb_dir [/mnt/USB/USB1_d1]
check /mnt/USB/USB1_d1/mfg_MyCloudPR4100 file
check /mnt/USB/USB1_d1/fun_plug
fun_plug does not exist [/mnt/USB/USB1_d1/fun_plug]
mfg_start abnormal exit

Create an empty fun_plug file and try again.

# touch /mnt/USB/USB1_d1/fun_plug
# /usr/sbin/mfg_start

mfg_start version 1.01

root@MyCloudPR4100 USB1_d1 # Fri Nov 24 13:14:49 2017

filename_mfg [mfg_MyCloudPR4100]
count of USB volume= 1
mfg_start check [ 1 ]
mnt pnt [/mnt/USB/USB1_d1]
usb_dir [/mnt/USB/USB1_d1]
check /mnt/USB/USB1_d1/mfg_MyCloudPR4100 file
check /mnt/USB/USB1_d1/fun_plug
sh /mnt/USB/USB1_d1/fun_plug /mnt/USB/USB1_d1/
mfg_start done

Append some simple sh script strings to the fun_plug file and try again.

# echo "#!/bin/sh" >> /mnt/USB/USB1_d1/fun_plug
# echo "echo 'hello world'" >> /mnt/USB/USB1_d1/fun_plug
# /usr/sbin/mfg_start

mfg_start version 1.01

root@MyCloudPR4100 USB1_d1 # Fri Nov 24 13:37:06 2017

filename_mfg [mfg_MyCloudPR4100]
count of USB volume= 1
mfg_start check [ 1 ]
mnt pnt [/mnt/USB/USB1_d1]
usb_dir [/mnt/USB/USB1_d1]
check /mnt/USB/USB1_d1/mfg_MyCloudPR4100 file
check /mnt/USB/USB1_d1/fun_plug
sh /mnt/USB/USB1_d1/fun_plug /mnt/USB/USB1_d1/
hello world
mfg_start done

Verify that it searches all attached USB flash drives after moving the mfg_MyCloudPR4100 and fun_plug files to another USB flash drive.

# /usr/sbin/mfg_start

mfg_start version 1.01

Fri Nov 24 13:49:40 2017

root@MyCloudPR4100 USB3_e1 # filename_mfg [mfg_MyCloudPR4100]
count of USB volume= 2
mfg_start check [ 1 ]
mnt pnt [/mnt/USB/USB1_d1]
usb_dir [/mnt/USB/USB1_d1]
check /mnt/USB/USB1_d1/mfg_MyCloudPR4100 file
open  /mnt/USB/USB1_d1/mfg_MyCloudPR4100 file failed
mfg_start check [ 2 ]
mnt pnt [/mnt/USB/USB3_e1]
usb_dir [/mnt/USB/USB3_e1]
check /mnt/USB/USB3_e1/mfg_MyCloudPR4100 file
check /mnt/USB/USB3_e1/fun_plug
sh /mnt/USB/USB3_e1/fun_plug /mnt/USB/USB3_e1/
hello world
mfg_start done

Success!

Every time the NAS boots, the /usr/sbin/mfg_start binary executable searches all attached USB flash drives for a file named mfg_MyCloudPR4100 which contains the strings mfg_MyCloudPR4100 and sn00py on separate lines. If found, it then looks for a fun_plug sh script file, and executes it.


#149

An original alternative to /etc/init.d with some USB flash drive sauce.
It doesn’t touch the internal flash so it’s arguably better than the cron mods! :wink:


#150

The /usr/sbin/mfg_start binary executable seems to put the firmware into some kind of special manufacturer mode, in addition to executing the fun_plug script. However, I have not yet investigated further. So far, I know that the user shares are not available on the network, and there seems to be some differences when cloud access is enabled. For example, the doughnut space chart does not appear.

Speaking of USB, I’m cooking up something good… very good.