TP-Linkルータは本当に危険?真実を探る

はじめに

Youtubeでは、TP-LINKのルータに関して、極めて出どころの怪しい情報が飛び交っているようです。聞いた感じだと、

  • パケットを中国に転送している
  • VPNが自動切断される

このようなところだと思います。しかし、これは極めて怪しいと言わざるを得ません。私が考えるに、パケットを中国に転送しているというのはダウトだと思います。それは、分析だけで手間すぎるし、そもそも、中国へのルートが酷い輻輳を起こすのが明らかだからです。

VPNは中国国内だとかなり規制されているので、代表的なポートが塞がれている可能性はなくはないです。日本国内での利用だと甚だ迷惑ですが。

いくつかYouTubeの動画などを確認しましたが、危険説は米国政府の発表などが全てで、ソースコードのリバースなど客観的な根拠は見当たりません。せいぜいが、国家情報法ですね。しかし、そういう法律があるというのは行われている根拠にはなりません。

TP-Linkとは

「TP-Link」は、ネットワーク機器の製造や販売などを行っている企業です。1996年に設立され、現在は1万円以下という低価格で購入できるWi-FiルーターやWebカメラなどが人気を博し、世界170か国以上で10億人を超えるユーザーにネットワーク関連製品を提供しています。世界44か国に現地法人を設置しており、日本には2015年に子会社である「ティーピーリンクジャパン株式会社」を設立しています。

実現性の検討

VPNの自動切断は一応、実現可能です。しかし、VPNかどうかの判別は正直、難しいのでこれも眉に唾を100リットルくらい塗るレベルですね。ただ、それ以上に私が怪しんでいるのはルータのファームウェアをばらしたレポートが一つもないことです。というか、ルータに問題があり得るなら、ファームウェアをばらせば一発です。故に、私はそのようなレポートがない以上、本件自体が虚偽と考えざるを得ません。

TP-LINKのコード

実は、TP-LINKのコードの多くは、GPLのコードです。したがって、多くの機種でコードが公開されています。もちろん、リビルドにはそれ相応の手間がかかるとは思います。そして、リバースエンジニアリングした方もいらっしゃいます。以下の記事でリバースエンジニアリングの例を見ることができますが、ロジックボムや隠されたゲートが発見されたという情報は確認できていません。

Reverse engineering my router’s firmware with binwalk

また、GPL上、ルータに書き込まれているバイナリとソースコードに不整合がある場合、GPL違反に問われるリスクがあります。そのようなリスクを冒して、トロイの木馬を埋め込むのはかなりハードルが上がると言わざるを得ません。

GPLは、ソフトウェアの自由な利用、改変、配布を保障するライセンスですが、その条件を遵守しない場合、法的な問題が発生することがあります。具体的には、GPLに基づくソースコードを使用しているにもかかわらず、ファームウェアにその変更点やソースコードを公開しない場合、著作権侵害として訴えられるリスクがあります。

検討

当然、本件が事実であると仮定した動画はすべて、疑いの目で見ることになります。私個人としては、適切なソースを引用していない場合、このような動画はすべて通報対象としています。

家庭用ルータの脆弱性

家庭用のルータの場合、特にUPnP周りが脆弱になることは比較的多いです。ネットワーク経由のゲーミングではポート開放が前提になることがあり、それがどのように設定されているかによっては致命的な脆弱性を実装するリスクがあります。

UPnP (Universal Plug and Play)とは

UPnP(Universal Plug and Play)は、ネットワークに接続されている機器同士が自動的に通信し、必要な設定を自動で行うための技術です。この技術により、ユーザーは手動で設定を行う手間を省くことができます。特に、ネットワーク経由のゲーミングやストリーミングサービスでは、UPnPが重要な役割を果たします。この種のゲートウェイ機器では、UPnPによるポートの自動開閉が定義されており、必要に応じてポートが自動開閉されます。

しかし、その利便性の反面、UPnPはセキュリティ上の脆弱性を抱えることが多く、適切に設定されていない場合や脆弱な実装がされている場合、外部からの不正アクセスのリスクが高まります。家庭用ルーターにおいても、UPnP機能の脆弱性がしばしば指摘されています。

監視とロギング

本来、このような問題の対処には監視とロギングが必要ですが、技術者以外にはその判断が困難です。家庭用ルータでsyslog転送などを持っているものはほとんど見受けられません。

終わりに向かって

個人的には、生成AIなどでこのようなスキルを埋めることができないかと思いますが、現状では生成AIの必要な負荷と家庭用のルータに利用されるプロセサのスペックを勘案すると、難しいと言わざるを得ないですね。

Delta Lakeの楽観的排他制御:ACID特性の詳細と実現方法

仕事で、Microsoft Fabric絡みのところを調べていました。

基本、Fabricの中ではApache Sparkなどが動いていることは判っていたので、Delta LakeでACID特性が実現されているというのもなんとなくわかっていました。では、どのようにしてACID特性が実現されているのかというところには関心がありました。この辺に関して触れられているのは以下のQiita上の記事です。

https://qiita.com/toshimitsuk/items/5dac76dddfe921cb8a47

そして、上記記事の次のところに着目しました。

Delta Lakeのソースコード (https://github.com/delta-io/delta) から、Delta Lakeの楽観的排他制御の仕組みを見ていきます。なお、ここではUpsertを対象に楽観的排他制御の仕組みを見ていきます。(再掲)

なるほど、楽観的排他制御かと。 では、楽観的排他制御とはなにかということです。

悲観的排他制御

これと対照的な概念が悲観的排他制御です。 悲観的排他制御とは所謂ロックによって排他制御を実現します。

こちらの方がよく知られているでしょう。いわゆるUpsertの場合において考えます。Upsertは排他制御がよくわかるところです、Upsertを仮に選択と条件分岐と更新と追加の組み合わせで考えます。

  1. 対象キーでレコードが存在するかどうかを確認する
  2. もし、レコードが存在すれば更新する
  3. レコードが存在しなければ追加する

これをそのまま実装してしまうと、1.と2.の間に割り込まれてしまうと、その間に重複するレコードが作成されてしまうリスクが発生します。結果的に、3.は正しく、Primary Keyなどの処理が実装されていればエラーになります。

Upsertであれば、悲観的排他制御であれば、1.のタイミングで対象となる表などにはロックが作られ、割り込み処理は一般的には待たされます。結果として、Upsertは完遂できます。仮に、待たされた方が自動連番などでキーを発生させていれば、その後により後のキーが発行されて正常に終了するでしょう。

楽観的排他制御

では、これが楽観的排他制御ではどうなるでしょうか? 楽観的排他制御ではロックではなく、更新の検出により処理します。つまり、処理する前に、割り込まれたことを検出して処理をします。 つまり、なぜ楽観的なのかというと、滅多に抵触する処理は行われないはずという仮定があります。 このあたりの詳しい話については以下の記事も参考にできます。

https://qiita.com/NagaokaKenichi/items/73040df85b7bd4e9ecfc

  1. 検証: 最初にレコードの現在の状態を取得し、その状態を記録します
  2. 更新の準備: データを更新する準備をします
  3. 更新の試行: 更新を試みますが、その際に他のトランザクションが同じレコードを変更していないかを確認します
  4. 競合の対処: 他のトランザクションが変更していた場合は、更新を再試行するか、エラーを返します

パフォーマンスと課題

さて、悲観的排他制御と楽観的排他制御の差はどこにあるのか? 一つのポイントはパフォーマンスです。悲観的排他制御はロックを行うため、そこがパフォーマンス上のボトルネックになります。では、楽観的排他制御は銀の弾丸か? そんなことはありません。銀の弾丸はどこにも存在しないのです。

楽観的排他制御の弱点は、更新の検出にあります。これが崩れればすべてがお釈迦です。そして、楽観的排他制御のポイントは、楽観的、競合することはそうそう起きないだろうにあります。競合がかなりの頻度で起きるとすればどうでしょうか? ほとんどの場合で、何らかの回避動作が必要になります。更に、その回避動作は正しいのかの検証も極めて重要です。

結論から言うと、楽観的排他制御は難易度が高いです。その意味ではロックして、競合処理を起こさないようにする悲観的排他制御の方がシステム的な難易度は低いです。パフォーマンスの劣化は大きな課題ですが。

テキストエンコーダーとベクトル演算が引き起こすプロンプト混在の謎

スタジオ真榊のAIイラスト術解説になぜ、複数キャラクターのプロンプトが混じってしまうのかというのがあるので、私なりに解説を試みてみましょう。

まず、画像生成AIのプロセスについて考える必要があります。代表的な、画像生成AIであるStable DiffusionについてはDeep Learning 論文 Advent Calendar 2022に参加された、omiitaさんの表した、「世界に衝撃を与えた画像生成AI「Stable Diffusion」を徹底解説!」があるのでこれを下敷きにします。

Stable DiffusionはText Encoder、拡散モデル、VAEというパーツで成り立っています。基本的にはプロンプトを解析する、Text Encoder、画像生成に重要な役割を担う拡散モデル(U-Net)を考えます。VAEは拡散モデルのはらんでいる問題点の解決には重要ですが、あとで考えても構わないと思います。

まず、「複数キャラクターのプロンプトが混じってしまう」要因には、Text Encoderが大いに関わっています。Stable DiffusionではText EncoderにCLIPという手法を使っていますが、これの役目はテキストをベクトルに変換することです。まず、試みに、”(1 girl, blue hair color), (1 boy, red hair color)”というプロンプトを考えます。

“()”は通常、Stable Diffusionでは、重みづけ以上の意味を持ちえません。故に、見た目ではグループ化のように見えますが、Stable Diffusionでは重みづけ以上の意味はありません。さて、ベクトル表現とはなんでしょうか? これは分散表現と大いに関係があります。

例えば、Kingという言葉を分散表現でとらえるとき、このような考え方ができます。King→男性の統治者、そうすると男性という概念と統治者という概念で表現できます。簡単に表そうとすれば(1,1)というベクトルでしょうか。この場合、最初の次元が例えば男性という概念、統治者というのが2次元目とします。

さて、女王と言うものを考えるためにベクトルの次元を増やしましょう。2次元目として女性という概念を加えます。この場合、先ほどの例は(1,0,1)というベクトルで表現できるかもしれません。昔、Word2vecが大流行りしたときに、王-男性+女性=女王というサンプルが多く見られました。これは以下の計算で、この例に当てはめられます。

(1,0,1)-(1,0,0)+(0,1,0)=(0,1,1)

ここまで、考えると、なぜプロンプトが混じるのかに答えが見えてきます。理由はベクトルの計算において、混じってしまうからです。先ほど、述べたように、()はStable Diffusionにおいて、重み以上の意味はありません。従って、書いたつもりになっていても単にベクトル演算の押し合いへし合いでかき回されているだけになります。

では解決策はどうするのか、何とかして計算を分離すればいいとなります。例えば、Latent Coupleなどでは、領域を分割して、そこに独立してText EncodingやU-Netを構築します。この辺は「複数キャラクターを分けて生成するLatent coupleの改良版!(Attention Couple)」あたりの解説を読むのが適切です。

以上、なぜ、プロンプトが混じるのかを解説してきました。

なぜ、VAEは特に説明しなかったのか? それは、基本的には拡散モデルの計算量を削減するための仕組みであり、実際上、VAEは画像の仕上がり具合には大きな影響がありますが、特に、最近では、VAEはモデルに組み込まれているものをそのまま使うことが多く、SD 1.5時代のように色味とかを考えてVAEを案じることがほぼ見られなくなっているため説明を省略しました。

2025年に廃止されるAzureサービス:移行先と最適な代替案

2025年に廃止になる、Azure関係のサービスは以下のような感じです。

2025/1/6

Microsoft Genomics

2025/3/31

Visual Studio App Center

2025/6/30

SAP HANA Large Instances

2025/9/30

Azure Database for Maria DB
Azure Basic Load Balancer
Azure HPC Cache
Azure Remote Rendering
Azure Service Map
Azure SQL Edge
Azure Unmanaged Disks
Azure vFXT

時間が限られているので難しいものもありますが、わかる範囲で考えていきます。SAP HANA Large Instancesは時間が限られていますが、Azureのサポートされているインスタンスサイズへの移行が考えられるでしょう。その意味では、テストが課題ですが比較的可能な範囲かなと思います。

Azure Database for Maria DBはだいぶ前からアナウンスがかかってましたし、恐らく、Azure Database for MySQLが考えられるでしょう。DDLなどのテストは必須ですが、他のオプションよりは考えられるでしょう。

Azure Remote RenderingはHololens2とWindows 10に向けた、レンダリングソリューションなので、実質、Windows 10のMRがリタイアしてしまえば存在意義を失うのは確かです。

Azure SQL Edgeは地味に面倒かもしれないです。まず、状況によるといったところです。SQL Serverは検討され得ますが、x64のみのサポートなのでエッジデバイスでARMの場合には検討対象から外れます。その場合、SQLiteなどを考慮できますが、クラウドとかにミラーリングが発生するならば厄介です。その場合、エッジデバイス内はmemcachedとかにして、クエリをキャッシュするという戦略の方がいいかもしれないです。

考えられる範囲でまとめてみました。

LLMの未来: スケーリング則の限界と効率化の新アプローチ

今、LLMは一つの岐路にあると思っている、現状の認識としてはスケーリング則に限界が見受けられること。スケーリング即とはモデルの大規模化によって、モデルの精度、アウトプットの品質が高まるという経験則を指す。しかし、スケーリング即に現状、限界が見えていて、モデルの大規模化が必ずしもアウトプットの深化に結び付かない例が観測されている。

AIの天井が見えてきた日:スケール則の限界と新時代の幕開け

最近の事例から、私は今後の有望な方向性として二つのアプローチを見出しています。

MoE (Mixture of Experts):比較的歴史の長い発想で、Gradient Boostingなどもその考え方と考えられます。複数のモデルを組み合わせ、それぞれに重み付けを行うことで高精度なモデルを構築する手法です。

BitNet:比較的新しい考え方で、ニューラルネットワークは発火しているか否かという状態を表すため、ビットレンジを極限まで圧縮できるはずという理論に基づきます。このアプローチでは、計算リソースの使用を大幅に削減することが可能です。

これまでは、モデルの大規模化競争が主流でしたが、これは妥当な方向性でしょうか。ビッグプレイヤーは結果的に原子力発電にまで進んでいますが、これがよい方向性だとは思えません。したがって、モデルの効率化が今後のゲームチェンジャーとなり得ると考えています。

暴言の坩堝と化したX:その背後にあるもの

イーロン・マスクが最近このようなことを言っています:

XユーザーのElon Muskさん: 「Please post a bit more positive, beautiful or informative content on this platform」 / Twitter

しかし、以下の発言も彼のものです:

XユーザーのElon Muskさん: 「𝕏 is the PvP of social media」 / Twitter

イーロン・マスクがTwitterを買収し、私物化してPvP(プレイヤー対プレイヤー)ソーシャルメディアに変えたのは周知の事実です。なぜこのようなことが起きたのでしょうか?

単純な理由があります。H-1Bビザを擁護したからです。アメリカのIT業界は、H-1Bビザで入国してくる海外の優秀な労働者に大きく依存しています。H-1Bビザがなくなると、業界にとっては死活問題となります。しかし、PvPソーシャルメディアとなった「𝕏」上で、イーロン・マスクのような経営者は多数派ではありません。そして、マスクが焚きつけた対立感情により、海外からの安価な労働者の流入を止めたいと考える人が増えています。

結果、「𝕏」は暴言の坩堝と化しました。しかし、その引き金を引いたのはイーロン・マスク本人であることを忘れてはなりません。

さらにウィットに富んだ良い返しを紹介します:

Xユーザーのdownshift.eth (on Warpcast)さん: 「@elonmusk Please write an algorithm that promotes more positive, beautiful or informative content on this platform」 / Twitter

日本では良い言葉がある。「人を呪わば穴二つ」

Apple Cardの性別バイアス問題とAI倫理

https://wired.jp/2019/11/22/the-apple-card-didnt-see-genderand-thats-the-problem で記されている古い問題ではあるが、今にもつながる問題を提起している。たしか、記憶してる限りだと、Apple Cardの極度額がある夫婦で夫と妻とで極端な差があったので問題になったはずです。同じ家計の夫婦であれば、リスクはほぼ同じになるはずが、そうなっていなかったというので問題になったはずです。

そして、これが性別を与信モデルに含んでいれば、ある種単純だったんですが、この事業では性別を見ていなかったのです。したがって、逆に、性別で差別をしていないという立証が困難になりました。

性別に限りませんが、ある変数が別の変数に関連しているのはよくある話です。例えば、今回の話でならば、女性の身長の平均が男性のそれより低いというのは、事実であり、身長というフィールドがあったならば性別を書いているのと同じことです。

そして、OECD AI五原則と言うルールがあります。

1. AIは持続可能な成長や開発、幸福促進に利益をもたらすべき。
(以下省略)

また、個人情報についてOECDには以下の八原則があります。

1. 個人データの収集目的を明確にし、データ利用は収集目的に合致するべきである。
(以下省略)

この二つを鑑みると、モデルを作るにあたっては収集目的に見合ったデータを集めモデルを作るべきとなります。
つまり、与信であれば、貸し倒れ等のリスクを見るのに、見合った項目によりモデルを作るべきということになります。

従って、これらの原則を援用すれば、適当にデータセットを作って、後はStep-wiseを含め機械に変数選択をやらせてなんとなく、精度高めのモデルできましたはOECDの各種原則に従ってるかと考えればかなり微妙となります。

実際、産総研の高木さんなんかは、OECDの原則に照らせば、こういう安易なモデルはもってのほかと考えているのは、Twitterでの発言を考えればわかる感じです。

LLM技術の革新とその課題

https://gigazine.net/news/20241224-openai-gpt5-orion-delays/ でGPT-5が苦戦中というのが出ているが。

僕の理解では、現状のLLMは古典的な自然言語処理では字句解析、構文解析、意味解析と下から順に階層的に処理して最終的にある問題の回答を求めようとしていたのを、LLMの隠れ層に中間的な工程を委ねていると思っている。古典的な自然言語処理がうまくいかなかったのは階層的な処理だと、例えば字句解析が90%の精度で、構文解析が80%の精度だと仮定すると、構文解析のところで実際の精度は72%になる。そして、工程を経るごとに精度は下がり続け決して上がることはない。

故に実際の問題のところに至るまでに実用的なラインを割り込んでしまう、実際、LLMの登極前の時点で、字句解析、構文解析、意味解析を実用的な精度できちんとやり切っているシステムを私は聞いたことがない。多くの場合は、Eliza的なパターンマッチングなどで動いていたと思う。


LLMはEnd to endで入力されたものと、出力とを完全に結びつけることで初めて、一つのブレイクスルーを得たと思う。途中を隠れ層に押し込むことで、精度低下を不可視化したと思う。勿論、技術的には活性化関数などや、もちろん計算機の進化によって、深層学習が実用になったこと、そして、Attention機構のようにRNN的な成果を実用的なパフォーマンスで得られるようになったことが大きい。

しかし、根本的には、人間はLLM内で何が起きているかを理解できていないし、結果的にフレーム問題なども前進したかどうかすらわからない。この辺に今のLLMを考える難しさがある。

重みが跳ね上がる:Fooocusのバグ解析

最近、Fooocusでもa1111と同じバグがあることに気づきました。この問題は、patch_clip.py内のpatched_encode_token_weightsの実装に起因しています。

z = z * (original_mean / new_mean)

上記のコードで、時折 new_mean が非常に小さい値を取るため、重みが跳ね上がり、正常な描画ができなくなっています。

実際に確認された値は以下の通りです:

original mean0.0004
new mean3.7944e-05

この場合、z は約10.54倍されることになり、結果として描画が大きく乱れる可能性があります。

以下の画像は、実際に乱れた描画結果の一例です:

GitHubのissueにもこの不具合を報告しましたが、Fooocus の issues は現在あまり動いていないようです。open な issue が積み上がる一方なので、自分でフォークした mashb1t 版のベースで対応を進める予定です。ただし、z の計算ロジックの適切な修正方法についてはまだ結論が出ていません。

元々のコードの出所はこちらです:Stable Diffusion XLで生成画像の破綻が起きる問題の解析と対策

AWS S3を悪用したLedger詐欺の解析

Ledgerなるおそらくウォレットを騙る、メールが来ました。Ledger Data Breachなるタイトルでアカウントの確認依頼になっていますが、ログイン先と主張しているアドレスがAmazon S3のアドレスでそもそも、私はLedgerなるサービスのアカウントは持っていないので十中十、フィッシングでしょう。

怪しいので、Windows Sandboxを使用し、メールで参照しているAWS S3のアドレスからダウンロードしてみたところ、中身は https://ledgerprotecthub.com/ にリダイレクトしていることがわかりました。 そして、このドメインをwhoisしてみたところ、以下のような内容でした。

Domain Name: LEDGERPROTECTHUB.COM
Registry Domain ID: 2935890219_DOMAIN_COM-VRSN
Registrar WHOIS Server: whois.registrar.amazon.com
Registrar URL: http://registrar.amazon.com
Updated Date: 2024-11-21T07:05:15Z
Creation Date: 2024-11-20T21:58:13Z
Registry Expiry Date: 2025-11-20T21:58:13Z
Registrar: Amazon Registrar, Inc.
Registrar IANA ID: 468
Registrar Abuse Contact Email: trustandsafety@support.aws.com
Registrar Abuse Contact Phone: +1.2024422253
Domain Status: ok https://icann.org/epp#ok
Name Server: SARAH.NS.CLOUDFLARE.COM
Name Server: YADIEL.NS.CLOUDFLARE.COM
DNSSEC: unsigned
URL of the ICANN Whois
Inaccuracy Complaint Form: https://www.icann.org/wicf/
>>> Last update of whois database: 2024-11-21T11:57:21Z <<<

まず、真正のドメインと考える理由はゼロです。RegistrarをAmazon Registrarにして、連絡先などを伏せている時点で真っ黒です。

https://ledgerprotecthub.comはWindows Sandbox上から、wgetを使ってアクセスしてみたところ、403ではじかれたので、Windows Sandboxから仕方なくEdgeでアクセスしてみたところ、少なくとも、24語のセキュリティワードを要求しているページと確認が取れたので、黒と判断しました。