I’ve had a Stanton SCS.4DJ unit for a few months now, and thorougly enjoy using it. However, there are a community of users who want to get their hands on the OS/application so we can help to improve it.

What follows is a collection of notes from my initial reserach into the device. Much of it isn’t complete, I need to spend more time doing in-depth analysis but that’s a hard task fitting it within my day job. Hopefully this is a good enough start that it picks up some interest from the community (or maybe even Stanton/Gibson themselves).

Lets start with QuickGrid:

QuickGrid is a PC based analysis program which analyses BPMs and generates the waveform display that is used on the unit. The SCS.4DJ can do it itself, but doing it on a PC is much faster. Lets see what it’s doing:

Analysis

Well, it’s a Java App with a couple of dependencies, namely djanalyze.exe. Running it manually gives:

C:\Program Files (x86)\Stanton>djanalyze.exe --help
usage: djanalyze audioFileName rootFolder songId [userBPM] [userBPMMode]
						or
			djanalyze --version
						or
			djanalyze --supports-hash
						or
			djanalyze --error-code
						or
			djanalyze --help

example: djanalyze "e:\audio.mp3" "e:" "FE66E7B1E7D1C4B8AAA2FD5BB8B71A39"

So the app must be generating the hash (which we assume to be an MD5 because it’s 32 characters long, though it’s not a plain md5 so it must be salted somehow It IS an md5 hash of the file!), analysing the mp3, then storing the results. So how does it store this data?

On-USB-Device filesystem:

• SCS.4DJ_Database
  • analysis
    • {two-chars}/{hash}.sar
    • {two-chars}/{hash}.sek
    • {two-chars}/{hash}.wfv
  • db_reserved_space
  • Stanton_DJ_DB.db

The most interesting file is of course, Stanton_DJ_DB.db. This is an SQLite database, and there’s a nifty extension for Firefox called ‘SQLite Manager‘. Opening this file gives us 5 database tables:

• Device
• Playlists
• SongAnalysis
• Songs
• Vieos

So if you ever wanted to find all the 87 BPM tracks and double them to 174, all it takes is a single SQL query (maybe someone will write a utility that can quickly do this…)

And now on the SCS.4DJ itself:

Normally to work this out we’d have to take apart the unit, but not wanting to void my warranty, we’re stuck with the hard way…. or maybe not so hard: Stanton have given us a firmware update file we can take apart!

Extracting the zip file at http://www.stantondj.com/pdf/products/controllers/scs4dj/SCS4%202_1-update-and-changelog.zip gives us

• SC-IX Update Instructions_Changelog.pdf
• SCS.4DJ_OSv2.1_2011-12-02.update

Looking at the .update file header, we can see that it’s a .tar.gz file, so extracting all of the contents of that gives us something that looks like:

• ColdfireUpdateAction
  • MR1.0.1_SCS4DJ_CF4.11_7_15.cfupdate
  • update-coldfire (ELF file)
• DeleteSelfAction
• DjappUpdateAction
  • home/jars/workspace
    • app
    • djanalyze
    • midi_controller
• KernelUpdateAction
  • zImage
• PrerequisiteCheckAction
• RootfsUpdateAction
  • boot …
  • etc …
  • lib …
  • root …
  • tmp …
  • usr …
• Scripts
  • 01-PrerequisiteCheckAction.sh
  • 02-RootfsUpdateAction.sh
  • 03-KernelUpdateAction.sh
  • 04-DjappUpdateAction.sh
  • 05-ColdfireUpdateAction.sh
  • 06-DeleteSelfAction.sh
• UpdateHelpers
  • fbsplash.ini
  • progress
  • scs4_progress.ppm.bz2
• Update

Some interesting files there, most notably the stuff in RootFsUpdateAction. Here’s what i’ve found out:

Modifying the scripts may void your warranty!

Lots of files have a header similar to this:

	#!/bin/sh
	# SCS.4DJ_OSv2.1_rc1_2011-12-02.update
	# Copyright Stanton Magnetics Inc.  All rights reserved.
	# Modifying any component of this file may void your warranty.
	# This script is automatically generated.  Do not update it manually.
	

ColdFire – the name of the chipset used.

It’s a RISC based 32bit processor, and CF4 denotes that it’s a v4 coldfire processor (which is bad news for those of us who wish for a faster processor!). Looks like build tools are available at freescale (go for the “Special Suite (Free Trial)” under codewarrior suites, and get the ColdFire bundle)

RootfsUpdateAction

Looks like a unix style file system! I’m gonna say BSD based…

ELF executable files

ELF format files are used for executables

There is a USB Ethernet adapter configured on this device

RootfsUpdateAction.tar\etc\udev\rules.d\68-drivers-net.rules shows us that the Trendnet USB Ethernet TUET100C has drivers loaded. Which is useful for the next part:

SSHD is available, but not configured

The files are there, but sshd.conf is not setup.

SFTP is available

sftp-server is located in RootfsUpdateAction.tar\usr\libexec

RootfsUpdateAction.tar\lib\modules\2.6.31.12-rt21-ivl-00001-ga75aeaa is a folder

2.6.31.12-rt21 is a linux release, ivl is the manufacturer, not sure what the rest means.

SCS.4DJ startup shell script

#!/bin/sh

# Set time from hardware clock
hwclock --hctosys

# Don't shut off screen
echo -e -n '\033[9]' > /dev/tty0
echo -e -n '\033[?25l' > /dev/tty0

ENABLE_USB_SLAVE_EMI_TEST=0
if [ $ENABLE_USB_SLAVE_EMI_TEST == 1 ]
then
		echo "setting up USB slave"
		RANDOM_SERIAL=$(hexdump -d -n 4 /dev/urandom | \
				sed -e "s/\s\+/ /g" | \
				cut -d' ' -f2,3 -s | \
				sed -e "s/\s\+//g" )

		modprobe g_midi idVendor=0x0d60 idProduct=0x3434 \
				iManufacturer="Stanton Magnetics" iProduct="SCS.4DJ" \
				iSerialNumber="$RANDOM_SERIAL"
fi

UBI_OK=0


if test -e /dev/mtd5
then
		# Hynix flash partition scheme
		MTD_USERFS=5
else
		# Samsung flash partition scheme
		MTD_USERFS=3
fi

echo "Setting up ubi/ubifs"
ubiattach /dev/ubi_ctrl -m $MTD_USERFS && \
		mount -t ubifs ubi1:app /home && \
		UBI_OK=1

if [ $UBI_OK == 0 ]
then
		echo "Application not found." > /dev/tty0
		echo "Formatting user partition..." > /dev/tty0

		# This might fail, depending on whether or not ubiattach succeeded
		ubidetach /dev/ubi_ctrl -m $MTD_USERFS || echo "Can't detach but continuing anyway"

		ubiformat /dev/mtd${MTD_USERFS} -y && \
				ubiattach /dev/ubi_ctrl -m $MTD_USERFS && \
				ubimkvol /dev/ubi1 -N app -m && \
				mount -t ubifs ubi1:app /home
fi

if test -x /home/jars/workspace/app/mx35r/djapp
then
		# Check for BIST request
		if test -d /root/bist
		then
				cd /root/bist/tests/entry
				/root/bin/bist
		fi

		# Start usbmuxd (coldplug)
		usbmuxd

		# Set default language to English
		export LANG=en_US.UTF-8

		# Core dumps -- set size limit in KB
		export COREDUMP_PREFIX=/home/SCS.4DJ_error_report
		ulimit -c 160000
		echo "${COREDUMP_PREFIX}_%e_%t" > /proc/sys/kernel/core_pattern

		# Delete any old core dumps
		rm -rf "${COREDUMP_PREFIX}"*

		while true
		do
				# Start Xfbdev if not running
				fbset -depth 16
				pgrep Xfbdev || Xfbdev -keybd keyboard -screen 480x272x16 &

				cd /home/jars/workspace/app/mx35r
				./djapp &
				PID=$!
				wait $PID
				DJAPP_RET=$?
				echo -ne '\x90\x00\x00' > /dev/ttymxc1

				if [ $DJAPP_RET -eq 0 ]
				then
						poweroff
						break   # Counterintuitively, poweroff returns
				elif [ $DJAPP_RET -ge 16 -a $DJAPP_RET -lt 32 ]
				then
						# Unmount devices so they will be removed cleanly if the user decides to remove them
						umount -lr /mnt/sd*
						umount -lr /mnt/ipod*

						# Don't kill X here
						MIDI_CHAN=$(($DJAPP_RET - 16))
						echo "MIDI channel $MIDI_CHAN"
						cd /home/jars/workspace/midi_controller/mx35r
						./midi_controller -m $MIDI_CHAN &
						PID=$!
						sleep 1
						dd if=/home/jars/workspace/app/resources/themes/GrayRed480x272/gtk-2.0/scs4_midi_screen.rgb565 of=/dev/fb0 bs=960 count=272
						wait $PID

				elif [ $DJAPP_RET -eq 64 ]
				then
						set -x
						# The application has indicated that it wants to do a firmware update
						# and it creates a symlink at /tmp/djapp-requested-fwupdate
						# For some reason -h tests for symlinks
						if test ! -h /tmp/djapp-requested-fwupdate
						then
								echo "The application requested a firmware update but the symlink" >2
								echo "to the update was not set.  (/tmp/djapp-requested-fwupdate)" >2
								echo "No update to apply -- restarting application" >2
								continue
						fi
						killall Xfbdev

						/root/bin/fwupdate-apply /tmp/djapp-requested-fwupdate
						rm -f /tmp/djapp-requested-fwupdate

						# The update may trigger a reboot on its own, or may exit, indicating
						# we should continue as normal
						set +x
						continue

				elif [ $DJAPP_RET -eq 68 ]
				then
						# X is not always in a good state when we exit
						killall Xfbdev

						# Delete local database and support files (-wal, -shm,...)
						rm -f /home/jars/workspace/app/local.db*

						# Delete midi controller configuration
						rm -f /home/jars/workspace/midi_controller/resources/*.txt
						sync
						continue

				elif [ $DJAPP_RET -eq 69 ]
				then
						# X is not always in a good state when we exit
						killall Xfbdev

						# Run a script
						if [ -f /tmp/djapp-exit-script.sh ]
						then
								chmod +x /tmp/djapp-exit-script.sh
								sh -x /tmp/djapp-exit-script.sh
								rm -f /tmp/djapp-exit-script.sh
						else
								echo 'Could not find /tmp/djapp-exit-script.sh'
						fi
						continue

				elif [ $DJAPP_RET -ge 128 ]
				then
						ERROR_SIGNAL=$(($DJAPP_RET - 128))
						SIGINT=2
						SIGTERM=15
						SIGSTOP=19

						# Kill Xfbdev, just in case
						killall Xfbdev
						if [ $ERROR_SIGNAL -eq $SIGINT -o $ERROR_SIGNAL -eq $SIGTERM -o $ERROR_SIGNAL -eq $SIGSTOP ]
						then
								# Stopped for debugging
								break
						else
								# Check for a core dump
								/root/bin/handle-core-dumps.sh

								# Try restarting application
								continue
						fi
				else
						# Kill Xfbdev, just in case
						killall Xfbdev
				fi
		done
elif test -d /root/bist
then
		# Wait for devices to settle
		udevadm settle
		sleep 10
		udevadm settle

		echo "Checking for firmware updates..."
		/root/bin/fwupdate-check-all-devices

		cd /root/bist/tests/menu
		/root/bin/bist
else
		echo "No BIST or application.  Insert USB stick with update." >/dev/tty0
		while [ 1 ]
		do
				sleep 10
				/root/bin/fwupdate-check-all-devices
				if [ $? == 0 ]
				then
						# Successful update -- reboot even if the script does not specify
						# a reboot, because we have nothing better to do
						reboot
				fi
		done
fi

The DJApp itself

Some app resources can be found in DjappUpdateAction.tar\home\jars\workspace\app\resources\, including the db schema, of which there are two:

1. One called ddb_schema (Device Database Schema?)
2. and ldb_schema (Local Database Schema).

The application language files have some further info on the development of the device (* symbols added for privacy),

POT-Creation-Date: 2011-05-24 15:35-0700
PO-Revision-Date: 2008-04-14 18:18-0700
Last-Translator: S******** M******** <********@ivl.com>
Language-Team: ENGLISH S******** M******** <********@ivl.com>

The new 'Generate Device Playlist' feature? Looks like the code was based off of the stanton forum community post!

(header of generate_playlist.sh)

#!/bin/sh
#
# Copyright (C) 2011 by IVL, Inc.,
# All Rights Reserved Worldwide.
#
# This script was derived from work by Vincent Falco from One Guy Group, Inc.,
# You can find him as "thevinn" in the Stanton SCS.4DJ forums
#
# This file is provided under MIT License
# http://www.opensource.org/licenses/mit-license.php
#
# Stanton SCS.4DJ is a trademark of Stanton Magnetics Inc
#   http://www.stantondj.com
#
# -----------------------------------------------------------------------------

Other 'pegasus' compatible network cards that we could use (if we updated the udev rules)

3Com USB Ethernet 3C460B
ATEN USB Ethernet UC-110T
Accton USB 10/100 Ethernet Adapter
SpeedStream USB 10/100 Ethernet
ADMtek ADM8511 "Pegasus II" USB Ethernet
ADMtek ADM8513 "Pegasus II" USB Ethernet
ADMtek ADM8515 "Pegasus II" USB-2.0 Ethernet
ADMtek AN986 "Pegasus" USB Ethernet (evaluation board)
AN986A USB MAC
AEI USB Fast Ethernet Adapter
Allied Telesyn Int. AT-USB100
Belkin F5D5050 USB Ethernet
Billionton USB-100
Billionton USBEL-100
Billionton USBE-100
iPAQ Networking 10/100 USB
Corega FEther USB-TX
Corega FEther USB-TXS
D-Link DSB-650TX
D-Link DSB-650TX(PNA)
D-Link DSB-650
GOLDPFEIL USB Adapter
ELECOM USB Ethernet LD-USB20
EasiDock Ethernet
Elsa Micolink USB2Ethernet
GIGABYTE GN-BR402W Wireless Router
Hawking UF100 10/100 Ethernet
HP hn210c Ethernet USB
IO DATA USB ET/TX
IO DATA USB ET/TX-S
IO DATA USB ETX-US2
Kingston KNU101TX Ethernet
LANEED USB Ethernet LD-USB/TX
LANEED USB Ethernet LD-USBL/TX
LANEED USB Ethernet LD-USB/T
Linksys USB10TX
Linksys USB100TX
Linksys USB10T Ethernet Adapter
Linksys USBVPN1
Linksys USB USB100TX
MELCO/BUFFALO LUA-TX
MELCO/BUFFALO LUA2-TX
Microsoft MN-110
NETGEAR FA101
OCT Inc.
OCT USB TO Ethernet
smartNIC 2 PnP Adapter
SMC 202 USB Ethernet
SMC 2206 USB Ethernet
SOHOware NUB100 Ethernet
SOHOware NUB110 Ethernet

Got shell access!!!

Friday 13th April. After I had the filesystem files, I rewrote the update script to give us a shell on the SCS.4DJ screen! To get shell, do this:

1. Extract the "update" file [here] on a usb stick
2. Get a USB keyboard plugged into the SCS.4DJ
3. Turn on the device whilst holding the pitch bend [-] key on the left deck, and the pitch bend [+] key on the right deck. The top corner lights will flash if you have done this correctly.
4. Once inside the test menu, press the [SYSTEM] button to initiate a firmware update
5. a login prompt should appear
6. enter "user" at the login prompt and type in "user" as the password.
7. boom

Next Steps:

To continue the investigation, we need to get a suitable USB ethernet controller so we can access the device.

There may also be some leverage in using ubiattach...

Comments have been disabled, for more information email kris at switchsystems.co.uk or follow this post in the stanton/gibson forums.

See for yourself at www.onehourpersecond.com

The recovery discs were being sold to customers for £14.99 when customers already have a recovery partition on their computer with the ability to create rescue media.

Comet have responded stating that they were acting in the interest of the customer, due to the policy change that OEM Microsoft operating system installs would not ship with recovery discs.

Congratulations to all who were shortlisted for last nights inaugural Exeter Impact awards held by the University of Exeter. An enjoyable evening with good company, good food, and even a few laughs!

Thank you to all of the RKT team for all their hard work in putting the event together.

Our opening hours over christmas and new years will be:

• Friday 23rd December
  09:00 – 13:00 (Half Day)
• Saturday 24th December
  Closed
• Sunday 25th December
  Closed
• Monday 26th December
  Closed
• Tuesday 27th December to Friday 30th December
  09:00 – 13:00 (Half Day)
• Saturday 31st December
  Closed
• Sunday 1st January
  Closed
• Monday 2nd January
  Closed
• Tuesday 3rd January
  Open as usual

As usual, our out-of-hours emergency contact number will be available 24/7, and we will be regularly checking phones and email so please leave a message if you need to contact us over the festive period.

Stay tuned for our exciting new newsletter, which should be arriving soon!

After signing in, I walked up to the cage where our servers sit. I took a couple of sneaky pictures – i wasn’t sure whether I was allowed to take pictures or not inside the ‘secure area’!

Above: yes people, this is what the internet looks like! Dry air-conditioned floors with raised floors, cable raceways, secure cages and flashing lights.

So the plan was to take out our old 4U VMware server and replace it with two newer, smaller (1U), and much more powerful machines. Then I remembered this server was racked at the top of the cabinet, making it’s removal a very carefully executed operation!

Above: that’s quite high. and that server is v. heavy!

In goes our new gear:

Job done!

Many thanks to the entire Switch Systems team for all their planning and preparation work, making this complete hardware change an operation which only resulted in 90 minutes of downtime (not that I think anyone noticed, as our existing contingency measures meant everything kept running anyway!)