読者です 読者をやめる 読者になる 読者になる

ポケモン ダイヤモンド・パールのGTS/バトルタワーの通信プロトコルについて

この記事は Pokemon RNG Advent Calendar 2016 の10日目です。

www.adventar.org

いわゆる「乱数調整」とは関係ないのですが、箸休めということで。


Q.) お前誰だよ?

A.) 「ポケモンの友」の管理者です。

pokebook.jp

(XY以降は、アイドルプロデュース活動が忙しくて全然手が回っていません……)


以下本題。

ポケモン ダイヤモンド・パールから 「GTS」と「Wi-Fiバトルタワー」という施設が登場しました。

ネットワークサービス「ニンテンドーWi-Fiコネクション」を使って、 全世界のトレーナーと交換や対戦(※CPU戦)が楽しめるというものです。

さすがに10年も前のゲームなので、これらのサービスはすでに終了してしまっているのですが、

せっかくなので、当時を思い出しながら書いてみます。


まずはじめに、ニンテンドーDSとサーバーとの間でどのような通信がされているか調べました。

ゲームのROMデータはDSカードから吸い出すことができていたので、 その中に含まれているエンドポイントのホスト名はすぐにわかりました。

そこで、LAN内にある作業用PCにDNSサーバーとHTTPサーバーを立てて、 上記ホスト名が作業用マシンのIPに向くよう設定し、DS側のDNS設定を作業用マシンのIPに。

として通信内容を観察すると、ゲーム内でのいちどの通信で、HTTP GETを2回行っていることが分かりました。

「HTTP?HTTPSではなくて?」と思われたかた、 10年も前のゲームであり、処理能力がそんなに高くないゲーム機での通信ということを思い出してください。

処理の流れは以下のようになります。

  1. 通信を行いたいエンドポイントに対して、パラメータにプレイヤーIDのみをつけてリクエストする。
  2. サーバー側からは、ランダムに生成されたトークン文字列が返却される。
  3. ゲーム側で、上記トークン文字列に対応したハッシュ値を求める。
  4. 1.と同じエンドポイントに対して、プレイヤーID、3.のハッシュ値、送信したいデータをBASE64URLエンコードしたもの、をパラメータにしてリクエストする。
  5. サーバー側でデータに応じた処理が行われる。
  6. 結果がバイナリデータで返却される。

f:id:mirai-iro:20161210004251p:plain

いわゆる「チャレンジ/レスポンス認証」というやつですね。

間にプロキシを挟んだ図は以下のようになります。

f:id:mirai-iro:20161210004300p:plain

これで何度か通信をして、ある程度ログをためて分析、という手順で進めていきました。


さて、プレイヤーIDは上記通信に生の値が含まれているのですが、残りのデータはどうなっているのでしょうか?

まず、レスポンスのバイナリデータについては、とくに暗号化がされていないことがわかりました。 GTSに預けたポケモンの情報を取得したとき、セーブデータに格納されている状態のものがそのまま却ってきていたからです。

もちろん、このポケモン情報自体は、暗号化がされています。いわゆるbin状態のpkmというやつです。 (Pokemon NDS Structure - ProjectPokemon Wiki)

3.のハッシュ値の計算については、文字列の長さが40であったので、方式がSHA-1という予想はすぐにたちました。 ですが、トークン文字列そのままのSHA-1ハッシュ値を算出しても、4.で送信しているハッシュ値と合いません。 つまり、なんらかのソルト値を加えているようなのですが……。

そこで、ソルト値が送信するデータや時刻によってハッシュ値が変わるかどうか確かめるため、 1.の通信がプロキシサーバーに来たとき、APIサーバーにアクセスせず、固定値を返すようにしました。

……すると、なんと毎回同じハッシュ値となることが分かりました。 ソルト値は送信するデータや時刻によらない固定された値と考えられます。

と、ここでエンドポイントのホスト名を調べている途中で、近くに不自然な文字列があったことを思い出しました。

もしかして……と思い、そのROM内の文字列とトークン文字列をつなげた文字列のSHA-1ハッシュ値を算出したところ……ビンゴ。


さて、最後の本丸、4.のリクエストデータに関してです。

さらに調査を続けたところ、このデータは、なんらかの暗号化がされているものの、同じリクエスト内容であれば常に同じデータということがわかりました。

つまり、あらかじめゲーム側で通信を行った際のリクエストを保存しておけば、残りの通信についてはもうルーチンが判明しているので、同じ通信を、ゲームを介することなしに行うことが可能になりました。

そう、バトルタワーの特定ルームの登録状況や、GTSの特定ポケモンのトレード情報を、ゲーム側を介さずに定点観測できるようになったのです。


しかし、やはり送信データがどのように作られているか知りたい。

というわけで、たまったログデータをもとに推測してみることにしました。

以下は、プレイヤーID 80162411 で、バトルタワーの情報を取得した時のリクエストデータです。

クエリパラメータ バイナリに変換したデータ(16進) ゲーム側からの取得内容
SjsteZ/Myel= 4A 3B 2D 79 9F CC C9 E9 サービス稼働状態の確認
SjsteZ/Myenk 4A 3B 2D 79 9F CC C9 E9 E4 ルーム数の確認
Sjstd/lWXar5Wj== 4A 3B 2D 77 F9 56 5D AA F9 5A ランク1 ルーム7 の情報を取得
Sjstdrw8G32pVz== 4A 3B 2D 76 BC 3C 1B 7D A9 57 ランク2 ルーム7 の情報を取得
SjstcXeF2UBUQT== 4A 3B 2D 71 77 85 D9 40 54 41 ランク3 ルーム7 の情報を取得
SjstcApqpwoHOj== 4A 3B 2D 70 0A 6A A7 0A 07 3A ランク4 ルーム7 の情報を取得
Sjstc83zZd22ND== 4A 3B 2D 73 CD F3 65 DD B6 34 ランク5 ルーム7 の情報を取得
SjstcoBYI6BkIT== 4A 3B 2D 72 80 58 23 A0 64 21 ランク6 ルーム7 の情報を取得
SjstbVsh4WsJGz== 4A 3B 2D 6D 5B 21 E1 6B 09 1B ランク7 ルーム7 の情報を取得
SjstbB6Grz66FD== 4A 3B 2D 6C 1E 86 AF 3E BA 14 ランク8 ルーム7 の情報を取得
Sjstb9FvbQFjDj== 4A 3B 2D 6F D1 6F 6D 01 63 0E ランク9 ルーム7 の情報を取得
SjstbpT0K9QQ+z== 4A 3B 2D 6E 94 F4 2B D4 10 FB ランク10 ルーム7 の情報を取得

ランクとルームの2バイトですみそうなところ、なぜか10バイトを送っています。 しかも、データの頭のほうが同じような値です。

4A 3B 2* … うーん?

ためしに、最初の4バイトと 4A 3B 2C 1D とのXORを取ってみます。

ゲーム側からの取得内容 先頭4バイトのXORを計算したデータ(16進)
サービス稼働状態の確認 4A 3B 2D 79 xor 4A 3B 2C 1D = 00 00 01 64
ルーム数の確認 4A 3B 2D 79 xor 4A 3B 2C 1D = 00 00 01 64
ランク1 ルーム7 の情報を取得 4A 3B 2D 77 xor 4A 3B 2C 1D = 00 00 01 6A
ランク2 ルーム7 の情報を取得 4A 3B 2D 76 xor 4A 3B 2C 1D = 00 00 01 6B
ランク3 ルーム7 の情報を取得 4A 3B 2D 71 xor 4A 3B 2C 1D = 00 00 01 6C
ランク4 ルーム7 の情報を取得 4A 3B 2D 70 xor 4A 3B 2C 1D = 00 00 01 6D
ランク5 ルーム7 の情報を取得 4A 3B 2D 73 xor 4A 3B 2C 1D = 00 00 01 6E
ランク6 ルーム7 の情報を取得 4A 3B 2D 72 xor 4A 3B 2C 1D = 00 00 01 6F
ランク7 ルーム7 の情報を取得 4A 3B 2D 6D xor 4A 3B 2C 1D = 00 00 01 70
ランク8 ルーム7 の情報を取得 4A 3B 2D 6C xor 4A 3B 2C 1D = 00 00 01 71
ランク9 ルーム7 の情報を取得 4A 3B 2D 6F xor 4A 3B 2C 1D = 00 00 01 72
ランク10 ルーム7 の情報を取得 4A 3B 2D 6E xor 4A 3B 2C 1D = 00 00 01 73

ランクが増えると、応じて1ずつ増えています。

もしかして、最初の4バイトは1オクテットのチェックサムなのでは……?

さらに、プレイヤーIDの 80162411 を16進数にすると0x04C72E6B 、 0x04 + 0xC7 + 0x2E + 0x6B = 0x0164 ……あれ?

ゲーム側からの取得内容 予想データ サム値 先頭4バイトのXOR
サービス稼働状態の確認 6B 2E C7 04 00 0x0164 00 00 01 64
ルーム数の確認 6B 2E C7 04 00 0x0164 00 00 01 64
ランク1 ルーム7 の情報を取得 6B 2E C7 04 01 07 0x016C 00 00 01 6A
ランク2 ルーム7 の情報を取得 6B 2E C7 04 02 07 0x016D 00 00 01 6B
ランク3 ルーム7 の情報を取得 6B 2E C7 04 03 07 0x016E 00 00 01 6C
ランク4 ルーム7 の情報を取得 6B 2E C7 04 04 07 0x016F 00 00 01 6D
ランク5 ルーム7 の情報を取得 6B 2E C7 04 05 07 0x0170 00 00 01 6E
ランク6 ルーム7 の情報を取得 6B 2E C7 04 06 07 0x0171 00 00 01 6F
ランク7 ルーム7 の情報を取得 6B 2E C7 04 07 07 0x0172 00 00 01 70
ランク8 ルーム7 の情報を取得 6B 2E C7 04 08 07 0x0173 00 00 01 71
ランク9 ルーム7 の情報を取得 6B 2E C7 04 09 07 0x0174 00 00 01 72
ランク10 ルーム7 の情報を取得 6B 2E C7 04 10 07 0x0175 00 00 01 73

ルーム情報の取得で2ずれていますが、ランク1 = 内部値0 と考えるとつじつまが合います。

と、ここまでは来たのですが、5バイト目以降のデータがどのように作られているのか、さっぱり見当がつきません。

ということで、ここからアセンブラの出番です。

ゲームのROMデータを 4A 3B 2C 1D で検索したところ1件ヒット。 近くを逆アセンブルしてみます。

(以下、正確な位置で切り出せなかったので、アドレスが変な感じになってしまっています)

000000fa 480e        ldr r0, [pc, #56]   ($00000134)     # r0 = 0x00000134 の値 = 0x4a3b2c1d
000000fc 4046       eor r6, r0                          # r6 = r6 xor r0
000000fe 0e30       lsr r0, r6, #24                     # r0 = r6 >>> 24
00000100 7038       strb    r0, [r7, #0]                # (r7 + 0)が指す先にr0の下位1バイトを格納
00000102 0c30       lsr r0, r6, #16                     # r0 = r6 >>> 16
00000104 7078       strb    r0, [r7, #1]                # (r7 + 1)が指す先にr0の下位1バイトを格納
00000106 0a30       lsr r0, r6, #8                      # r0 = r6 >>> 8
00000108 70b8       strb    r0, [r7, #2]                # (r7 + 2)が指す先にr0の下位1バイトを格納
0000010a 70fe       strb    r6, [r7, #3]                # (r7 + 3)が指す先にr0の下位1バイトを格納
(中略)
00000134 2c1d       cmp r4, #29
00000136 4a3b       ldr r2, [pc, #236]  ($00000224)

r5にデータ長さ、r6にSUM値、r7に送信するデータが格納されているメモリアドレスが入っているようです。 では、その少し手前を見てみます。

000000de 2400        mov r4, #0                          # r4 = 0
000000e0 2d00       cmp r5, #0
000000e2 dd0a       ble $000000fa                       # r5 <= 0 なら ★を飛ばす
# ★ {
000000e4 f000 f828  bl  $00000138                       # 0x00000138 を呼び出し
000000e8 9900       ldr r1, [sp, #0]                    # r1 = スタックポインタ内の値が指すアドレスに格納された値 (引数で渡された値と考えてください)
000000ea 5d09       ldrb    r1, [r1, r4]                # r1 = (r1 + r4)からバイト単位ロード
000000ec 4041       eor r1, r0                          # r1 = r1 xor r0
000000ee 1c20       mov r0, r4      (add r0, r4, #0)    # r0 = r4
000000f0 3008       add r0, #8                          # r0 = r0 + 8
000000f2 5439       strb    r1, [r7, r0]                # (r7 + r0)が指す先にr1の下位1バイトを格納
000000f4 1c64       add r4, r4, #1                      # r4 = r4 + 1
000000f6 42ac       cmp r4, r5
000000f8 dbf4       blt $000000e4                       # r4 <= r5 なら 0x000000e4 へジャンプ
# } ★

r1 に、暗号化前のリクエストデータが格納されているアドレスをロードして、作業しているようです。

1バイトごとに、0x00000138 を呼び出したあと、r0に入っている値とXORしていますね。 r0には何が入っているのでしょうか? 呼び出し先のルーチンを見てみます。

00000138 4906        ldr r1, [pc, #24]   ($00000154) # r1 = 0x022185a0
0000013a 680a       ldr r2, [r1, #0]                # r2 = r1のアドレスの値
0000013c 2045       mov r0, #69                     # r0 = 69 (=0x45)
0000013e 4342       mul r2, r0                      # r2 = r2 × r0
00000140 4805       ldr r0, [pc, #20]   ($00000158) # r0 = 0x00001111
00000142 1812       add r2, r2, r0                  # r2 = r2 + r0
00000144 4805       ldr r0, [pc, #20]   ($0000015c) # r0 = 0x7fffffff
00000146 4002       and r2, r0                      # r2 = r2 and r0
00000148 600a       str r2, [r1, #0]                # r1のアドレス(=0x022185a0)にr2を格納
0000014a 1410       asr r0, r2, #16                 # r0 = r2の上位16ビット
0000014c 0600       lsl r0, r0, #24                 # r0 = r0 <<< 24
0000014e 0e00       lsr r0, r0, #24                 # r0 = r0 >>> 24 つまりこれで r2 の下から17-24ビット目の値だけが残る
00000150 4770       bx  lr                          # 呼び出し元に戻る
00000152 46c0       nop         (mov r8,r8)
00000154 85a0       strh    r0, [r4, #44]
00000156 0221       lsl r1, r4, #8
00000158 1111       asr r1, r2, #4
0000015a 0000       lsl r0, r0, #0
0000015c ffff       second half of BL instruction 0xffff
0000015e 7fff       ldrb    r7, [r7, #31]

r0 が ((アドレス[0x022185a0]に格納された値 × 0x45 + 0x1111) >>> 16) & 0xFF という値だと分かりました。

[0x022185a0]にはなにが格納されているのでしょうか? 000000deの位置に戻って、もう少し手前を見てみます。

000000ac 1c30        mov r0, r6      (add r0, r6, #0)    # r0 = r6 = SUM値
000000ae f000 f857  bl  $00000160                       # 00000160 を呼び出し

00000160 0401       lsl r1, r0, #16                 # r1 = r0 <<< 16
00000162 4308       orr r0, r1                      # r0 = r0 or r1
00000164 4901       ldr r1, [pc, #4]    ($0000016c) # r1 = 0x022185a0
00000166 6008       str r0, [r1, #0]                # r1のアドレスにr0を格納
00000168 4770       bx  lr                          # 呼び出し元に戻る
0000016a 46c0       nop         (mov r8,r8)
0000016c 85a0       strh    r0, [r4, #44]
0000016e 0221       lsl r1, r4, #8

つまり アドレス0x022185a0に、SUM値の下位2バイトを上位2バイトにORしてできた値が入っているようです。

# 例) SUM値が 0x0164 なら、入っている値は 0x01640164


ということで、リクエストデータは以下の線形合同法を使ったストリーム暗号で暗号化されているということが分かりました。

S[0] = (1オクテットのチェックサム * 0x00010000) + (1オクテットのチェックサム) % 0x100000000

S[n+1] = (0x45 * S[n] + 0x1111) % 0x100000000

r[n] = (S[n] >>> 16) % 0x0100

……というようなことは、世界中のポケモンに詳しいハッカーが調べていて、

GTSの動作をエミュレートして任意のポケモンGTS経由でゲーム内に送ったり、 GTSにあずけたポケモン個体値を内部データから正確に表示する、 などのWebサービスが、DS末期に登場したりなどしました。

もちろん、これらの行為はいろいろと危険が危ないので、くれぐれもご用心を。

自称「アイマスエンジニア」とはいったい何だったのか

2016/12/17(土)に「アイマスハッカソン2016」というイベントがあります。

imas.connpass.com

何年も前から「アイマス好きのITエンジニア」を公言してきた自分としては、仲間が増えてとてもうれしいです。

……と単純に言えればよいのですけれど、 正直に言うとこの状況にどう向き合えばよいのか分かりません。

自分の活動っていったいなんだったのだろうと。


2013年、まだ自分が岡山に住んでいたころ。

職業ITエンジニアとして、またそれ以前から趣味でWebサイトを作っていた人間として、 そしてアーケード版(当時7年前)からプロデューサーとしてアイドルマスターと付き合ってきて。

当時、アニメ(2012年7月期・錦織監督作品)が放送されたり、Mobageシンデレラガールズが盛り上がり始めたりと、アイドルマスターXbox360版以来の拡大傾向にあったこと。

TwitterなどSNSが広く使われだしたこと。

などなどあり、地方で細々と活動していた自分には信じられないくらい、全国に同じくアイマス好きの仲間が増え、そして可視化されつつありました。

しかし、アイマス以外で知り合った、いわゆるエンジニア層には、プロデューサーを公言しているようなひとは目立っていませんでした。

どちらかというと、当時スクフェスからのラブライブ!が流行していたり、キュアエンジニアだったり、アイカツ!していたりと、 ほかの作品のファンを公言していたITエンジニアが多数を占めていたように思います。

それでも、いちおう自分もプロデューサーのはしくれ。

岡山のIT勉強会で発表してみたり、

www.slideshare.net

Twitterでそれっぽい話をしてみたり。

以前から続けていた自分のサイトで、新しくWebアプリケーション的なものを作ってみたり。

勉強会に出たり、アイマス関係なく、さまざまなITエンジニアのかたたちと出会ってみたり。

しかし、その活動もよい結果には結びつかなかった、と自分には感じられました。

その後も「アイマスエンジニア」、アイマス好きを推しだしているITエンジニア、が増えたように感じられなかったからです。


時は流れ、2015年。

アイドルマスターは10周年を迎え、前年の劇場版や、シンデレラガールズのアニメ化、デレステのリリース、など、なおも拡大の一途をたどり。

とくにアニメシンデレラガールズデレステの影響が大きく、 まわりのアイマスにとくに興味がなかったITエンジニアのかたたちが、日々アイマスの話をするようになり、 ぼくの観測範囲でも、明らかにアイマスの話であふれるようになりました。


それで冒頭の話に戻るのですが。

気づいてしまったのです、結局「それ自分のプロデュース力じゃなくね?」と。

アイマスの話をするITエンジニアが目に見えて増えたのはデレステの影響が多分に大きいこと。

ずいぶん前から「アイマスエンジニア」だの「アイマス勉強会」だの言ったり、 アドベントカレンダー企画してたりしてたのにまったく周りに影響を与えられなかったこと。

www.adventar.org (しかも企画しておいて一記事も書けていないこと(後述)。)

そして、それとは関係なく、スッと今回のハッカソンや、今年のアドベントカレンダーを力強く立ち上げられた先輩のみなさま。

www.adventar.org

結局、自分のプロデュース力が足りなかったのです。

そう思うと、「今までの自分がやってきたことってなんだったのだろう?」と、かなしくなってしまいました。


さらに、自分のキャパシティが無くなってしまい、身軽に動くことができなくなったということもあります。

先のように、単純にアイドルマスターに関する情報量が爆発的に増えたこと、 東京に移り住んでいろいろなイベントへ取材に行けるようになったこともあり、 自分のサイトの情報の更新が追い付かなくなってしまったのです。

この声明を出したのはもう約半年前なのですが、状況はまったく好転していません。


そんな中、いったいどんな顔でハッカソンアドベントカレンダーに参加したらいいかわからないの……。

いや繪里子さんは「プロデュースの方法は、それぞれでいいと思う」とおっしゃいましたけれど。

気持ちに整理をつけるにはいったいどうしたらよいのでしょうか。

ダイアリーから記事移行しました

表題のとおりです。

いろいろあってしばらく目立ったアウトプットができずにいたのですが、
これからいろいろアウトプットしてゆくつもりです。

なお一部の記事は削除させていただきました。
あしからずご了承ください。

大都会岡山 Advent Calendar 2014 (at 12/1 47時)

アッハイ

というわけで作ったのでした。

大都会岡山 Advent Calendar 2014
http://www.adventar.org/calendars/661

このエントリは1日目(12/1)になる予定です。
大丈夫です、まだ12/1の47時ごろです^^

私はもう1年半ほど前に岡山を離れてしまったのですが、10年ほど過ごした、ITエンジニアとして歩き始めた地であるので、岡山には特別な思いがあります。

岡山にいたころに出会えたみなさんとも、まだまだネット上などでお付き合いしていただいており、大変感謝しています。

そんな感謝の気持ちを込めて、お送りしました。

2日目へ続く。

岡山と東京の勉強会の違いについて考える

このエントリは「大都会岡山 Advent Calendar 2013」の13日目のエントリです。
昨日はtamaさんの「大都会にコメダができたそうな」でした。シロノワールおいしそうです。

 

さて本題。
自分は今年の7月に会社の都合で転勤となり、大都会岡山から東京へ引っ越しました。

そうです、いつもTLやUSTで「ぐぬぬ」と指をくわえてみていた、いろんな勉強会に参加できるようになったのです。
ということで、東京で参加した勉強会と、岡山での勉強会を比べて思うことなどをレポートしようと思っていたのですが……。

東京へ引っ越してから参加した勉強会の件数、なんと驚きの0件。

うわっ……私の意識、低すぎ?

どうしてこうなった。

というわけで、反省会を兼ねて、岡山と東京との違いを考えてみようと思います。

 

1. 東京の勉強会は自分で探さないと触れる機会がない

岡山にいたころは「勉強会やります!参加者募集中!」という話題がわりとTLに流れてきていました。
コミュニティが小さいことと、絶対的な人数が少ないこともありますが、積極的なかたが多いということもあります。

それに対し、東京の勉強会は参加者募集をほとんど見かけません。
ひとが多いから、そこまで宣伝しなくても参加者が集まるのだと思います。
また知ったころにはもう開催中か、参加希望者多数につきキャンセル待ちで、結局あきらめるということも多かったです。
早いうちにこちらから積極的に探す必要があるのだと思います。
(「IT勉強会カレンダー」というものを教えていただきました。)

2. 東京の勉強会は平日夜が多く、途中参加もしづらい

岡山の勉強会は土日の昼に公共施設で開催されることが多かったですが、
東京の勉強会は平日の夜にセキュリティのしっかりしたビルで開催されることが多いように思います。

自分の働いている会社は終業時刻が遅いので、平日夜だと途中参加になってしまいます。
そしてセキュリティのしっかりしたビルなので、途中参加が面倒とか、そもそもできないとかで、あきらめた勉強会がいくつかありました。

3. 東京は勉強会以外にもイベントが多い

岡山に居たころあきらめていたのは勉強会だけではありません。
そう、サブカル系イベント(とくにアイドルプロデュース業)もそのひとつ。
週末の予定がそういったイベントで埋まってしまうことが多かったです。

 

まとめると、引っ越しで物理的にコミュニティから離れてしまったこと、タイミングがなかなか合わないこと、それもあいまって自分にとって勉強会のプライオリティが下がったこと、ということでした。

(もうひとつ「単に仕事or私情でヒマがなかった」ということもありますが本題とは関係ないので割愛。)

はやく意識を取り戻さねば。

 

「大都会岡山 Advent Calendar 2013」明日は真さんです。

 

追伸その1

今週末2013/12/14(土)は「合同勉強会 in 大都会岡山 -2013 Winter-」&「忘年会議2013」です。
ぼくは残念ながら参加しないのですが、岡山の近くにお住いのかたはぜひ。

追伸その2

岡山で知り合ったみなさんへ。
TLで絡むことが減っていたり、フォローを外されてしまったりと、さみしく思っています。
また仲良くしてやってください。

ミリオンライブ!のアイドルのイメージカラーは公式ブログで使われている色なのか?

アイマス

というわけで過去のエントリ含めて調べてみました. (注:LTP05メンバー以外は楽曲の文字色です)

アイドル 公表済の色 文字色 公式ブログのエントリー
最上静香 ■ #0000ff 静香ソロ曲「Precious Grain」の試聴がスタート!
七尾百合子 ■ #00bfff 七尾百合子「透明なプロローグ」&箱崎星梨花「トキメキの音符になって」試聴開始
箱崎梨花 ピンク ■ #ee82ee 七尾百合子「透明なプロローグ」&箱崎星梨花「トキメキの音符になって」試聴開始
望月杏奈 ■ #ee82ee 「THE@TER PERFORMANCE 03」試聴開始!&ジャケット公開!
春日未来 ■ #fa8072 「THE@TER PERFORMANCE 03」未来ソロ&奈緒ソロ、試聴開始!
横山奈緒 ■ #ee82ee 「THE@TER PERFORMANCE 03」未来ソロ&奈緒ソロ、試聴開始!
豊川風花 - ■ #fa8072 「THE@TER PERFORMANCE 03」風花ソロ&響ソロ、試聴開始!
我那覇響 ライトブルー(浅葱) ■ #0000ff 「THE@TER PERFORMANCE 03」風花ソロ&響ソロ、試聴開始!
所恵美 黒(または青) ■ #ee82ee 「THE@TER PERFORMANCE 04」恵美ソロ曲&カード絵柄大公開!
田中琴葉 - ■ #fa8072 「THE@TER PERFORMANCE 04」琴葉ソロ&イベント出演者公開!
北沢志保 ■ #9370db 「LIVE THE@TER PERFORMANCE 04」志保ソロ曲を公開!
水瀬伊織 ピンク ■ #ef82ef 「THE@TER PERFORMANCE 05」特典カード絵柄を公開!
エミリー ■ #6000bf 「THE@TER PERFORMANCE 05」特典カード絵柄を公開!
真壁瑞希 - ■ #80c0ff 「THE@TER PERFORMANCE 05」特典カード絵柄を公開!
百瀬莉緒 - ■ #ffc0c0 「THE@TER PERFORMANCE 05」特典カード絵柄を公開!
北上麗花 - ■ #33ffcc 「TP06」麗花ソロ&美希ソロ視聴開始!イベントグッズ情報も!
星井美希 フレッシュグリーン ■ #66ff33 「TP06」麗花ソロ&美希ソロ視聴開始!イベントグッズ情報も!

LTP05メンバーの文字色はたしかにそうっぽいですが, 楽曲の文字色については相関なさそうです. 残念.

なお, ミリオンライブ!のアイドルのイメージカラーは「あくまでも(CVが出演する)イベントで使ってほしいサイリュームの色」であるとも発表されています.
正確な「アイドルのイメージカラー」が知りたいところですが, そこは大人の事情なのでしょうか…….

CV未定のアイドルに声優の色が付く、アイマス史上前例のない出来事が発生

アイマス

モバマスについて|ジェーニャオフィシャルブログ「From Russia with love...」Powered by Ameba の件。


アイドルマスターにおいて、アイドルのCVを担当する声優はほぼオーディションにより選ばれます。

選ばれた声優は「アイマスガールズ」と呼ばれ、ゲーム、楽曲、ラジオ番組、ライブイベント、などを通じファン(プロデューサー)との信頼関係を構築。
そして、アイドルと一心同体のように相互に影響を及ぼしあうこととなります。


さて、そんなアイマスの作品の1つである「アイドルマスターシンデレラガールズ」では、現在ゲーム内で「第2回シンデレラガール選抜総選挙」という名の人気投票が行われています。
「上位5人のアイドルはユニットを組みCDデビュー」と発表されており、CVが決まっていないアイドル(2013年4月現在145名)が選出されれば、必然的にCV担当の声優を決めることになります。

そんなおり、CVが決まっていないアイドルの一人「アナスタシア」(ロシア人ハーフという設定) について、
ロシア人の声優ジェーニャさんが以前から「彼女の声を担当したい!」とツイートしており

そんな彼女の声をきき「応援したい」というファンが集まったのか、アナスタシアは中間発表で1位となりました。
このまま上位をキープし最終結果で5位以内となれば、CV担当を決めなければなりません。


これまでは、アイドルと担当声優との相互干渉は、CV担当が発表されてからのスタートでした。
しかし今回は、CV担当が決まる前から(本人の意思とは関係なく)干渉が始まりつつあり、それが中間発表の順位や、冒頭のエントリに書かれているプロダクション*1への支援などの形となって如実に表れています。


シンデレラガールズに登場するアイドルのCV担当決定方針について、アイドルマスター総合ディレクター石原章弘氏は以下のように語ります。


ユーザーの中に「キャラクターはこういう人」という 思い描いた像がもともと思い浮かんでいるので イメージ通りの声を探すところから始めている
(2013/04/12放送「めざましテレビ」より)

このままファンとの友好的な関係が続き、「アナスタシアの声はジェーニャさんだよね」という雰囲気が広まれば、実現する可能性は十分にあります。

それがいいか悪いかはともかく、アイマスの歴史上前例のない出来事ですので、どうなるかわくわくしながら見守りたいと思います。


(2013/04/29 02:25ごろ: ジェーニャさんが今回突然言い始めたのではなく、以前から言及していたことについて追記しました。)

2013/05/13 追記

アナスタシアが最終結果で2位となりTOP5入り。CVが付きCDデビューします。
今回、他の4人がいずれもCV決定済アイドルですので、オーディションとなれば1枠をめぐりすごい争いが繰り広げられるでしょう。
しかし、1枠なので、出来レースor完全指名という可能性も少なからず残されています。
いったいどうなるのか、目が離せません。

*1:一般的なネトゲでいう「ギルド」