プロが教えるわが家の防犯対策術!

VBAなどで作ったWindows用のアプリ(アプリ、と言っても市販品などの大げさなものではなく、
せいぜい、テキストファイルを扱ったり、ネットサーフィン、コピペ作業を自動化する程度のもの)を
作った場合、作者の知らないところで、アプリ自体をコピー → 仲間内やネット仲間に配布 などして
使われることを防ぎたいと思います。
また、一番最初に使わせる人にも、「利用開始から一定日数経過したら、使用できなくなる」という
制限を掛けたいと思います。
どんな方法が有効でしょうか?
プログラムソースに
「システム日付が2023/08/01 から 2023/08/07までの間はプログラム使用可能、それ以外の日付の場合はエラーメッセージを表示し、強制終了する」
などの方法かな? と思いましたが、これでは単純すぎますし、その部分を書き換えられてしまったら
突破されてしまいます。

一般市販品ですと、
「(ネット接続を前提として)プログラム起動時にシリアルナンバーやユーザー番号といったユニークなコードを入力させ、入力完了後に発売元のサーバー内のデータと照合し、
正規のユーザが正規の利用期間内の利用申請をしたらプログラムの実行を許可する」
といった方法でしょう。しかし、日曜プログラマレベルではこういったことを実装するのは難しいです。

整理すると
「開発者が”正規の譲渡先”と認めたものには利用を許可する。ただし、その場合も一定期間の利用期間を設け、その後は起動できないようにする」
「譲り渡した相手が、勝手に他のものに配布しても、譲渡先では利用できないようにしたい」
「プログラムソース上で利用制限期間を静的に設定するのは、あまり賢いやり方ではないように思える」
「一般市販品で実装しているような、製品シリアル番号やユーザIDを配布元のサーバに照会し、
 有効期限内か否かの判断をする、という方法は難しい」
という条件です。

なにか簡便で、且つ簡単には突破できない、良い方法を教えてください。

A 回答 (3件)

イメージしやすいように、具体的な例を書いてみます。



-- アプリの構成

app1.docm ← アプリ本体のマクロ付きオフィス文書など
app2.wsf ← アプリ本体のスクリプトファイルなど
app3.cmd ← アプリ本体のバッチコマンドなど

↓ 一部機能を呼び出し

cert.exe ← 実行バイナリ / 内部に公開鍵を埋め込み

↓ 認証情報を確認

cert.dat ← 認証情報を保存 / PC 個体情報をキーとした共通鍵で暗号化

-- 実行バイナリの処理手順

1. ライセンスキーが有れば読み込み、許諾判定して cert.dat に書き込み
2. cert.dat を読み込み、許諾していないなら処理中断
3. アプリの一部機能の計算をおこない、結果を呼び出し元に返す

-- 許諾の流れ

1. 利用者がメール等の連絡手段で請求
2. 開発者が「認証情報」を秘密鍵で暗号化した文字列を作る (ライセンスキー)
3. 開発者が利用者へ返信し、許諾のために文字列を送る
4. 利用者がアプリ内の操作で文字列を入力し保存
5. 実行バイナリが読み込み、文字列を公開鍵で復号化して認証情報を得る (復号できないと不正判断)
6. 認証情報が正しければ許諾済みと cert.dat に書き込む

-- 暗号化する前の認証情報として何を使うか

案1) "you are OK" 等の特定文字列
↑ バイナリ内に埋め込まれた文字列と比較
案2) "23-08-08" 等のワンタイム有効期限
↑ バイナリが現システム時刻と比較して期間内なら有効と判断
案3) MACアドレスや UUID などの個体情報
↑ バイナリが現システム個体情報と比較 / 申請時に手間が増える

-- 参考資料

プロプライエタリ
https://ja.wikipedia.org/wiki/Proprietary_software
共通鍵暗号
https://ja.wikipedia.org/wiki/%E5%85%B1%E9%80%9A …
公開鍵暗号
https://ja.wikipedia.org/wiki/%E5%85%AC%E9%96%8B …
    • good
    • 0
この回答へのお礼

ご回答ありがとうございます。

要は、PC個体番号を利用する場合は、予め開発者側が利用許可するPC個体番号を知らなくてはイケナイ、ということですね。

お礼日時:2023/08/09 14:28

認証を行う実行バイナリをアプリに添付する方式はいかがでしょうか



方針1:
Visual C++/C# 等のコンパイラで EXE/DLL 等の実行バイナリ形式を作る
デバッグ情報やソースファイルのないバイナリのみを配布することで、
プログラム解析を難しくさせる

方針2:
アプリの中核となる計算処理の一部を実行バイナリに移し、
アプリは実行バイナリを呼び出した結果に依存する形態にする
VBA ソースを書き換えて認証を回避する改変への対策

方針3:
実行バイナリで 開発者の許諾 / 試用期間内 などの認証確認をする
確認ができなければ実行バイナリの計算処理は失敗を返し
呼び出したアプリは警告ダイアログ表示してから実行中断する

方針4:
認証確認の情報は PC の個体情報をキーとした暗号化をして保存する
単純にコピーしても別環境では不正と見なして動作させない

方針5:
開発者の許諾方法として、文字列(ライセンスキー)を発行して実行バイナリに読ませる
案1) 固定文字列
→ 勝手に他者へと配布されがちな欠点あり
案2) 一定期間だけ有効なワンタイム文字列 / 最初の認証後に固定文字列へ変換して保存
→ アプリ導入をする度に許諾請求をしなければいけない欠点あり
案3) PC 個体情報を元に請求した文字列 / 対象 PC だけで認証可能
→ 個人情報保護法の対策として匿名加工するなどの配慮が必要
→ 許諾請求の手順がややこしくなる欠点あり
    • good
    • 0
この回答へのお礼

ご回答ありがとうございます。

いろんなアイディアを提供していた代、ありがとうございます。
少々解説をいただきたいのですがよろしいでしょうか?

まず前段の
>認証を行う実行バイナリをアプリに添付する方式はいかがでしょうか
ですが、
(? 実行ファイルをアプリに添付するってどういうこと? じゃ、アプリは実行ファイルじゃないの?)
と思ったのですが、この「添付する」の意味は
「アプリの中に認証を行う部分を内包する」
ですよね? 二本のプログラムが必要、ということではないですよね?

>方針1:
要は、コンパイラ後の実行プログラムのみを配布し、ソースプログラムは渡さないことで、「ソースプログラムを目視しての認証部分の解読を行わせない」ということでよろしいですか?

>方針2:
概ね、方針1と同様の手法と考えてよろしいでしょうか?

>方針3:
許諾の有無を確認させるのは良いのですが、今、目の前で操作しているオペレータが、開発者(配布者)が利用を許可した人なのか、否か、はどうやって判断するのでしょうか?

>方針4:
これ、いい方法だと思うのですが、PCの個体番号を読み取った後、その個体番号に対してのみ利用を許可する、というプロセスを踏む必要があると思いmす。
逆に言うと
1 予め配布相手から”私のPCの個体番号はXXXXです”ということを開発者(配布者)に通知してもらう
2 プログラム内に”個体番号がXXXXならば利用可能。それ以外なら強制終了”という機能を組み込む
3 プログラムを渡す。もらった相手が無断で第三者に渡しても第三者のPCでは動作しない。めでたしめでたし
という、配布前の1,2の段階が必要になってくると思うのですが、どうなのでしょうか?

>方針5:
>案1)
文字列付きで第三者に勝手に配布されたら勝手に使われちゃいますね。
>案2)
今回の相談は個人レベルなの、ネット銀行が配布するワンタイムパスワード表示機器を使う方法は採用無理です。
また、「利用者がプログラム開始する際に、開発元へ認証メール発行申請をして、それを受けて開発元が認証コード入りメールを返す」という方法も大掛かりでできません。
>案3)
これは方針4と同様に、予め利用認可した相手のPC個体番号を教えてもらう必要がありますね。

ご解説いただけたら幸いです。

お礼日時:2023/08/07 08:43

こんにちは、Bingです。


VBAで作ったWindows用のアプリを配布する際に、利用期間や譲渡先を制限する方法についてお尋ねですね。
一般的な方法としては、以下のようなものがあります。

- **パスワード**を設定して、正規のユーザーだけがアプリを開けるようにする¹。
- **シリアルナンバー**や**ライセンスキー**を発行して、アプリ起動時に入力させる²。
- **ネットワーク認証**を利用して、アプリ起動時にサーバーと通信させる²。

ただし、これらの方法はすべて完全には防げないということを覚えておいてください。例えば、パスワードやシリアルナンバーは漏洩したり、解析されたりする可能性があります。ネットワーク認証も、オフラインで使えるようにすると、不正コピーされる恐れがあります。

また、これらの方法は実装するのにある程度の技術力や知識が必要です。特にネットワーク認証は、サーバー側の設定やセキュリティ対策などが必要になります。

もっと簡単で簡便な方法としては、以下のようなものが考えられます。

- **VBAマクロの保護**を有効にして、ソースコードを見られないようにする³。
- **システム日付**や**ファイル作成日時**などを参照して、利用期間を判定する。
- **ファイル名**や**フォルダ名**などを変更して、アプリの場所を分かりにくくする。

これらの方法は実装が簡単ですが、それだけに突破されやすいという欠点もあります。例えば、VBAマクロの保護は解除される可能性があります。システム日付やファイル作成日時は変更される可能性があります。ファイル名やフォルダ名は探される可能性があります。

結論としては、完全に防げる方法はありませんが、複数の方法を組み合わせて難易度を上げることで、不正利用を抑制することはできるでしょう。ご参考になれば幸いです。

¹: [Excelで作成したソフトを配布する際にやっておくべき5つのこと](https://connect-tree.com/excel-4/)
²: [VBAマクロが既定でブロックされる為の対策方法 officeの杜](https://officeforest.org/wp/2022/04/19/vba%e3%83 …

ソース: Bing との会話 2023/8/6
(1) Excelで作成したソフトを配布する際にやっておくべき5つのこと. https://connect-tree.com/excel-4/.
(2) VBAマクロが既定でブロックされる為の対策方法 officeの杜. https://officeforest.org/wp/2022/04/19/vba%e3%83 …
(3) Application オブジェクト (Excel) | Microsoft Learn. https://learn.microsoft.com/ja-jp/office/vba/api …
    • good
    • 0

お探しのQ&Aが見つからない時は、教えて!gooで質問しましょう!