FL Studioの開発元であるImage-Lineが提供中のAndroid/iOS用アプリImage-Line Remote (IL Remote)を導入してみました。このアプリ自体には音楽制作機能はありませんが、Android/iOS搭載モバイルデバイスのタッチパネルをPCで稼働するFL Studio(又はDeckadance)の強力なコントロールサーフィスとして利用可能になります。
IL RemoteはGooglePlayまたはAppStoreより無償ダウンロードが可能です。
使用環境
今回はAndroid版のアプリをZenfone 2 Laserに導入し、64bit版Windows10で稼働する64bit版FL Studio 12を操作してみました。本投稿の記載内容はスマートフォンとタブレットの差異や、OSの差異などによって異なる可能性が有ります。
セットアップ
基本的に難しいことはなく、以下の流れで利用可能になります。
- モバイルデバイスにGooglePlay/AppStoreよりIL Remoteアプリを導入
- モバイルデバイスをFL Studioが稼働するPCと同一のLANに接続
- PCでFL Studioを起動
- モバイルデバイスでIL Remoteアプリを起動
- "Tap to connect"と書いてあるので、タップして接続
※FL Studio側の設定前は以下のエラーが表示されるかもしれませんが問題ありません
- "Tap to connect"と書いてあるので、タップして接続
- FL StudioのMIDI設定画面からIL Remoteを有効化
- Enable Image-Line Remoteをクリック
- Windowsファイヤーウォールの警告ダイアログが表示されるので、危険性を認識したうえでFL Studioの通信を許可
後述しますが、デフォルトはゆるゆるな設定のため、パブリックネットワークを許可することはリスキーです。プライベートネットワークのみに限定するべきでしょう - Input MIDI deviceにFL Studio Remoteが表示され、ステータスがグリーン表示であることを確認
- Enable Image-Line Remoteをクリック
初回以外はPCでFL Studioを、モバイルデバイスでIL Remoteを起動するだけですので特別面倒なことは何もありません。
できること
アプリ側では以下のコントロールサーフィスが使用可能です(前述の通りモバイルデバイスの画面サイズやOSによって異なる可能性が有ります)。
ユーザによって感じ方は異なるかもしれませんが、スイッチやフェーダーの類のコントローラはタッチパネルでもかなり使いやすく、nanoKONTROL等のハードウェアMIDIコントローラと同様に操作性が向上します(一方、ツマミ(ノブ)型のような回転型コントローラをタッチパネルで操作するのは私は苦手で、まだまだハードウェアコントローラの方が断然使いやすいです)。
MAIN
↑主にFL Studioそのもののを操作するスイッチ群
PIANO
↑主にキーボードコントローラとKORG製品でメジャーになったXYパッド
FPC
↑AKAI MPCを模したトリガーパッドとフェーダー
HARMO
↑コード(和音)入力用マトリクス
SLICEX
PERFORM
MIX
↑ミキサーの音量フェーダーと3バンドEQ
ファイヤーウォール設定について
セットアップの項でも触れましたが、デフォルトではファイヤーウォールにゆるゆるの大穴が開く設定となっています。セキュリティ観点からファイヤーウォールに開ける穴は必要最低限に埋めるべきです。
アクセス許可直後のWindows Firewallの設定状態
FL StudioのMIDI設定画面で[Enable Image-Line Remote]を押下した際に表示されたWindowsファイヤーウォールの警告ダイアログで[アクセスを許可する]を押下すると、以下のようにTCP用とUDP用で合計2つの"受信の規則"が作成されます。
この規則の詳細な設定値は以下の通り。ポート指定も無く、ネットワーク上の全端末からFL Studioの実行体(fl64.exe)に対して通信を試みる(攻撃を試みる)ことが可能な設定となっています。
>netsh advfirewall firewall show rule name="FL Studio" verbose 規則名: FL Studio ---------------------------------------------------------------------- 説明: FL Studio 有効: はい 方向: 入力 プロファイル: プライベート,パブリック ← チェックボックス選択状態で異なる グループ: ローカル IP: 任意 リモート IP: 任意 プロトコル: UDP ローカル ポート: 任意 リモート ポート: 任意 エッジ トラバーサル: ユーザーに従う プログラム: C:\program files (x86)\image-line\fl studio 12\fl64.exe インターフェイスの種類: 任意 セキュリティ: NotRequired 規則のソース: ローカル設定 操作: 許可 規則名: FL Studio ---------------------------------------------------------------------- 説明: FL Studio 有効: はい 方向: 入力 プロファイル: プライベート,パブリック ← チェックボックス選択状態で異なる グループ: ローカル IP: 任意 リモート IP: 任意 プロトコル: TCP ローカル ポート: 任意 リモート ポート: 任意 エッジ トラバーサル: ユーザーに従う プログラム: C:\program files (x86)\image-line\fl studio 12\fl64.exe インターフェイスの種類: 任意 セキュリティ: NotRequired 規則のソース: ローカル設定 操作: 許可 OK
ネットワーク絡みのソフトウェアとは異なり、音楽制作ソフトのセキュリティなんて特別気にしないユーザが多いのではないかと思います。ですがこの設定値のまま運用し続けて、FL Studioに未知の脆弱性が有った場合、攻撃者にとって絶好のターゲットにされてしまう可能性が有ります。すなわち、差し迫った危険性は無いかもしれませんが、潜在的に危険な状態ではあります。
(蛇足)64bit版実行体の場所
本論から逸れますが、上記に掲載した"受信の規則"設定のプログラム設定値が気持ち悪い感じです。
私の環境では64bit版Windows 10を使用していますが、64bit版バイナリが格納されるべき"Program Files"配下ではなく、"Program Files (x86)"配下にfl64.exeという64bit版の実行体が配置されています(FL Studioのインストール先ディレクトリはデフォルトから変更していません)。
>dir "c:\Program Files (x86)\Image-Line\FL Studio 12\*.exe" /on
ドライブ C のボリューム ラベルは OS です
ボリューム シリアル番号は ****-**** です
c:\Program Files (x86)\Image-Line\FL Studio 12 のディレクトリ
2016/12/15 21:53 392,000 FL (compatible memory).exe
2016/12/15 21:53 387,584 FL (scaled).exe
2016/12/15 21:53 392,000 FL.exe
2016/12/15 21:53 406,016 FL64 (scaled).exe
2016/12/15 21:53 410,432 FL64.exe
2016/12/15 22:54 4,138,464 uninstall.exe
6 個のファイル 6,126,496 バイト
0 個のディレクトリ 1,476,898,816 バイトの空き領域どうやら"Program Files (x86)"配下に32bit版と64bit版の両方が混在して配置されるようです。念のため"Program Files"の方を確認してみても、FL Studio本体はありません。
>tree "c:\Program Files\Image-Line" /a
フォルダー パスの一覧: ボリューム OS
ボリューム シリアル番号は ****-**** です
C:\PROGRAM FILES\IMAGE-LINE
\---Downloader
+---Downloads
+---Fonts
+---Stub
+---Temp
\---Update64bit非対応VSTプラグインもあったりするので、その兼ね合いでカオス構成になっていたりするのでしょうかねぇ？
閑話休題。
FL Studioの通信の状況を調べる
FL Studio(64bit版)の実行体(fl64.exe)がWindowsファイヤーウォールの規則に登録されていたことから、通信を司る実体は外部プログラムに分割されているわけではなく、fl64.exeそのものであることが解ります。ということで、まずはfl64.exeのプロセスID(PID)を特定します。
>tasklist /fi "IMAGENAME eq FL64.exe" イメージ名 PID セッション名 セッション# メモリ使用量 ========================= ======== ================ =========== ============ FL64.exe 2984 Console 1 77,304 K
当該プロセスの通信を調べてみると以下の通り。
>netstat -a -b -o -n アクティブな接続 プロトコル ローカル アドレス 外部アドレス 状態 PID UDP 0.0.0.0:55273 *:* 2984 [FL64.exe] UDP 0.0.0.0:55274 *:* 2984 [FL64.exe] UDP 192.168.1.23:9050 *:* 2984 [FL64.exe]
WindowsファイヤーウォールにはTCPの"受信の規則"も作成された状態ですが、実は上記のようにUDPしか使っていないようです。また、FL Studioを何度か起動・終了してみたところ、リモートのポート番号は動的に変わり、ローカルのポート番号9050は常に固定されているように見受けられました。
Image-Line公式のサポート情報を調べてみると、ポート番号について触れている以下の記述が見つかりました。
2. Disable anti-virus programs - If this works, white-list FL Studio in the anti-virus program options. Look for any firewall options (integrated into the anti-virus program) as mentioned above. If there are options, allow FL Studio (FL.exe) for local networks and enable port 9050 and 9100 for UDP protocol.
3. Check your network router's admin controls - Look for IP filtering, MAC filtering (if your device can connect to the internet through your Wi-Fi network this won't be the cause), router firewalls etc. Ports - Try adding a manual rule to allow FL Studio (FL.exe) for local networks and enabling port 9050 and 9100 for UDP protocol. IL Remote only uses port 9050, so add this exception anywhere you can find the opportunity.
ということで、UDPのポート9050、9100だけ開放していれば動作に支障は無さそうです。故に、TCPの"受信の規則"は削除し、UDPの"受信の規則"のポート番号指定はanyから固定値に変更することで、僅かながらシステムのハードニングを図れるでしょう。
設定変更後のWindows Firewallの設定値
2つあったFL Studioの"受信の規則"のうち、TCPの方は削除します。UDPの方を残し、ローカルポートを9050,9100に変更、エッジトラバーサルをブロックするに指定、プロファイルをプライベートのみにチェックを入れます。
この設定変更後は以下のような設定値になるはずです(この状態でAndroid側のIL RemoteからFL Studioが操作可能な事は確認していますが、設定を誤るとIL Remoteが使用不能になりますのでご注意ください)。
>netsh advfirewall firewall show rule name="FL Studio" verbose 規則名: FL Studio ---------------------------------------------------------------------- 説明: FL Studio 有効: はい 方向: 入力 プロファイル: プライベート グループ: ローカル IP: 任意 リモート IP: 任意 プロトコル: UDP ローカル ポート: 9050,9100 リモート ポート: 任意 エッジ トラバーサル: いいえ プログラム: C:\program files (x86)\image-line\fl studio 12\fl64.exe インターフェイスの種類: 任意 セキュリティ: NotRequired 規則のソース: ローカル設定 操作: 許可 OK
これで過剰にゆるゆるだったファイヤーウォールの大穴が、必要最低限に近づきました。理想的には接続可能なリモート端末も制限したいところですが、WiFiルータのDHCPに依存してAndroid端末のIPアドレスは動的に変わりますし、ホスト名もよく解らないため、この程度の設定で致し方ないかと。不特定多数の端末が存在する公衆無線LANなどに接続するPCの場合、この設定でもまだリスキーですが、不審な端末も無く外部からアクセス不能な宅内/社内LANであれば特に問題ないでしょう。
以上。
