モジュールアップデートを簡素化します

先々週対応した新暗号化ライブラリ版をインストーラにも適用したため、オンライン版のインストーラが例のVPS上においても動作するようになりました。

今後は、オンライン版インストーラのみに統一していくことにします。

当社のモジュールアップデートは、2種類の方法があります。

1つは、デスクトップのショートカットを起動すると表示するソフトウェアの更新ダイアログによるモジュールアップデートがあります。これは、同じバージョンのフレームワークを使用している場合に有効で、BOTの処理を更新するときなどに使用します。

もう1つは、インストーラからアップデートする方法で、これは未インストールのPCに対してインストールする場合や、フレームワークの更新がある場合は、こちらで行う必要があるため、fastBOTサイトでアップデートを通知していますが、なかなかアップデートが進んでいない場合は、前者の更新で強制的にインストーラの再インストールを促すことを行っています。

今後は、ソフトウェアの更新ダイアログがBOTのアップデート前に、オンラインインストーラの更新チェックを行い、更新があったときは以下の画面を表示するようにします。

上記画面でコンポーネントの更新を行うことで、インターネットから最新のモジュールに入れ替える作業をインストーラが行ってくれます。

今回はチケットぴあ自動購入のみ行っていますが、順次他のBOTも切り替えていきます。

暗号化ライブラリを移植しました。

当社が使用しているフレームワークに、新しい暗号化ライブラリの移植が成功しました。

移植に成功しても、KAGOYA CLOUD VPSで動かないと意味がないので早速動作確認をしました。

リモートデスクトップのIPアドレスがKAGOYA CLOUD VPSのものであることを以下の2つの画像で証明しています。現在リリースしているインストーラでは、ライセンス認証が出来なかったのですが、新しいフレームワークでは、ライセンス登録ができるようになりました。

AWSでも動かないようなので、来週中には全てのアプリケーション分を用意したいと思います。

今回移植した暗号化ライブラリは、既存の暗号化ライブラリよりも軽量という謳い文句がありますが、軽量≒高速(軽量だから高速である)というわけでもなく、以前のものも残す方が良いのか悩みますが、利用する側としては、利用できることの方が重要だと思うので、一気に変えていきます。

無題

あれやこれややっていたので追記が遅れたのだが、実は2日後には以下の回答が来ていた。

この言い分は、Windows OSについてはカスタマイズは一切していないよ!ということだ。

Windows OSのNDIS中間ドライバやもっと下位のドライバでブロックすることもできそうだが、上記のことがあるため、ルータでブロックしていることはほぼ間違いないだろう。

このようなケースが他にも考えられるため、自分的には意地でもOpenSSL以外の暗号化スイートを使用したいと考えていて、今はそこに全力投球している。

今は良さげな暗号化スイートをフレームワークに移植することを行っているのだが、その暗号化スイートはOpenSSL ver 1系に合わせたI/Fを用意している一方で、フレームワークはOpenSSL ver 3系のI/Fになっているため、こちらで合わせ込みをしなければならず、予想外に時間が掛かりそうな状況になっている。

ぴあの座席指定機能を追加して欲しいとか、TicketBookに対応して欲しいとか要望を頂いているのは認識しているが、直ぐの実現は難しい。

TicketBookは、去年の年末にサイト側が刷新されたので、アップデートしようとしていたのだが、ブラウザではなく通信データでリストック監視を行った途端にBOTだと判断されてカートにチケットが入らなくなる。これについて色々悩んでいたら風邪を引いてしまい、モチベーションが落ちてしまってほったらかし状態になっていた。

当社BOTは必ずブラウザと共存した作りにしているので、ブラウザの自動操作も駆使することで対応は可能だったとは思うのだが、モチベーションが下がってしまっては元も後もない。

脈絡とは全然関係無いのだが、問い合わせをもらうときに、「いつもお世話になっております」という文言が最初に入ることが多くなった。

実はこれ、俺からするとかなり違和感がある。

サブスクの商品であればまだ理解はできるが、売り切りの商品についてこれを言われても、契約書を交わしている訳でも無いわけで、こちらからすれば赤の他人から言われても違和感しかない。カスタマーサポートが存在する企業であれば、そこが一次受付するから、開発部署には問題の内容ぐらいしか届いてこないのが普通なのだが、当社は俺しかいないので仕方ないのかもしれないが、変えていきたい。

問題提起をしてくれるのはありがたい反面、只々動かないとしか書かれていると、これで何を判断しろって言うんだ?!と思う。ログや画面キャプチャーなどの証拠を提示してくれれば、こちらのことも考えてくれていると思える。

Google DriveやOne Driveにログや画面キャプチャーをアップロードさせておいて、そのリンクを問い合わせフォームに貼り付けてくれれば助かります。Driveにアップロードしたログは共有状態にしておくことを忘れずに。

KAGOYA CLOUD VPS

BOTを使う場合、自分の家の環境でIPBANになったら不便になるので、ProxyIPを使うか、VPSを使う選択をする場合も多いと思う。

最近、ユーザからインストーラが動かないという連絡があった。以前もこの問い合わせがあったときは、ITリテラシーが無いのだろうと決めつけてしまい、BOT利用自体をお断りすることがあったが、今回は詳細な事象を話してもらえたため、原因追及のために私自身が調査を行った。

当社のインストーラは2種類存在しており、インストーラ内に全てのモジュールを詰め込んであるものと、インストーラを起動すると、インターネットからモジュールをダウンロードするものがある。今回の事象は後者の方で、モジュールがダウンロードできないので、インストーラを動かすことができなかった。

最初は、ファイヤーウォールや受信の規則を弄れば良いのではと考えていたのだが、そこらを弄っても全然改善されない。

まず何が原因なのかを調べるため、VPSにWiresharkを入れて、通信の状況を監視したところ、そもそもデータがサーバに届いていないことが分かった。具体的には、サーバには送っているが、KAGOYAのLAN内で戻されていた。恐らくルータにブロックフィルターを仕掛けているのだろうと思い、問題の切り分けをするために、HTTP POSTデータ送信を行うだけのアプリを作り、暗号化ライブラリを変えて通信できるか確かめた。

当社が使っている暗号化ライブラリはOpenSSLを採用しており、インストーラもOpenSSLを使用している。これはOpenSourceであり且つアップデートが頻繁に行われているため、信頼性の高いものである。こちらを使った場合は、サーバとの通信が行えなかった。

もう一つはEdgeの暗号化ライブラリを使ったHTTP POSTデータ送信を使用したところ、問題無くサーバとの通信ができた。

暗号化ライブラリが関係しているのは、下記の第5層に位置している。恐らくKAGOYA VPSでは、LAN内のルータにて第5層のペイロードを見て、OpenSSLだと分かる何かで判断して、ブロックしているのだと思う。

BOTが扱っているのは第7層だが、ここは暗号化ライブラリによりデータが暗号化されているのでチェックすることが出来ない。そこでBOTが使用している暗号化ライブラリに着目して、BOT利用者を弾き出そうとしたという訳だ。

いつから使えなくなっているのかは分からない。少なくとも1回目の使えない報告があったのが2023/3/25なので、それより前から使えなくなっていたということだろう。

この対処の仕方が、一般的に考えてあり得ない対応だと思ったので、当方からKAGOYAに以下のように問い合わせてみた。

土日祝を除いた3営業日と考えると、18時は営業時間外なので11/14(火)までに連絡があるのか待ってみようと思う。

今回発覚した暗号化ライブラリ特有のペイロードでブロックしているということが分かり、こういう技術は、BOT対策として他でも行っているに違いない。

ブラウザと同じデータを送っているのに、処理でHTTP通信を行うとサーバ側で弾かれる理由の1つにこの件が該当するのだと思うと、もっと早く調べておけば良かったと少し後悔した。

当社BOTは全てOpenSSLを使用しているため、他の暗号化ライブラリに変更しようと実際に動き始めている。

サーバ運営側はBOT利用者を追い払いたいと思うだろうが、私はBOT利用者を推進する側なので、今回のことは正直むかついた。