My Cloud PR4100 / PR2100 Firmware Analysis


#22

Lately, I’ve been analyzing each of the default system cron jobs and cron jobs which seem to be generated by various processes. My ultimate goal is to disable anything which isn’t needed, especially anything “Cloud” related. While my analysis is ongoing, one thing is abundantly clear.

Analytics and data logging processes are so pervasive, and often hidden in compiled binary files, that I’m having trouble tracking them all down. There are also far more firmware update processes than there need to be, which only serves to make me highly suspicious of the true purpose of these devices.

Case in point, the following is a list of system crontab programs/scripts and my early attempt to classify them into “Keep” or “Remove” categories. Notice a common theme? Logs, logs, and more logs. And it only gets worse when one digs a little deeper… In fact, I’m beginning to feel like Alice in Wonderland.

Keep:
./usr/sbin/auto_clear_recycle_bin.sh &

Maybe:
./usr/sbin/sysinfo_update.sh
/usr/sbin/stime&
./usr/sbin/getHddWhiteList.sh

Remove:
/usr/sbin/rlog -s /usr/local/modules/files/syslog_rotate.conf
/usr/sbin/quota_monitor &
/etc/init.d/atop ] && /etc/init.d/atop rotate
./usr/sbin/random_check -s &
./usr/sbin/expire.sh
/usr/local/sbin/ssl_cert_job.sh start > /var/log/ssl_cert_cron.out 2>&1
/usr/local/sbin/PullWdlogConfig.sh
/usr/sbin/daily_log_upload.sh &
/usr/sbin/traceroute_wd.sh &
./usr/sbin/logwdmsg -o &
./usr/sbin/wd_crontab.sh&
/usr/sbin/wd_rotate.sh
/usr/local/sbin/LogDataSize.sh
/usr/sbin/chk_wfs_download&
./usr/sbin/auto_fw -a -c&
./usr/sbin/auto_fw -c 1 &
./usr/sbin/logwdmsg -e &
/usr/sbin/wdappmgr_log_stats.py > /dev/null 2>&1 &


#23

The WD My Cloud PR4100 NAS (firmware version 2.30.165 and prior) have an old version of the OpenVPN secure tunneling daemon installed by default.

# /usr/sbin/openvpn
# /usr/local/modules/sbin/openvpn

Installed: openvpn-2.3.0.tar.gz (5/8/2013)
Current: openvpn-2.4.1.tar.gz (3/22/2017)
URL: https://openvpn.net
URL: http://swupdate.openvpn.org/community/releases/

# openvpn --help

OpenVPN 2.3.0 x86_64-intel-linux-gnu [SSL (OpenSSL)] [LZO] [EPOLL] [eurephia] [MH] [IPv6] built on Apr 28 2015

General Options:
--config file   : Read configuration options from file.
--help          : Show options.
--version       : Show copyright and version information.

Tunnel Options:
--local host    : Local host name or ip address. Implies --bind.
--remote host [port] : Remote host name or ip address.
--remote-random : If multiple --remote options specified, choose one randomly.
--remote-random-hostname : Add a random string to remote DNS name.
--mode m        : Major mode, m = 'p2p' (default, point-to-point) or 'server'.
--proto p       : Use protocol p for communicating with peer.
                  p = udp (default), tcp-server, or tcp-client
--proto-force p : only consider protocol p in list of connection profiles.
                  p = udp6, tcp6-server, or tcp6-client (ipv6)
--connect-retry n : For --proto tcp-client, number of seconds to wait
                    between connection retries (default=5).
--connect-timeout n : For --proto tcp-client, connection timeout (in seconds).
--connect-retry-max n : Maximum connection attempt retries, default infinite.
--http-proxy s p [up] [auth] : Connect to remote host
                  through an HTTP proxy at address s and port p.
                  If proxy authentication is required,
                  up is a file containing username/password on 2 lines, or
                  'stdin' to prompt from console.  Add auth='ntlm' if
                  the proxy requires NTLM authentication.
--http-proxy s p 'auto[-nct]' : Like the above directive, but automatically
                  determine auth method and query for username/password
                  if needed.  auto-nct disables weak proxy auth methods.
--http-proxy-retry     : Retry indefinitely on HTTP proxy errors.
--http-proxy-timeout n : Proxy timeout in seconds, default=5.
--http-proxy-option type [parm] : Set extended HTTP proxy options.
                                  Repeat to set multiple options.
                  VERSION version (default=1.0)
                  AGENT user-agent
--socks-proxy s [p] [up] : Connect to remote host through a Socks5 proxy at
                  address s and port p (default port = 1080).
                  If proxy authentication is required,
                  up is a file containing username/password on 2 lines, or
                  'stdin' to prompt for console.
--socks-proxy-retry : Retry indefinitely on Socks proxy errors.
--resolv-retry n: If hostname resolve fails for --remote, retry
                  resolve for n seconds before failing (disabled by default).
                  Set n="infinite" to retry indefinitely.
--float         : Allow remote to change its IP address/port, such as through
                  DHCP (this is the default if --remote is not used).
--ipchange cmd  : Run command cmd on remote ip address initial
                  setting or change -- execute as: cmd ip-address port#
--port port     : TCP/UDP port # for both local and remote.
--lport port    : TCP/UDP port # for local (default=1194). Implies --bind.
--rport port    : TCP/UDP port # for remote (default=1194).
--bind          : Bind to local address and port. (This is the default unless
                  --proto tcp-client or --http-proxy or --socks-proxy is used).
--nobind        : Do not bind to local address and port.
--dev tunX|tapX : tun/tap device (X can be omitted for dynamic device.
--dev-type dt   : Which device type are we using? (dt = tun or tap) Use
                  this option only if the tun/tap device used with --dev
                  does not begin with "tun" or "tap".
--dev-node node : Explicitly set the device node rather than using
                  /dev/net/tun, /dev/tun, /dev/tap, etc.
--lladdr hw     : Set the link layer address of the tap device.
--topology t    : Set --dev tun topology: 'net30', 'p2p', or 'subnet'.
--tun-ipv6      : Build tun link capable of forwarding IPv6 traffic.
--ifconfig l rn : TUN: configure device to use IP address l as a local
                  endpoint and rn as a remote endpoint.  l & rn should be
                  swapped on the other peer.  l & rn must be private
                  addresses outside of the subnets used by either peer.
                  TAP: configure device to use IP address l as a local
                  endpoint and rn as a subnet mask.
--ifconfig-ipv6 l r : configure device to use IPv6 address l as local
                      endpoint (as a /64) and r as remote endpoint
--ifconfig-noexec : Don't actually execute ifconfig/netsh command, instead
                    pass --ifconfig parms by environment to scripts.
--ifconfig-nowarn : Don't warn if the --ifconfig option on this side of the
                    connection doesn't match the remote side.
--route network [netmask] [gateway] [metric] :
                  Add route to routing table after connection
                  is established.  Multiple routes can be specified.
                  netmask default: 255.255.255.255
                  gateway default: taken from --route-gateway or --ifconfig
                  Specify default by leaving blank or setting to "nil".
--route-ipv6 network/bits [gateway] [metric] :
                  Add IPv6 route to routing table after connection
                  is established.  Multiple routes can be specified.
                  gateway default: taken from --route-ipv6-gateway or --ifconfig
--max-routes n :  Specify the maximum number of routes that may be defined
                  or pulled from a server.
--route-gateway gw|'dhcp' : Specify a default gateway for use with --route.
--route-metric m : Specify a default metric for use with --route.
--route-delay n [w] : Delay n seconds after connection initiation before
                  adding routes (may be 0).  If not specified, routes will
                  be added immediately after tun/tap open.  On Windows, wait
                  up to w seconds for TUN/TAP adapter to come up.
--route-up cmd  : Run command cmd after routes are added.
--route-pre-down cmd : Run command cmd before routes are removed.
--route-noexec  : Don't add routes automatically.  Instead pass routes to
                  --route-up script using environmental variables.
--route-nopull  : When used with --client or --pull, accept options pushed
                  by server EXCEPT for routes and dhcp options.
--allow-pull-fqdn : Allow client to pull DNS names from server for
                    --ifconfig, --route, and --route-gateway.
--redirect-gateway [flags]: Automatically execute routing
                  commands to redirect all outgoing IP traffic through the
                  VPN.  Add 'local' flag if both OpenVPN servers are directly
                  connected via a common subnet, such as with WiFi.
                  Add 'def1' flag to set default route using using 0.0.0.0/1
                  and 128.0.0.0/1 rather than 0.0.0.0/0.  Add 'bypass-dhcp'
                  flag to add a direct route to DHCP server, bypassing tunnel.
                  Add 'bypass-dns' flag to similarly bypass tunnel for DNS.
--redirect-private [flags]: Like --redirect-gateway, but omit actually changing
                  the default gateway.  Useful when pushing private subnets.
--client-nat snat|dnat network netmask alias : on client add 1-to-1 NAT rule.
--push-peer-info : (client only) push client info to server.
--setenv name value : Set a custom environmental variable to pass to script.
--setenv FORWARD_COMPATIBLE 1 : Relax config file syntax checking to allow
                  directives for future OpenVPN versions to be ignored.
--script-security level: Where level can be:
                  0 -- strictly no calling of external programs
                  1 -- (default) only call built-ins such as ifconfig
                  2 -- allow calling of built-ins and scripts
                  3 -- allow password to be passed to scripts via env
--shaper n      : Restrict output to peer to n bytes per second.
--keepalive n m : Helper option for setting timeouts in server mode.  Send
                  ping once every n seconds, restart if ping not received
                  for m seconds.
--inactive n [bytes] : Exit after n seconds of activity on tun/tap device
                  produces a combined in/out byte count < bytes.
--ping-exit n   : Exit if n seconds pass without reception of remote ping.
--ping-restart n: Restart if n seconds pass without reception of remote ping.
--ping-timer-rem: Run the --ping-exit/--ping-restart timer only if we have a
                  remote address.
--ping n        : Ping remote once every n seconds over TCP/UDP port.
--multihome     : Configure a multi-homed UDP server.
--fast-io       : (experimental) Optimize TUN/TAP/UDP writes.
--remap-usr1 s  : On SIGUSR1 signals, remap signal (s='SIGHUP' or 'SIGTERM').
--persist-tun   : Keep tun/tap device open across SIGUSR1 or --ping-restart.
--persist-remote-ip : Keep remote IP address across SIGUSR1 or --ping-restart.
--persist-local-ip  : Keep local IP address across SIGUSR1 or --ping-restart.
--persist-key   : Don't re-read key files across SIGUSR1 or --ping-restart.
--passtos       : TOS passthrough (applies to IPv4 only).
--tun-mtu n     : Take the tun/tap device MTU to be n and derive the
                  TCP/UDP MTU from it (default=1500).
--tun-mtu-extra n : Assume that tun/tap device might return as many
                  as n bytes more than the tun-mtu size on read
                  (default TUN=0 TAP=32).
--link-mtu n    : Take the TCP/UDP device MTU to be n and derive the tun MTU
                  from it.
--mtu-disc type : Should we do Path MTU discovery on TCP/UDP channel?
                  'no'    -- Never send DF (Don't Fragment) frames
                  'maybe' -- Use per-route hints
                  'yes'   -- Always DF (Don't Fragment)
--mtu-test      : Empirically measure and report MTU.
--fragment max  : Enable internal datagram fragmentation so that no UDP
                  datagrams are sent which are larger than max bytes.
                  Adds 4 bytes of overhead per datagram.
--mssfix [n]    : Set upper bound on TCP MSS, default = tun-mtu size
                  or --fragment max value, whichever is lower.
--sndbuf size   : Set the TCP/UDP send buffer size.
--rcvbuf size   : Set the TCP/UDP receive buffer size.
--mark value    : Mark encrypted packets being sent with value. The mark value
                  can be matched in policy routing and packetfilter rules.
--txqueuelen n  : Set the tun/tap TX queue length to n (Linux only).
--memstats file : Write live usage stats to memory mapped binary file.
--mlock         : Disable Paging -- ensures key material and tunnel
                  data will never be written to disk.
--up cmd        : Run command cmd after successful tun device open.
                  Execute as: cmd tun/tap-dev tun-mtu link-mtu \
                              ifconfig-local-ip ifconfig-remote-ip
                  (pre --user or --group UID/GID change)
--up-delay      : Delay tun/tap open and possible --up script execution
                  until after TCP/UDP connection establishment with peer.
--down cmd      : Run command cmd after tun device close.
                  (post --user/--group UID/GID change and/or --chroot)
                  (command parameters are same as --up option)
--down-pre      : Run --down command before TUN/TAP close.
--up-restart    : Run up/down commands for all restarts including those
                  caused by --ping-restart or SIGUSR1
--user user     : Set UID to user after initialization.
--group group   : Set GID to group after initialization.
--chroot dir    : Chroot to this directory after initialization.
--cd dir        : Change to this directory before initialization.
--daemon [name] : Become a daemon after initialization.
                  The optional 'name' parameter will be passed
                  as the program name to the system logger.
--syslog [name] : Output to syslog, but do not become a daemon.
                  See --daemon above for a description of the 'name' parm.
--inetd [name] ['wait'|'nowait'] : Run as an inetd or xinetd server.
                  See --daemon above for a description of the 'name' parm.
--log file      : Output log to file which is created/truncated on open.
--log-append file : Append log to file, or create file if nonexistent.
--suppress-timestamps : Don't log timestamps to stdout/stderr.
--writepid file : Write main process ID to file.
--nice n        : Change process priority (>0 = lower, <0 = higher).
--echo [parms ...] : Echo parameters to log output.
--verb n        : Set output verbosity to n (default=1):
                  (Level 3 is recommended if you want a good summary
                  of what's happening without being swamped by output).
                : 0 -- no output except fatal errors
                : 1 -- startup info + connection initiated messages +
                       non-fatal encryption & net errors
                : 2,3 -- show TLS negotiations & route info
                : 4 -- show parameters
                : 5 -- show 'RrWw' chars on console for each packet sent
                       and received from TCP/UDP (caps) or tun/tap (lc)
                : 6 to 11 -- debug messages of increasing verbosity
--mute n        : Log at most n consecutive messages in the same category.
--status file n : Write operational status to file every n seconds.
--status-version [n] : Choose the status file format version number.
                  Currently, n can be 1, 2, or 3 (default=1).
--disable-occ   : Disable options consistency check between peers.
--gremlin mask  : Special stress testing mode (for debugging only).
--comp-lzo      : Use fast LZO compression -- may add up to 1 byte per
                  packet for uncompressible data.
--comp-noadapt  : Don't use adaptive compression when --comp-lzo
                  is specified.
--management ip port [pass] : Enable a TCP server on ip:port to handle
                  management functions.  pass is a password file
                  or 'stdin' to prompt from console.
                  To listen on a unix domain socket, specific the pathname
                  in place of ip and use 'unix' as the port number.
--management-client : Management interface will connect as a TCP client to
                      ip/port rather than listen as a TCP server.
--management-query-passwords : Query management channel for private key
                  and auth-user-pass passwords.
--management-query-proxy : Query management channel for proxy information.
--management-query-remote : Query management channel for --remote directive.
--management-hold : Start OpenVPN in a hibernating state, until a client
                    of the management interface explicitly starts it.
--management-signal : Issue SIGUSR1 when management disconnect event occurs.
--management-forget-disconnect : Forget passwords when management disconnect
                                 event occurs.
--management-up-down : Report tunnel up/down events to management interface.
--management-log-cache n : Cache n lines of log file history for usage
                  by the management channel.
--management-client-user u  : When management interface is a unix socket, only
                              allow connections from user u.
--management-client-group g : When management interface is a unix socket, only
                              allow connections from group g.
--management-client-auth : gives management interface client the responsibility
                           to authenticate clients after their client certificate
                              has been verified.
--management-client-pf : management interface clients must specify a packet
                         filter file for each connecting client.
--plugin m [str]: Load plug-in module m passing str as an argument
                  to its initialization function.

Multi-Client Server options (when --mode server is used):
--server network netmask : Helper option to easily configure server mode.
--server-ipv6 network/bits : Configure IPv6 server mode.
--server-bridge [IP netmask pool-start-IP pool-end-IP] : Helper option to
                    easily configure ethernet bridging server mode.
--push "option" : Push a config file option back to the peer for remote
                  execution.  Peer must specify --pull in its config file.
--push-reset    : Don't inherit global push list for specific
                  client instance.
--ifconfig-pool start-IP end-IP [netmask] : Set aside a pool of subnets
                  to be dynamically allocated to connecting clients.
--ifconfig-pool-linear : Use individual addresses rather than /30 subnets
                  in tun mode.  Not compatible with Windows clients.
--ifconfig-pool-persist file [seconds] : Persist/unpersist ifconfig-pool
                  data to file, at seconds intervals (default=600).
                  If seconds=0, file will be treated as read-only.
--ifconfig-ipv6-pool base-IP/bits : set aside an IPv6 network block
                  to be dynamically allocated to connecting clients.
--ifconfig-push local remote-netmask : Push an ifconfig option to remote,
                  overrides --ifconfig-pool dynamic allocation.
                  Only valid in a client-specific config file.
--ifconfig-ipv6-push local/bits remote : Push an ifconfig-ipv6 option to
                  remote, overrides --ifconfig-ipv6-pool allocation.
                  Only valid in a client-specific config file.
--iroute network [netmask] : Route subnet to client.
--iroute-ipv6 network/bits : Route IPv6 subnet to client.
                  Sets up internal routes only.
                  Only valid in a client-specific config file.
--disable       : Client is disabled.
                  Only valid in a client-specific config file.
--client-cert-not-required : Don't require client certificate, client
                  will authenticate using username/password.
--username-as-common-name  : For auth-user-pass authentication, use
                  the authenticated username as the common name,
                  rather than the common name from the client cert.
--auth-user-pass-verify cmd method: Query client for username/password and
                  run command cmd to verify.  If method='via-env', pass
                  user/pass via environment, if method='via-file', pass
                  user/pass via temporary file.
--opt-verify    : Clients that connect with options that are incompatible
                  with those of the server will be disconnected.
--auth-user-pass-optional : Allow connections by clients that don't
                  specify a username/password.
--no-name-remapping : Allow Common Name and X509 Subject to include
                      any printable character.
--client-to-client : Internally route client-to-client traffic.
--duplicate-cn  : Allow multiple clients with the same common name to
                  concurrently connect.
--client-connect cmd : Run command cmd on client connection.
--client-disconnect cmd : Run command cmd on client disconnection.
--client-config-dir dir : Directory for custom client config files.
--ccd-exclusive : Refuse connection unless custom client config is found.
--tmp-dir dir   : Temporary directory, used for --client-connect return file and plugin communication.
--hash-size r v : Set the size of the real address hash table to r and the
                  virtual address table to v.
--bcast-buffers n : Allocate n broadcast buffers.
--tcp-queue-limit n : Maximum number of queued TCP output packets.
--tcp-nodelay   : Macro that sets TCP_NODELAY socket flag on the server
                  as well as pushes it to connecting clients.
--learn-address cmd : Run command cmd to validate client virtual addresses.
--connect-freq n s : Allow a maximum of n new connections per s seconds.
--max-clients n : Allow a maximum of n simultaneously connected clients.
--max-routes-per-client n : Allow a maximum of n internal routes per client.
--stale-routes-check n [t] : Remove routes with a last activity timestamp
                             older than n seconds. Run this check every t
                             seconds (defaults to n).
--port-share host port [dir] : When run in TCP mode, proxy incoming HTTPS
                  sessions to a web server at host:port.  dir specifies an
                  optional directory to write origin IP:port data.

Client options (when connecting to a multi-client server):
--client         : Helper option to easily configure client mode.
--auth-user-pass [up] : Authenticate with server using username/password.
                  up is a file containing username/password on 2 lines,
                  or omit to prompt from console.
--pull           : Accept certain config file options from the peer as if they
                  were part of the local config file.  Must be specified
                  when connecting to a '--mode server' remote host.
--auth-retry t  : How to handle auth failures.  Set t to
                  none (default), interact, or nointeract.
--static-challenge t e : Enable static challenge/response protocol using
                  challenge text t, with e indicating echo flag (0|1)
--server-poll-timeout n : when polling possible remote servers to connect to
                  in a round-robin fashion, spend no more than n seconds
                  waiting for a response before trying the next server.
--explicit-exit-notify [n] : On exit/restart, send exit signal to
                  server/remote. n = # of retries, default=1.

Data Channel Encryption Options (must be compatible between peers):
(These options are meaningful for both Static Key & TLS-mode)
--secret f [d]  : Enable Static Key encryption mode (non-TLS).
                  Use shared secret file f, generate with --genkey.
                  The optional d parameter controls key directionality.
                  If d is specified, use separate keys for each
                  direction, set d=0 on one side of the connection,
                  and d=1 on the other side.
--auth alg      : Authenticate packets with HMAC using message
                  digest algorithm alg (default=SHA1).
                  (usually adds 16 or 20 bytes per packet)
                  Set alg=none to disable authentication.
--cipher alg    : Encrypt packets with cipher algorithm alg
                  (default=BF-CBC).
                  Set alg=none to disable encryption.
--prng alg [nsl] : For PRNG, use digest algorithm alg, and
                   nonce_secret_len=nsl.  Set alg=none to disable PRNG.
--keysize n     : Size of cipher key in bits (optional).
                  If unspecified, defaults to cipher-specific default.
--engine [name] : Enable OpenSSL hardware crypto engine functionality.
--no-replay     : Disable replay protection.
--mute-replay-warnings : Silence the output of replay warnings to log file.
--replay-window n [t]  : Use a replay protection sliding window of size n
                         and a time window of t seconds.
                         Default n=64 t=15
--no-iv         : Disable cipher IV -- only allowed with CBC mode ciphers.
--replay-persist file : Persist replay-protection state across sessions
                  using file.
--test-crypto   : Run a self-test of crypto features enabled.
                  For debugging only.

TLS Key Negotiation Options:
(These options are meaningful only for TLS-mode)
--tls-server    : Enable TLS and assume server role during TLS handshake.
--tls-client    : Enable TLS and assume client role during TLS handshake.
--key-method m  : Data channel key exchange method.  m should be a method
                  number, such as 1 (default), 2, etc.
--ca file       : Certificate authority file in .pem format containing
                  root certificate.
--capath dir    : A directory of trusted certificates (CAs and CRLs).
--dh file       : File containing Diffie Hellman parameters
                  in .pem format (for --tls-server only).
                  Use "openssl dhparam -out dh1024.pem 1024" to generate.
--cert file     : Local certificate in .pem format -- must be signed
                  by a Certificate Authority in --ca file.
--extra-certs file : one or more PEM certs that complete the cert chain.
--key file      : Local private key in .pem format.
--pkcs12 file   : PKCS#12 file containing local private key, local certificate
                  and optionally the root CA certificate.
--verify-hash   : Specify SHA1 fingerprint for level-1 cert.
--tls-cipher l  : A list l of allowable TLS ciphers separated by : (optional).
                : Use --show-tls to see a list of supported TLS ciphers.
--tls-timeout n : Packet retransmit timeout on TLS control channel
                  if no ACK from remote within n seconds (default=2).
--reneg-bytes n : Renegotiate data chan. key after n bytes sent and recvd.
--reneg-pkts n  : Renegotiate data chan. key after n packets sent and recvd.
--reneg-sec n   : Renegotiate data chan. key after n seconds (default=3600).
--hand-window n : Data channel key exchange must finalize within n seconds
                  of handshake initiation by any peer (default=60).
--tran-window n : Transition window -- old key can live this many seconds
                  after new key renegotiation begins (default=3600).
--single-session: Allow only one session (reset state on restart).
--tls-exit      : Exit on TLS negotiation failure.
--tls-auth f [d]: Add an additional layer of authentication on top of the TLS
                  control channel to protect against DoS attacks.
                  f (required) is a shared-secret passphrase file.
                  The optional d parameter controls key directionality,
                  see --secret option for more info.
--askpass [file]: Get PEM password from controlling tty before we daemonize.
--auth-nocache  : Don't cache --askpass or --auth-user-pass passwords.
--crl-verify crl ['dir']: Check peer certificate against a CRL.
--tls-verify cmd: Run command cmd to verify the X509 name of a
                  pending TLS connection that has otherwise passed all other
                  tests of certification.  cmd should return 0 to allow
                  TLS handshake to proceed, or 1 to fail.  (cmd is
                  executed as 'cmd certificate_depth subject')
--tls-export-cert [directory] : Get peer cert in PEM format and store it
                  in an openvpn temporary file in [directory]. Peer cert is
                  stored before tls-verify script execution and deleted after.
--tls-remote x509name: Accept connections only from a host with X509 name
                  x509name. The remote host must also pass all other tests
                  of verification.
--ns-cert-type t: Require that peer certificate was signed with an explicit
                  nsCertType designation t = 'client' | 'server'.
--x509-track x  : Save peer X509 attribute x in environment for use by
                  plugins and management interface.
--remote-cert-ku v ... : Require that the peer certificate was signed with
                  explicit key usage, you can specify more than one value.
                  value should be given in hex format.
--remote-cert-eku oid : Require that the peer certificate was signed with
                  explicit extended key usage. Extended key usage can be encoded
                  as an object identifier or OpenSSL string representation.
--remote-cert-tls t: Require that peer certificate was signed with explicit
                  key usage and extended key usage based on RFC3280 TLS rules.
                  t = 'client' | 'server'.

SSL Library information:
--show-ciphers  : Show cipher algorithms to use with --cipher option.
--show-digests  : Show message digest algorithms to use with --auth option.
--show-engines  : Show hardware crypto accelerator engines (if available).
--show-tls      : Show all TLS ciphers (TLS used only as a control channel).

Generate a random key (only for non-TLS static key encryption mode):
--genkey        : Generate a random key to be used as a shared secret,
                  for use with the --secret option.
--secret file   : Write key to file.

Tun/tap config mode (available with linux 2.4+):
--mktun         : Create a persistent tunnel.
--rmtun         : Remove a persistent tunnel.
--dev tunX|tapX : tun/tap device
--dev-type dt   : Device type.  See tunnel options above for details.
--user user     : User to set privilege to.
--group group   : Group to set privilege to.

General Standalone Options:
--show-gateway : Show info about default gateway.

#24

Bad news… I managed to brick it, and I wasn’t even trying.

I recently upgraded the firmware to version 2.30.165, but since the upgrade the NAS didn’t seem to behave normally at times, so I decided to reflash the same factory firmware version 2.30.165 (using the dashboard) to see if that straightened things out. As luck would have it, the power failed at precisely the wrong time, which resulted in a partial or corrupted firmware flash. After the power came back on, I turned on the NAS, thinking the rescue firmware would save the day, but it was nowhere to be found. Yep, it’s bricked, but all hope is not lost.

Despite the nature of this thread, I’ve been running stock firmware all along, being extremely careful when using SSH to analyze the actual hardware, etc. A virtual environment was used for testing compiled code because I’m not stupid enough to upload custom/experimental firmware until it’s been extensively tested.

Regardless, it’s safe to assume that my “warranty” is probably void, and despite the possibility that I’m now the proud owner of a $500 “My Brick” NAS box, I consider this to be a valuable learning experience, and WD has actually done something quite remarkable. They have awakened a sleeping desire to resume my past hobby of hardware hacking.

At this point, the only way to fix this is by interfacing directly with the hardware. That said, I removed the NAS cover (for the first time) and believe I’ve located the UART port and identified it’s pinout (GND, TX, RX, VCC). If I’m correct, which can only be confirmed after my new “tools” arrive, the internal UART port is fitted with a standard JST 4 pin connector. These connectors were commonly used on the audio interface of older CD ROM drives, so I had a few in my junk box from past computer projects.

All of my “tools” are designed to interface with older RS232 serial hardware, so I’ve ordered a Saleae Logic 4 - USB Logic Analyzer, a SparkFun USB to Serial Breakout Board - FT232RL, and assorted test leads/cables for use with future “projects”. A good multimeter is also a requirement, but being a former electronics technician, I’ve got that covered. WARNING: Never try to interface with hardware unless you have the proper experience and tools for the job. One wrong move and the hardware can be fried… permanently.

One last thing… I regret sending back the QNAP TS451+ NAS (due to hidden files) in favor of buying the WD PR4100 NAS (which also has hidden files), so I’ve ordered another QNAP (TS-453A) to use as my primary NAS device. The QNAP also has an integrated display port, so one can see the entire boot process (including BIOS) if needed. Seriously, if this situation had occurred with a QNAP, they have several recovery procedures which would have had me back up an running within minutes. Conversely, recovering the WD NAS from a failed firmware flash is a nightmare. Hint, live CDs and bootable USB sticks work wonders for fixing things like this.


#25

Sorry to hear about the “brickage” @dswv42

I was a first timer buying a NAS and extensive reports from specialized media convinced me WD EX4 was a good choice. I regret it know, maybe not as much as you, but I wouldn’t go for WD again as well. SO many bugs, poor performance, bad support, it is not worth it.

As far as fiddling with the hardware goes, good luck and keep posting about the progress!


#26

Likewise, I thought this NAS got relatively good reviews. In hindsight, I now believe 90% of the reviews I saw were sponsored in some way. In time, I intend to write a review of my own, and it will reflect a very accurate picture of my experiences… which have not been good ones.

Don’t worry, I will post about the outcome, even if it’s bad, if for no other reason than to warn others. In any case, it will likely take some time because interfacing directly with the hardware is extremely dangerous, and one wrong command can wipe out everything in the NAND flash memory, even the bootloader. As you can imagine, prudence is warranted.

I should have some idea of what’s going on by tomorrow evening, after my “tools” arrive. However, getting console access via the UART serial port is the easy part. I won’t know what course of action is required, or if recovery is even possible, until I see the boot messages. Undoubtedly, the boot process will fail at some point, but the question is… where? Is it the bootloader, the kernel, the initramfs, or something else? My money is on the kernel, but only time can tell.

Currently, I estimate the odds of success to be around 80%, maybe a little higher.


#27

FedEx is due to deliver my UART “tools” any time now, but the suspense is killing me. Having direct access to the bootloader is the only way I will know what is wrong, and how to proceed. In addition, I suspect that U-boot is the primary bootloader, which then chainloads GRUB as a secondary bootloader, but again, I won’t know for certain until the moment of truth arrives.

Regardless, my plan is to get serial console access, then save a copy of the environment variables and (U-Boot ?) command list so I can examine them. No matter how much I may want to fix my NAS, this is one time where getting in a hurry can make things exponentially worse. Assuming that the primary bootloader is ok (98% chance), one wrong command can wipe it out, which would then require directly reflashing the chip itself. I know how, but doing so can potentially damage the chip and/or PCB, so it’s only something I’d consider as an absolute last resort.

Oh great, I hear thunder… guess I’ll have to wait, “tools” or not.


#28

It’s alive! The PR4100 is alive and kicking… no thanks to WD. And Support said it couldn’t be done. HA!


#29

Oh, and I almost forgot…

The rescue firmware does not seem to work properly, at least not if the power fails during a firmware upload. It seems to rely on certain files stored in partitions outside of the rescue_firmware partition, and if these files are corrupt… you are out of luck, unless you have the skills to make the magic happen.

BTW: Part of the process I used to resurrect my PR4100 NAS from the dead involved using an attached USB stick, exactly as I suggested in a “product idea”.


#30

My unfortunate “bricking” experience may have been a blessing in disguise. Not only has it given me direct access to information (via the serial UART console) not available by any other means, it has also sparked a few new ideas.

After successfully compiling existing and current versions of the Linux Kernel, I’ve been itching to test them on the actual hardware, but haven’t done so for fear of the consequences. Various compiled kernels were successfully tested in a virtual environment, but this is no guarantee that they will run on the actual hardware. Despite my precautions, the NAS was temporarily bricked due to circumstances “partially” beyond my control. I say partially because I should have been using a UPS while performing any kind of firmware update.

Regardless, my bricking experience has revealed the following:

  1. The WD rescue firmware doesn’t seem to work properly.
  2. There is no known USB recovery procedure.
  3. GRUB appears to be the primary bootloader.

Armed with this new-found information, I’ve come to believe that the bootloader may be tweaked to offer a relatively foolproof USB recovery procedure, with the added benefit of allowing firmware customizations to be tested on the actual NAS hardware with virtually no risk of bricking.

Regardless, I plan to thoroughly test this new idea on my PC before making any changes to the NAS, but first I must compile a “special” version of the Linux kernel which will run on my PC hardware. As a matter of fact, I have one compiling now, but it’s a very slow process.

If successful, this will finally allow me to begin unleashing the true potential of this NAS.


#31

Since it looks like I will soon be able to test updated kernel builds on the actual hardware with minimal risk, I’ve resumed efforts towards being ready when the time comes.

In fact, I’ve largely automated the process of incorporating Linux version 4.9.19 and Netatop version 1.0 into a custom firmware build. Only one insignificant warning message "your version of binutils lacks AVX512 support" remains during the kernel compilation phase of the build process. In time, this warning will be resolved, just like the rest.

With certain tweaks, this process could be easily adapted to any My Cloud model.


#32

Getting the kernel to build properly was bad, but building packages is exponentially worse. No two packages are the same, and the requirements for the build environment are not included in the firmware build instructions.

Making matters worse is the fact that #!/bin/sh is frequently used, but Ubuntu #!/bin/sh defaults to dash not bash, requiring certain scripts to be changed to #!/bin/bash so they will “hopefully” work properly. Thankfully, the sed command makes short work of changing #!/bin/sh to #!/bin/bash on the fly, but that doesn’t compensate for broken dependencies and paths/files which don’t exist.

Oh, and I’m beginning to suspect that the merge program may not produce proper firmware bin files, or at least the files it produces seem to have some significant structural differences when compared with factory firmware bin files. I can’t be certain because the merge program is a compiled binary file, with no source code available.


#33

Console access via the internal UART (Universal Asynchronous Receiver / Transmitter) port is provided and controlled by the BIOS, which is only accessible via the UART port. This only applies to the WD PR4100 and PR2100 NAS devices. Other models likely have a different system configuration.

WARNING: BIOS settings should NEVER be changed.


#34

I discovered how to boot the NAS from a USB stick, and no changes to the NAS are required. This means that it’s now possible to load rescue firmware from USB, safely test custom kernel builds, and much more.


#35

Critical sections of the source code are stored in executable binary files.

For example, the following code snippet from a system initialization script named rc.sh loads a SquashFS file named image.cfs, which contains the primary root filesystem. Note how the script calls a binary program named chk_image, but the programmers left just enough information to logically reconstruct the functionality of the chk_image binary program. That, and binary files can be reverse-engineered.

# 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

#36

I’ve successfully tested rescue firmware copied from the /dev/mmcblk0p5 (wdnas_rescue_fw) NAND flash partition to a USB stick. It was booted using the stock WD GRUB bootloader, which was also copied to the USB stick with a modified grub.cfg file.

Note that the GRUB bootloader menu can only be viewed via a UART serial console. However, a properly configured grub.cfg file allows the process to work automatically, with no user interaction required.

BTW: My firmware is not corrupted, that’s just what the rescue firmware is programmed to say after it loads. When the test was complete, I simply shut down the NAS by briefly pressing the power button, before removing the USB stick and pressing the power button again to boot the internal stock firmware.


USB Rescue Firmware Procedure
#37

The following paths contain the same files, but I’m not entirely certain why. Then again, I fail to see the logic behind most of the stuff I’ve found.

/etc/init.d/
/usr/local/modules/etc/init.d/

-rwxrwxr-x    1 root     root          1782 Mar 21 03:54 AddVolumes.py
-rwxrwxr-x    1 root     root            94 Mar 21 03:54 S14hwinit
-rwxrwxr-x    1 root     root          2018 Mar 21 03:54 S14wdhws
-rwxrwxr-x    1 root     root          2018 Mar 21 03:54 S15wdlcd
-rwxrwxr-x    1 root     root          2035 Mar 21 03:54 S20wdpms
-rwxrwxr-x    1 root     root          2398 Mar 21 03:54 S20wdtmsd
-rwxr-xr-x    1 root     root          3530 Aug 18  2016 atop
-rwxr-xr-x    1 root     root           777 Aug 18  2015 commgrd
-rwxr-xr-x    1 root     root          5554 Aug 18  2015 onbrdnetloccommd
-rwxr-xr-x    1 root     root          1052 Nov 13  2015 restsdk-serverd
-rwxrwxr-x    1 root     root          1933 Mar 21 04:01 wdappmgrd
-rwxr-xr-x    1 root     root          2422 Jan 24 04:45 wdmcserverd
-rwxr-xr-x    1 root     root          2086 Aug 18  2015 wdnotifierd
-rwxr-xr-x    1 root     root          1865 Jan 24 04:45 wdphotodbmergerd

The files are all scripts which start assorted daemons, most of which appear to be privacy-invading, resource-hogging junk.


#38

The /etc/init.d/atop script uses atopsar to generate a /var/log/atop/atop_current analytics report log file, but it seems to be encrypted or obfusticated.

The atopsar -A command can be used to view log files, but no results are found.

/var/log/atop/atop_20170427 - open raw file: No such file or directory

Lets give atopsar something to chew on and see exactly what kind of information is being logged.

cp -f /var/log/atop/atop_current /var/log/atop/atop_20170427

The atopsar -A command will now display the log file in the terminal window, but the log is quite large. It’s best to pipe the output to a text file for a better viewing experience using a real text editor.

atopsar -A > /shares/Public/atop_log.txt

Time to take out the garbage. It’s not permanent, but this can be changed later.

/etc/init.d/atop stop
rm /var/log/atop/atop_current

Oh, and lets not forget it’s buddies.

/etc/init.d/wdnotifierd stop
/etc/init.d/wdmcserverd stop
/etc/init.d/wdphotodbmergerd stop
/etc/init.d/restsdk-serverd stop
/etc/init.d/onbrdnetloccommd stop


#39

On second thought, the /etc/init.d/wdnotifierd script may actually perform a useful function. Anything starting with the letters “wd” automatically makes me want to nuke it from existence. It’s become a force of habit because “wd” stuff tends to do things which are not in my best interest.

The /etc/init.d/wdnotifierd script calls the /usr/local/bin/wdnotifier process, which appears to send notifications to the dashboard and trigger certain LED / LCD display functionionality.

As a quick test, I gave the NAS something to complain about by inserting a USB stick, then removing it without stopping it first. As expected, the dashboard warned me that the world was coming to an end because I yanked the USB stick without stopping it first. Lets see what happens if I tell the /etc/init.d/wdnotifierd script to stop the /usr/local/bin/wdnotifier process.

/etc/init.d/wdnotifierd stop

Oops, no notifications. Better tell the /etc/init.d/wdnotifierd script to start the /usr/local/bin/wdnotifier process back up again.

/etc/init.d/wdnotifierd start

That’s better, now the dashboard can resume its excessive complaining.

BTW: I like living dangerously, so I performed the same test by yanking a hard drive. Curiously, the dashboard still received the standard notification messages, even with the /usr/local/bin/wdnotifier process stopped.


#40

My kill list is growing, and I think I’ve finally tracked down the process responsible for trying to phone home to the mothership. And the winner is…

# /usr/sbin/sysinfod

sysinfod: full update begin…
sysinfod: disk connected: previous=0xffffffff, now=0x7
–2017-04-27 16:05:17-- http://download.wdc.com/nas/BNFA_HDD_Blacklist.xml
Resolving download.wdc.com… failed: Name or service not known.
wget: unable to resolve host address ‘download.wdc.com
/tmp/hdd_white_list.xml:1: parser error : AttValue: " or ’ expected

Interestingly, the sysinfod process appears to be a process named infod in disguise.

# /usr/sbin/sysinfod -h

Usage: infod [–time POLLING_TIME] #default polling time is 10 seconds

What’s this process really doing the background? What’s it polling every 10 seconds and is it really necessary to do it so often?

Here’s the result returned from the BNFA_HDD_Blacklist.xml file that the sysinfod process tries to retrieve.

<?xml version="1.0" encoding="UTF-8"?>
<Error>
	<Code>NoSuchKey</Code>
	<Message>The specified key does not exist.</Message>
	<Key>nas/BNFA_HDD_Blacklist.xml</Key>
	<RequestId>315605FA88D44013</RequestId>
	<HostId>uMM26xNFCyDLngnEtWSlSqkZGQ9QI10lOtHtBR+qWBGxDYjdcnJlq4zRRdxwLKKoacrHOfndKII=</HostId>
</Error>

Either the mothership doesn’t want to give up its secrets, or nobody’s home. But could there be another reason for requesting a file that doesn’t exist? Merely making a request for a file transmits certain information to the server, even if the file doesn’t exist, so it could also be used as a form of tracking. Think of it as a beacon saying “here I am”.

It’s possible that the sysinfod process may also be responsible for critical system functions, so I’m going to leave it alone for now, but definitely plan to watch it closely. WD seems to “bundle” things in compiled binary files, likely as an attempt to prevent certain processes from being removed, but there are ways around this tactic.


#41

Ok, this one actually made me laugh.

# /usr/sbin/log_conf -h

/usr/sbin/log_conf: invalid option -- 'h'
usage:
   /usr/sbin/log_conf --default
   /usr/sbin/log_conf -h

The /usr/sbin/log_conf program includes -h among the list of valid options, but -h isn’t a valid option. Seriously, nobody could make this stuff up.