QIWI端末。 別の方法

実を言うと、私はQIWIの支払い端末や、そのためのソフトウェアを扱ったことがありません。 どうやら、星は非常に形成されていたので、支払い機との私のほぼ5年間の会話は、2006年に5人のピンクの鉄の友人を獲得した地下タイプの未知の会社から始まりました。 それでも、QIWI端末がいくつあるかを見ると、所有者は、端末ソフトウェア、処理、監視を使用して自分のネットワークを作成した方法を読んで、おそらく何かを武器に取り入れることに興味があると思います。

知人

おそらく誰かにとっては、9年前、すべてのマシンがタッチスクリーンを持っていなかったという啓示になるでしょう。 私が購入したものは、ATMのスクリーンとほぼ同じように配置されていました。普通の破壊者に強いスクリーン、スクリーンの下に別のデジタルユニット、スクリーンの左右に2つの列の4つのボタンがあります。 momentalka.exeプログラムはソフトウェアとして機能し、学生の仕事の最高の伝統で作られた15枚のA4シートの広範なマニュアルが添付されていました。ボリュームの水の80％、有用な情報の20％。 残念なことに、このプログラムはかなり前に失われたため、そのインターフェースを実証することはできません。 要するに、これは、可能な演算子がハードコードされ、可能な演算子がプログラムでハードコードされたjpg画像のセットであり、何かを変更、追加、または削除したい場合、私自身は非常に失望しました。 販売者の功績として、メイン画面に出荷する前に、私が必要としていたのはまさにオペレーターでした。



当時、決済システムの市場はあまり発展しておらず、QIWI（当時のOSMP）はリーダーではなく、主にe-portを使用し、その後QIWIが購入しました。 QIWIと比較して、e-portにははるかに多くの可能性がありました。サーバーと対話するための3つの形式、ピンコードまたはデジタル署名による承認の可能性、httpsからの選択、および作業。



私の自動販売機にはインターネットがありませんでした。当時、私のような郡の町には3Gモデムも第三世代ネットワークもありませんでした。そして、自動販売機のコストの10％でヒキガエルが首を絞めました。 私は安価なモトローラE350L電話を購入しました。その利点は、通信用のUSBポートと独立した電源コネクタの存在でした。 彼らにはいくつかの困難がありましたが、一般的にはアイデアは報われました。

最初の問題

彼らは仕事の最初の日に始まりました。 結局のところ、法案アクセプターと連携するためのプロトコルは非常に不自然に解決され、法案アクセプターがホストに法案は使用できないが報告に成功したと報告したときに状況がしばしば発生しました。 または、飲み込んでおらず、かみましたが、これは一般的には問題ではありません。クライアントは、彼のお金が電話に到着しようとしていると固く信じています。 私も所有者としてこれを頼りにしていますが、最終的には支払いが失われ、請求書受領者のスタッカーにお金が計上されません。 箱の内容をプログラムで受け入れられた請求書のログと比較し、これらの不一致を見つけなければなりませんでした。 怒った投資家が、「左の紙幣」を見つけるよりも早く問題を知らせてきたことがよくありました。



2番目の不快な瞬間は、監視の完全な欠如に関連していました。 つまり マシンがまだその場所に立っていること、請求書を詰まらせたり、ハングしたり、インターネットがそれに落ちたりしないことを見つけるために、定期的に支払いを行うことから間接的にのみ可能でした。 同時に、不足している支払いと端末のパフォーマンスの間に大きなパターンはありませんでした。そして、私はしばしば到着して、すべてがマシンに問題がないことを見つけました。



別の失望は、白緑のオペレーターからのインターネットでした。 最も安いように見えますが、6 r / mbのトラフィックの価格で100 kbの課金しきい値は、インターネットの1か月あたり1000ルーブルに注がれました。 その結果、固定インターネットはマシンの半分で実行され、これが不可能なマシンではオペレーターが交換され、インターネットは正式に高価になりましたが、実際にはインターネットコストは月額100 rに下がりました。

最初の改善

端末の1つは、私のオフィスと同じ建物内にあったため、ツイストペアケーブルが接続され、端末自体が主要な実験ウサギになりました。 当然のことながら、処理の最初の犠牲者は端末からのネイティブプログラムでした。 しばらくの間、私の友人と私はportmonを通じて請求書受領者のプロトコルを調べましたが、これは2006年であり、インターネットで情報を見つけることができなかったことを思い出します。 それにもかかわらず、すべてがうまくいき、請求書を正常に受け入れることができました。 2番目の主要な改善点は、eポートサーバーとの連携の変更でした。第2バージョンの新しいプロトコルに切り替え、デジタル署名による承認を実装しました。 原則として、9年後でも、端末から送信されるsslパケットをインターセプトしてそこからPINコードを取り出す必要があるかどうかはわかりません。マシンにアクセスしてそこからデジタル署名を取得し、全体をマージするよりもはるかに簡単ですYandexのマネーまたはウェブマネーに対するエージェントの残高との残高が、完了しました。



さて、最後に、インターフェースが完成し、1つまたは別のオペレーターに属する番号の自動識別が実装され、最初のバージョンが正常に機能しました。 もちろん、最初は特定のbajochkiとバグさえ浮上しましたが、深刻なことは何もありませんでした。 以下にスクリーンショットをいくつか示します。





メイン画面では、すぐに番号をダイヤルして支払うことができます





お金を預けた後、もう少しお金を払うか、支払うことができます



数週間の正常な作業の後、不具合なしで、ログモジュールが追加され、マシンの動作に関するすべての情報が当社のWebサーバーに送信されました。 これらはすべてfirebirdデータベースに保存されていたため、必要な情報の検索は、何らかの統計や失われた請求書の検索など、単純なSQLクエリに限定されました。



彼はまた、携帯電話の画面に表示するための最小限のスタイルで小さなWebマズル（スクリプトなし、最小htmlのみ）と、電話があり、自分の存在が必要な場合に適切なマシンに誘導するオペレーターのためのプログラムを作成しました。





オペレーター向けプログラム。 印刷キュー内のジョブは、プリンターの用紙切れを意味します



少ししてから、請求書の受理者に問題が発生した場合、すぐに到着して詰まった請求書を引き出したり、顧客が拷問したデバイスを再起動したりするために、アスタリスクを使用して電話を鳴らしました。 それは非常に便利です。特定の番号が鳴り、すぐに問題がある統計ページを見て、その場所に移動します。完全自動化です。

センサーに切り替え

1、2年の成功した仕事の後、ログインが個人アカウントとして示されているローカルインターネットプロバイダーの支払いを受け入れる必要があり、少なくとも孫が置くために送ったあまりにも高度な祖母にとっては、デジタルブロックに入力することは非常に問題ですインターネット上で百ルーブルとログインで一枚の紙を与えた、これは不可能な作業になります。 私はデザインをやり直し、タッチスクリーンをインストールすることにしました。



その時までに、ソフトウェア部分は再設計されました。つまり、2つの独立したモジュールに分割されました。1つはインターフェイスで動作し、紙幣と印刷小切手を受け入れ、2つ目はすべてのデータを支払いシステムサーバーに送信し、サーバーにログを記録し、インターフェイスのウォッチドッグとしても機能しましたモジュール。 今後は、領収書印刷モジュールも別の実行可能ファイルに割り当てられていました。 私はすべてのマシンをセンサーに転送しませんでしたが、私の意見では正当化された部分のみを転送したため、バックグラウンドモジュールはそのままでしたが、インターフェースモジュールはタッチスクリーン用と通常のブランチ用の2つのブランチに分割されました。 一方で、これはサポートをやや複雑にしました。一方で、より多くのプログラムがあったため、他方では、2年で非タッチインターフェイスがなめらかに舐められ、私はもう触れませんでした。



タッチスクリーンを操作するためのインターフェイスにより、マシンが以前は物理的に受け入れることができなかったプロバイダーを追加できるようになりましたが、モバイルオペレーターとローカルインターネットプロバイダーの支払いを受け入れることに制限し、後で別のプロバイダーを追加することにしました。 まず、顧客の行動を観察すると、明確に述べることができます-オプションが少ないほど、この選択が誤って行われた問題が少なくなります。 第二に、OSMPソフトウェアを使用している同僚は、定期的にさまざまな電子財布に不法にお金を引き出す試みを行ったため、私は気にしないことにしました。 以下のインターフェースの写真：





メイン画面では、何かを選択する必要があります





支払いの過程で





成功！

決済システム事業者の変更

ネットワークが正常に動作し、通常の収入と最小限の問題をもたらすまでに、QIWIはeポートを正常に購入し、私のソフトウェアが私のように機能するためにゲートウェイを体系的に閉じ始めました。 マネージャーは随時電話をかけ、ゲートウェイが先月機能しており、支払いを受け取ることができなくなったことを警告し、OSMPからソフトウェアに切り替えるように説得しました。 おそらく私は行ってこの物語は終わったかもしれませんが、自動販売機の半分はタッチスクリーンがありませんでした、私は近代化に投資したくありませんでした、さらに、受け入れられたオペレーターのリストは支払いシステムによって規制されており、場合によっては私のコミッションもあります。



したがって、受け入れられる唯一のオプションは、端末にソフトウェアを残し、品質で処理を記述することでした。 実際、その時点までにすべての支払い端末からのすべてのログが既にサーバーに送信されているため、セキュリティのために電子デジタル署名を追加し、ログを少し解析して、以前はロギング専用に使用されていた同じデータベースの別のテーブルに支払いが表示されるようにしました。 残っている質問は1つだけです。このテーブルから支払いを行う方法は？

カスタム処理、最大の試み

QIWIは、支払いゲートウェイを使用して支払いのチェックを外すという考えを本当に好まなかったため、私はだまさなければなりませんでした。 QIWIキャッシャープログラムがインストールされました。これは、支払いを受け取るためのオペレーターの職場でした。 必要なオペレーターはホットキーに掛けられ、エミュレータープログラムはオペレーターの不安定な活動を描写しました。端末からのログがマージされたデータベースから、必要な支払い情報が選択され、QIWIキャッシャーを通じて実行されました。 プログラムは、希望のホットキーを押してオペレーターを選択し、支払いの詳細と金額を入力し、QIWIに支払いを送信することをエミュレートしました。 これはすべて、ログがマージされた同じサーバー上の仮想マシンでスピンするため、追加コストは発生しませんでした。 一般的に、QIWIキャッシャーが「違法な操作を行って閉鎖される」ことを定期的に確認し、定期的に、場合によっては1日に数回、再開することを除いて、アイデアは成果を上げました。 ただし、端末のネットワーク上にソフトウェアを残し、それらのアクティビティを完全に制御する機能に対する低料金。

プリンター

当時（2010年）、税務調査官は支払い機を詳しく調べ始めました。これは、ほとんどの場合、端末からの現金が販売されたためであり、支払い端末を介した現金化との戦いの一環として、誰もが財政登録機関を使用する義務がありました。 もちろん、それらを供給することは可能であり、技術的な問題はありませんでしたが、機械から3.5か月分の利益を一度だけ支払わなくても、EKLZの年間メンテナンスだけでさらに10分の1の利益が奪われます。



その結果、オフィスにいる唯一の会計担当者との通信を自分の処理に追加することが決定され、現場のマシンは重複チェックを印刷します。 この壮大なタスクの2番目の部分は実現されなかったことをすぐに認めなければなりません：重複したチェックが印刷されましたが、会計レジストラがオフィスで生成するデジタル署名の代わりに、チェックは通常のランダム（65536）でした。 結局、小切手を印刷する会計レジストラは、小切手を認証する「署名」を表示しますが、小切手自体にのみ、この署名をプログラムで取得できませんでした。 EKLZ（安全な電子制御テープ-実際にすべての領収書を保存し、署名を生成するユニット）を引き出して直接作業するというアイデアがありましたが、法的な観点からは、「正直な」EKLZを備えた破壊されたレジは、同じチェックよりもほとんど優れていません誤った署名：税務当局は、ターミナルにフィスカルが存在するかどうかを確認し、存在する場合はすべてOKであり、そうでない場合はそれで問題ありません。チェックをチェックするかどうかは重要ではありません。



私はまだ会計レジストラを1つ購入しました。その結果、小切手印刷モジュールはプリンターだけでなく特定のモデルの会計レジストラもサポートし始め、小切手は同じプリンターに基づいて作成されたため、小切手はまったく同じプリンター（EKLZコードを除く）で印刷されました私の場合はCitizen CBM1000です。



多分誰かが私が同一の小切手を印刷する方法に興味があるだろう：インターネットで一般的なキャシー小切手印刷プログラムから、フォントはシンボルセルから成る画像の形で抽出された。 一般に、ビットマップフォントを使用する典型的な例として、切り抜き文字で構成される印刷が生成されました。

処理、2回目の実行

2011年の春に、私はこのビジネスを売却しました。 ただし、ボーナスとして、ロボットがQIWIキャッシャーの仮想ボタンをクリックする方法を常にradminで確認する必要がないように、バイヤーを通常の処理にすることにしました。



サーバーのリストで使用されているものを手動で指定できるため、まず、レジとサーバーとの通信を調べることにしました。 したがって、httpsを介して動作するすべてのサーバーが削除され、wiresharkが起動され、すべてが非常に明確になりました。支払いデータを含むxml-requestです。 2つの困難がありました。支払いに関係のないリクエストの特定の「マジック」パラメータと、リクエストの電子デジタル署名です。 私の友人と私は最初の問題-ollydbg、1時間-をすぐに解決し、日付、金額、端末番号で構成される特定のコードを計算するアルゴリズムの準備が整いました。 私はEDSをいじる必要がありました：レジ係は標準のWindows CryptoAPIツールを使用し、キーは回復不能な状態で生成され、メモリ内で検索して抽出しました。これが原理的に可能な場合、スキルはありませんでした。 ここで、少し余談をして、このキーを生成するプロセスがどのように発生するかを伝える必要があります。 このため、QIWIにはもう1つのプログラム、QIWI保護があります。 この同じ回復不可能なキーを生成し、その後、QIWIキャッシャーはそれを使用して送信された要求に署名します。 生成には、さまざまなキーオプションが設定されているパラメーターの1つで、CryptGenKey関数が使用されます。 秘密鍵のエクスポートを許可するCRYPT_EXPORTABLEフラグを設定するように、exeファイルにパッチを適用しました。 その後、キーが生成され、問題なく抽出されましたが、問題はありませんでした-パスワードを担当するCryptExportKey関数のパラメーターパラメーターで、NULLの代わりに空の引用符が設定され、2日間、エクスポートされたキーを必要な形式に変換できませんでした。 さて、バグが敗北したとき-別のLinux仮想マシンで30秒ごとにクラウンからさらに数時間のコーディングとphpスクリプトが実行され、QIWIサーバーに支払いが送られました。

おわりに

数年後、私のマシンは再び転売されました。すでに大規模なネットワークで、QIWIソフトウェアを使用しており、処理に煩わされていませんでした。 どうやら、何かを最適化するよりも、手数料を2倍にして、彼らが働いていたという名目で銀行に売上高の割合を支払う方が、より有益であることが判明しました。 そして、処理中の仮想マシンをオフにし、ログを収集するためにWebサーバーを停止し、私の開発のもう1つは要求されなくなりました。



アルマジストの創造は、私がこの記事を書くきっかけとなりましたが、私たちのアプローチは根本的に異なりますが、私の意見では、本質は同じです-私たちのマシンの独自のルールを確立するために。 私はプロのプログラマーではないので、コードを書いて生計を立てているわけではありません。そのため、私の開発はDelphi 6で停止しました。これは研究所での長年の研究に関連しており、ソースコードを公開していません しかし、誰かがそれを必要とする場合-彼はそれを共有する準備ができている、それを取る-それは残念ではありません。 面白かったと思います。