たれながし.info

とあるITエンジニアの備忘録

OBS StudioにSwitch 2の音声を取り込めなかった件の解決メモ


はじめに

OBS Studioという映像をキャプチャしたり配信したりするためのPC用ソフトウェアがあります。
Switch 2とOBS Studioを接続すると、ゲーム画面と音声を録画したりネット配信することができるようになります。

先日、Switch 2を手に入れました。
しかしSwitch 1と同じ構成でSwitch 2とOBS Studioを接続しても、映像は取り込めるのに音声が取り込めませんでした。

接続構成

我が家のSwitch 2とOBS Studioの接続構成です。

ノートPCにUSBでHDMIキャプチャボードを接続し、Switch 2を接続しています。
Switch 2のHDMI出力には非純正の小型のドックを使っています。

原因について

Switch2の音声をOBS Studioに取り込めなかったのは、PCでマイクを無効にしていたことが原因でした。
マイクを有効にしたところ、事象は解決しました。

Switch 2にはマイクが内蔵されていて無効にできないっぽいです(Switch 1にはマイク搭載されてない)。
PCがSwitch 2をマイクと認識するためか?PCでマイクを有効にしておく必要があったようです。

マイクの有効化はWindowsの[設定] > [プライバシーとセキュリティ] > [マイク] > [マイクのアクセス]から行います。

映像キャプチャデバイスの音声設定

映像キャプチャデバイスの音声設定でもはまったのでメモしておきます。

カスタム音声デバイスが有効な場合

映像キャプチャデバイスでカスタム音声デバイスが有効な場合、音量等の設定は「映像キャプチャデバイス」で実施します。

カスタム音声デバイスが無効な場合

映像キャプチャデバイスでカスタム音声デバイスが無効な場合、音量等の設定は「マイク」で実施します。

この場合、OBS Studioの[設定] > [音声] > [マイク音声]にキャプチャボードのオーディオデバイスをあらかじめ指定する必要があります。

React Server Componentsの脆弱性(CVE-2025-55182)について調べたことのメモ

はじめに

2025年12月3日に、React Server Components(RSC)の脆弱性(CVE-2025-55182)が公開されました。
認証なしでリモートコード実行が可能ということで大きな話題になっています。

Reactは「WebサイトのUIを作成するライブラリ」程度の知識しか持っていなかったので、Reactやこの脆弱性について調べたことのメモです。
実際に脆弱なサイトを構築してPoCを実行して理解を深めることもしてみました。

ReactとReact Server Components(RSC)について

  • Reactは2013年にメタ社が公開したWebページのUIを構築するためのJavaScriptライブラリ
  • Reactにはいくつかの描画処理方式がある、主要なものは以下の通り
    • CSR(Client Side Rendering)
    • SSR(Server Side Rendering)
    • SSG(Static Site Generation)
    • RSC(React Server Components)
  • RSCではサーバー側で処理したコンポネントをシリアル化してクライアントに送信する

脆弱性(CVE-2025-55182)について

  • RSCのサーバー/クライアント間通信に使うflightプロトコルのデシリアライズ処理に検証不足があり脆弱性(CVE-2025-55182)に繋がっている
  • 脆弱なRSCを使用するWebアプリに細工したリクエストを送信すると、認証なしでリモートからコードが実行できる
  • Reactを使っていても、RSCを使っていなければ影響はない
  • Next.js等のRSCに依存するライブラリ/フレームワーク脆弱性の影響を受ける
    ※Next.jsでは処理の仕組みの1つApp RouterがRSCを使うため(もう1つのPage Routerでは使っていない)
  • CVSSv3は10.0、KEVにも2025年12月5日に掲載された

参考にした情報

検証用Webアプリの作成

Next.jsはデフォルトでRSCを利用するとのことなので、Next.jsでWebアプリを作成する。
Next.js等を使わずRSCネイティブでアプリを作るのは、ユーザーが沢山コードを書く必要があり大変らしい。
Next.jsのWebアプリの作り方はCopilotに聞きました。

構築環境

Windows 11 Pro

Webアプリの構築

1. Node.jsのインストール
https://nodejs.org/ja/download

> node -v
v24.11.1

2. Next.jsのインストールとWebアプリの起動
脆弱なバージョンを指定してNext.jsをインストールする
create-next-appは、各種テンプレートとともにNext.jsをインストールしてくれる

> npx create-next-app@16.0.6 my-app

> cd my-app
> npm run dev

3. Webアプリへアクセス
http://localhost:3000にブラウザでアクセスする
※my-app/appに作成されたテンプレートの内容が表示される


PoCの実行

PoCについて

脆弱性発見者が公開しているPoCを利用しました。
github.com

PoC環境の構築

PoCはNode.jsで動作させるように作成されている。

1. Node.js新規プロジェクト作成とパッケージインストール

> mkdir clients
> cd clients
> npm init -y
> npm install form-data

2. PoCのダウンロードと修正
PoCをダウンロードする

> curl -O https://raw.githubusercontent.com/lachlan2k/React2Shell-CVE-2025-55182-original-poc/refs/heads/main/01-submitted-poc.js

01-submitted-poc.jsの末尾コメントアウトを解除、Port番号を修正

修正前:// exploitNext('http://localhost:3003')
修正後:exploitNext('http://localhost:3000')

3. PoCの動作確認
PoCを実行

> node 01-submitted-poc.js

サーバー側のログを確認すると、"50"と出力される
これはPoCの13行目にある'console.log(7*7+1)'がサーバー上で実行されたため

OSINTサービスの個人的なメモ

はじめに

気に入ったOSINTサービス/ツールの個人的なメモです。
あれどこにあったかな?って思った時に参照するためのものです。追々追加していきたい。

OSINTサービス/ツール

Intelligence X「Multiple URLs Opener」

複数のURLを一括で開くためのサービス
https://intelx.io/tools?tab=urls

CompleteDNS

ドメインの履歴を収集しているサービス
https://completedns.com

リンク情報の整理

ブラウザに表示しているWebページのリンク先を整理してサイドバー風に表示してくれるブックマークレット
http://bookmarklet.web.fc2.com/bookmarklet_116.html

顔認識対応画像検索エンジン

顔認識対応の画像検索エンジンらしい、使ったことないのでどうなのかは知らん。
hxxps://lenso.ai
hxxps://pimeyes.com

飛行機と船舶の位置情報

Marine Traffic

船舶に登録が義務付けられているAIS(船舶自動識別装置)の信号を利用し船舶の位置を表示するサービス
https://www.marinetraffic.com

Sendmailのバナーに表示されるバージョン情報について調べた!(Sendmail Version on the Banner)

Sendmailのバナーに表示されるバージョン情報について調べてみた。


はじめに

Sendmailは、UnixLinuxで古くから使われているMTA(メール転送エージェント)です。

Sendmailのバナーには、バージョン情報が表示されます。
以下のようにスラッシュ(/)で区切られる形で、2つのバージョン情報が表示されます。

サーバーによって、表示される2つのバージョンが同じこともあれば、違う場合もあります。
これはどういうことなんだ?どっちを信じればいいんだ?と気になったので調べて見ました。

2つのバージョン情報が同じパターン
 Sendmail 8.15.2/8.15.22つのバージョン情報が異なるパターン
 Sendmail 8.16.1/8.14.7

結論

前半がソフトウェアのバージョン、後半がコンフィグのリビジョンレベルを意味するようです。

ソフトウェアのバージョンは、その名の通りソフトウェアのバージョンです。
"sendmail -d0.101"で調べることができます。

コンフィグのリビジョンレベルは、Sendmailのコンフィグファイル(sendmail.cf)の管理版数となります。

■バナーの確認
# curl -telnet://localhost:25
220 localhost.localdomain ESMTP Sendmail 8.16.1/8.16.1;

■ソフトウェアのバージョンの確認
# sendmail -d0.101
Version 8.16.1

■コンフィグのリビジョンレベルの確認
# grep DZ /etc/mail/sendmail.cf
DZ8.16.1

コンフィグのリビジョンレベルの説明は、sendmail.cfのmanに記載があります。
必ずしも"DZ8.16.1"といった表記とする必要は無いようですが、慣例でソフトウェアバージョンと同じ値を付ける場合が多いと思われます。

ソフトウェアのバージョン、コンフィグのリビジョンレベルが異なるケースは、コンフィグを引きついでソフトウェアをアップデートしたり、コンフィグを移植したりするとズレが発生すると思われます。

・man sendmail.cf
→Configuration File Revision Level Option	(DZNumber)

The configuration file revision level macro, Z, helps you track changes
that you make to the sendmail configuration file. Each time that you
make a change to the sendmail configuration file, you should also
change the value of this macro. Choose any format for the number that
you define. For example, if the sendmail configuration file is at
level 3.1, the following entry appears in the sendmail configuration
file: DZ3.1

A text string can also be used for this macro: DZversion_one


動作検証

コンフィグのリビジョンレベルを書き換えて、バナーの情報が変わるか動作検証しました。

検証環境

Sendmailをインストールし起動

# yum install sendmail
# systemctl start sendmail


バナーの確認
Sendmail 8.16.1/8.16.1 です。

# curl telnet://localhost:25
220 localhost.localdomain ESMTP Sendmail 8.16.1/8.16.1;


コンフィグのリビジョンレベルを "hogehoge" へ変更

# cd /etc/mail/
# cp -a sendmail.cf{,org}

# grep DZ sendmail.cf
DZ8.16.1

# sed -i 's/DZ8.16.1/DZhogehoge/g' sendmail.cf
# grep DZ sendmail.cf
DZhogehoge


Sendmailを再起動しバナーを確認
→"Sendmail 8.16.1/hogehoge"に変わったことが確認できた

# systemctl restart sendmail

# curl telnet://localhost:25
220 localhost.localdomain ESMTP Sendmail 8.16.1/hogehoge;


sendmail.cfを直接書き換えてはいけないとされています。
 本来はsendmail.mcを書き換えてからコマンドでsendmail.cfを生成する必要がある

Install Node.js on RHEL9

はじめに

RHEL9(Red Hat Enterprise Linux 9)に、Node.jsをインストールした際のメモです。
RHELの公式ページを参照しました。

developers.redhat.com

インストール

利用可能なモジュールリストを確認

# dnf module list nodejs
…
Red Hat Enterprise Linux 9 for x86_64 - AppStream (RPMs)
Name             Stream           Profiles                                        Summary
nodejs           18               common [d], development, minimal, s2i           Javascript runtime
nodejs           20               common [d], development, minimal, s2i           Javascript runtime
nodejs           22               common [d], development, minimal, s2i           Javascript runtime


利用するモジュールを有効化
※今回はv20を利用する

# dnf module enable nodejs:20


再度モジュールリストを確認
→v20がenableになっている

# dnf module list nodejs
…
Red Hat Enterprise Linux 9 for x86_64 - AppStream (RPMs)
Name             Stream           Profiles                                        Summary
nodejs           18               common [d], development, minimal, s2i           Javascript runtime
nodejs           20 [e]           common [d], development, minimal, s2i           Javascript runtime
nodejs           22               common [d], development, minimal, s2i           Javascript runtime
ヒント: [d]efault, [e]nabled, [x]disabled, [i]nstalled


モジュールをインストール

# dnf install nodejs
…
==============================================================================================================
 パッケージ  Arch   バージョン                                         リポジトリー                     サイズ
==============================================================================================================
インストール:
 nodejs      x86_64 1:20.18.2-1.module+el9.5.0+22758+4ad2c198          rhel-9-for-x86_64-appstream-rpms  14 M
弱い依存関係のインストール:
 nodejs-docs noarch 1:20.18.2-1.module+el9.5.0+22758+4ad2c198          rhel-9-for-x86_64-appstream-rpms 8.5 M
 nodejs-full-i18n
             x86_64 1:20.18.2-1.module+el9.5.0+22758+4ad2c198          rhel-9-for-x86_64-appstream-rpms 8.4 M
 npm         x86_64 1:10.8.2-1.20.18.2.1.module+el9.5.0+22758+4ad2c198 rhel-9-for-x86_64-appstream-rpms 2.3 M

トランザクションの概要
==============================================================================================================
インストール  4 パッケージ
…


バージョン確認

# node -v
v20.18.2

動作確認

テスト用プログラムの作成

# vi hello-heep.js
const http = require('node:http');
const hostname = process.argv[2] || '127.0.0.1';
const port = 3000;

const server = http.createServer((req, res) => {
  res.statusCode = 200;
  res.setHeader('Content-Type', 'text/plain');
  res.end('Hello World\n');
});

server.listen(port, hostname, () => {
  console.log(`Server running at http://${hostname}:${port}/`);
});


ファイアウォールを開ける

# firewall-cmd --add-port=3000/tcp
# firewall-cmd --add-port=3000/tcp --permanent


プログラム起動

# node hello-http.js  10.2.153.95
Server running at http://10.2.153.95:3000/


ブラウザで接続

Install Apache Tomcat 11 on RHEL9


はじめに

検証目的でRed Hat Enterprise Linux 9にApache Tomcat 11をインストールしたので、その手順のメモです。
以下のページを参考にしました。
www.tecmint.com

Apache Tomcat 11のインストール

RHEL9.5にTomcat 11.0.2をインストールします。

環境について

OSバージョンはRHEL9.5です。SELinuxは無効です。

# cat /etc/os-release
NAME="Red Hat Enterprise Linux"
VERSION="9.5 (Plow)"

# getenforce
Disabled

Javaのインストール

Tomcat 11ではJava 17以上が必要なので、今回はOpenJDK 17をインストールします。

# yum install java-17-openjdk

# java -version
openjdk version "17.0.14" 2025-01-21 LTS
OpenJDK Runtime Environment (Red_Hat-17.0.14.0.7-1) (build 17.0.14+7-LTS)
OpenJDK 64-Bit Server VM (Red_Hat-17.0.14.0.7-1) (build 17.0.14+7-LTS, mixed mode, sharing)

参考)TomcatJavaバージョンの対応表
Apache Tomcat® - Which Version Do I Want?

参考)RHELが提供するOpenJDKのバージョン情報
OpenJDK のライフサイクルおよびサポートポリシー - Red Hat Customer Portal

Tomcat 11のインストール

Tomcat 11.0.2をDL&解凍する。

# curl -O https://archive.apache.org/dist/tomcat/tomcat-11/v11.0.2/bin/apache-tomcat-11.0.2.tar.gz

# tar xzf apache-tomcat-11.0.2.tar.gz
# ls -l
drwxr-xr-x  9 root root     4096  3月 23 00:23 apache-tomcat-11.0.2
-rw-r--r--  1 root root 13671357  3月 23 00:20 apache-tomcat-11.0.2.tar.gz


システムアカウント tomcatを作成、ディレクトリ所有者を変更、/usr/local/tomcat11に配置にする。

# useradd -r tomcat
※-rは、システムアカウントのオプション

# chown -R tomcat:tomcat apache-tomcat-11.0.2
# mv apache-tomcat-11.0.2 /usr/local/tomcat11
# ls -ld /usr/local/tomcat11
drwxr-xr-x 9 tomcat tomcat 4096  3月 23 00:23 /usr/local/tomcat11


Unitファイルを作成する。

# vi /etc/systemd/system/tomcat.service
[Unit]
Description=Apache Tomcat Server
After=syslog.target network.target

[Service]
Type=forking
User=tomcat
Group=tomcat

Environment=CATALINA_PID=/usr/local/tomcat11/temp/tomcat.pid
Environment=CATALINA_HOME=/usr/local/tomcat11
Environment=CATALINA_BASE=/usr/local/tomcat11

ExecStart=/usr/local/tomcat11/bin/catalina.sh start
ExecStop=/usr/local/tomcat11/bin/catalina.sh stop

RestartSec=10
Restart=always
[Install]
WantedBy=multi-user.target


Unitファイルの変更を反映し、Tomcatを起動

# systemctl daemon-reload

# systemctl start tomcat.service
# systemctl status tomcat.service
● tomcat.service - Apache Tomcat Server
     Loaded: loaded (/etc/systemd/system/tomcat.service; disabled; preset: disabled)
     Active: active (running) since Sun 2025-03-23 00:34:58 JST; 5s ago


8080/TCPポートを開ける

# firewall-cmd --zone=public --add-port=8080/tcp --permanent
# firewall-cmd --zone=public --add-port=8080/tcp

動作確認

ブラウザでアクセスして動作確認する。

2025年のパッチチューズデーを計算する(Patch Tuesday)

はじめに

パッチチューズデーを計算するプログラムを以前作成しました。
それを使って2025年のパッチチューズデーを計算します。

tarenagashi.hatenablog.jp

計算してみる

パッチチューズデーの仕様

パッチチューズデーの仕様は以下の通りです。

  • パッチチュズデーは「米国太平洋標準時(UTC-8)の毎月第2火曜日の午前10時」
  • 日本時間(UTC+9)では「第2もしくは第3水曜日の午前2時もしくは午前3時」
  • 日本時間(UTC+9)で第2水曜日となるのか、第3水曜日となるのかはその月による
  • 日本時間(UTC+9)で午前2時となるのかは、アメリカがサマータイムなのかによる
  • 現地時間の「3月第2日曜日午前2時〜11月第1日曜日午前2時」がサマータイムでに当たり1時間早まる

プログラム

import datetime, calendar, pytz

def get_day_of_nth_dow(year, month, nth=2, dow=1):

    first_dow, n = calendar.monthrange(year, month)
    day = 7 * (nth - 1) + (dow - first_dow) % 7 + 1
    
    return day

if __name__ == '__main__':

    year=2025 # 2025年

    print('-' * 49)
    title = '|' + ' ' * 4 + '太平洋時間(PST)' + ' ' * 4 + \
            '|' + ' ' * 5 + '日本時間(JST)' + ' ' * 5 + '|'     
    print(title)
    print('-' * 49)

    for month in range(1, 13):

        # 第2火曜日の日付の取得
        day = get_day_of_nth_dow(year, month)
        naive_pst = datetime.datetime(year, month, day, 10)

        # 太平洋標準時(PST)の計算
        pst = pytz.timezone('US/Pacific')
        aware_pst = pst.localize(naive_pst)

        # 日本標準時(JST)の計算
        jst = pytz.timezone('Asia/Tokyo')
        aware_jst = aware_pst.astimezone(jst)

        print("| {} | {} |".format(aware_pst.strftime("%Y/%m/%d(%a) %H:%M"), aware_jst.strftime("%Y/%m/%d(%a) %H:%M")))
 
    print('-' * 49)

結果

-------------------------------------------------
|    太平洋時間(PST)    |     日本時間(JST)     |
-------------------------------------------------
| 2025/01/14(Tue) 10:00 | 2025/01/15(Wed) 03:00 |
| 2025/02/11(Tue) 10:00 | 2025/02/12(Wed) 03:00 |
| 2025/03/11(Tue) 10:00 | 2025/03/12(Wed) 02:00 |
| 2025/04/08(Tue) 10:00 | 2025/04/09(Wed) 02:00 |
| 2025/05/13(Tue) 10:00 | 2025/05/14(Wed) 02:00 |
| 2025/06/10(Tue) 10:00 | 2025/06/11(Wed) 02:00 |
| 2025/07/08(Tue) 10:00 | 2025/07/09(Wed) 02:00 |
| 2025/08/12(Tue) 10:00 | 2025/08/13(Wed) 02:00 |
| 2025/09/09(Tue) 10:00 | 2025/09/10(Wed) 02:00 |
| 2025/10/14(Tue) 10:00 | 2025/10/15(Wed) 02:00 |
| 2025/11/11(Tue) 10:00 | 2025/11/12(Wed) 03:00 |
| 2025/12/09(Tue) 10:00 | 2025/12/10(Wed) 03:00 |
-------------------------------------------------

まとめ

ということで、2025年のパッチチューズデーを計算しました。
日本では、初回は第3水曜日の1/15(水) 午前3時となります。