当社が使用しているフレームワークに、新しい暗号化ライブラリの移植が成功しました。
移植に成功しても、KAGOYA CLOUD VPSで動かないと意味がないので早速動作確認をしました。
リモートデスクトップのIPアドレスがKAGOYA CLOUD VPSのものであることを以下の２つの画像で証明しています。現在リリースしているインストーラでは、ライセンス認証が出来なかったのですが、新しいフレームワークでは、ライセンス登録ができるようになりました。
AWSでも動かないようなので、来週中には全てのアプリケーション分を用意したいと思います。
今回移植した暗号化ライブラリは、既存の暗号化ライブラリよりも軽量という謳い文句がありますが、軽量≒高速（軽量だから高速である）というわけでもなく、以前のものも残す方が良いのか悩みますが、利用する側としては、利用できることの方が重要だと思うので、一気に変えていきます。
あれやこれややっていたので追記が遅れたのだが、実は２日後には以下の回答が来ていた。
この言い分は、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にアップロードしたログは共有状態にしておくことを忘れずに。
BOTを使う場合、自分の家の環境でIPBANになったら不便になるので、ProxyIPを使うか、VPSを使う選択をする場合も多いと思う。
最近、ユーザからインストーラが動かないという連絡があった。以前もこの問い合わせがあったときは、ITリテラシーが無いのだろうと決めつけてしまい、BOT利用自体をお断りすることがあったが、今回は詳細な事象を話してもらえたため、原因追及のために私自身が調査を行った。
当社のインストーラは２種類存在しており、インストーラ内に全てのモジュールを詰め込んであるものと、インストーラを起動すると、インターネットからモジュールをダウンロードするものがある。今回の事象は後者の方で、モジュールがダウンロードできないので、インストーラを動かすことができなかった。
最初は、ファイヤーウォールや受信の規則を弄れば良いのではと考えていたのだが、そこらを弄っても全然改善されない。
まず何が原因なのかを調べるため、VPSにWiresharkを入れて、通信の状況を監視したところ、そもそもデータがサーバに届いていないことが分かった。具体的には、サーバには送っているが、KAGOYAのLAN内で戻されていた。恐らくルータにブロックフィルターを仕掛けているのだろうと思い、問題の切り分けをするために、HTTP POSTデータ送信を行うだけのアプリを作り、暗号化ライブラリを変えて通信できるか確かめた。
当社が使っている暗号化ライブラリはOpenSSLを採用しており、インストーラもOpenSSLを使用している。これはOpenSourceであり且つアップデートが頻繁に行われているため、信頼性の高いものである。こちらを使った場合は、サーバとの通信が行えなかった。
もう一つはEdgeの暗号化ライブラリを使ったHTTP POSTデータ送信を使用したところ、問題無くサーバとの通信ができた。
暗号化ライブラリが関係しているのは、下記の第５層に位置している。恐らくKAGOYA VPSでは、LAN内のルータにて第５層のペイロードを見て、OpenSSLだと分かる何かで判断して、ブロックしているのだと思う。
BOTが扱っているのは第７層だが、ここは暗号化ライブラリによりデータが暗号化されているのでチェックすることが出来ない。そこでBOTが使用している暗号化ライブラリに着目して、BOT利用者を弾き出そうとしたという訳だ。
いつから使えなくなっているのかは分からない。少なくとも１回目の使えない報告があったのが2023/3/25なので、それより前から使えなくなっていたということだろう。
この対処の仕方が、一般的に考えてあり得ない対応だと思ったので、当方からKAGOYAに以下のように問い合わせてみた。
土日祝を除いた３営業日と考えると、18時は営業時間外なので11/14（火）までに連絡があるのか待ってみようと思う。
今回発覚した暗号化ライブラリ特有のペイロードでブロックしているということが分かり、こういう技術は、BOT対策として他でも行っているに違いない。
ブラウザと同じデータを送っているのに、処理でHTTP通信を行うとサーバ側で弾かれる理由の１つにこの件が該当するのだと思うと、もっと早く調べておけば良かったと少し後悔した。
当社BOTは全てOpenSSLを使用しているため、他の暗号化ライブラリに変更しようと実際に動き始めている。
サーバ運営側はBOT利用者を追い払いたいと思うだろうが、私はBOT利用者を推進する側なので、今回のことは正直むかついた。
前回の便利ツール（Androidアプリ）と連携する機能を、チケットぴあ自動購入に追加しました。
使用するには、最新のインストーラをインストールする必要があります。
ヘルプメニューの「MQTT Settings」を選択すると、以下の画面が表示されます。
MQTT Brokerに接続のための情報を設定後、Connectボタン押下で、接続されます。
次に、Topicを指定します。指定後、TabキーでSubscribeボタンが有効になります。
Topicは、便利ツール（Androidアプリ）と同じにする必要があります。
試しに、Publish欄に、「tel:xxxxxxxxxxxx」（x=電話番号）を設定してPublishボタンを押下すると、便利ツールが起動状態であれば、その電話番号に発信することが確認できます。
以下は、チケットぴあ自動購入ツール自身も「tt」TopicをSubscribeしているため、送信したデータを受信しているのが分かります。
チケットぴあ自動購入の右側には、MQTTの状態が表示されており、以下の表示になっていれば、繋がった状態になります。この状態であれば、電話認証が表示されたときに、スマホと連携する動きになります。
座席指定のチケットを扱うのが初めてだったからか、対応する画面の量がいつもの倍以上あったため、予定外の時間を費やしてしまいました。
画面遷移の仕組みも、自分は今まで出会ったことが無い作りになっていて、最初はすんなり行けそうと思っていたのですが、なぜか最後の購入完了のところでサーバに弾かれてしまい、その理由が全く分からず、仕方なく通信とブラウザ遷移のハイブリット型と言ったらよいのか、とにかく今までの形とは異なるものが出来上がりました。
動作速度については、最速にはしておらず、失敗しない速度にしています。
最後の画面遷移は入力はしていません。裏でデータは全て取得済みのため、そのデータを足しているだけです。
