元スレ+ JavaScript の質問用スレッド vol.134 +
JavaScript覧 / PC版 /みんなの評価 :
501 = :
ジャップ真でくれ
502 = :
スレをミスったわ
503 = :
なーにが会話のボールだ
ボールにウンコ付けて投げといて相手がキャッチしないとブー垂れるバカかww
取るわけねーだろバーカwwww
504 = :
「解析されにくい」が前提にあればできることなら
例えばflashなどで実現されてたはずの手法ってことにならんかね
あれわりとブラックボックスだろ
505 = :
>>499
>>486は入力された文字列をトリップみたいなもので返してほしいな、
程度の話で、>>486の最後の行と>>491のシリアルキーのくだりはmd5云々とは別の話です
シリアルのくだりを強いて言うなら例えば、
(1)シリアルキーを発行するwasm
例)「3284443」や「7138751」という素数シリアルキーを発行する
(2)シリアルキーを解読できる圧縮解凍フォーマットwasm
例)「3284443」や「7138751」を素数判定して解凍
みたいな感じです
仮に、素数も(1)(2)のソースコードもバレなければ、復号化が難しい
みたいな感じです
ただし、シリアルコードが流出することや復号化されたデータが流出することには対応できません
みたいな感じです
さすがにくどいと思いますが、もちろんシリアルキーが素数というのはあくまで例なので
そのままの意味で受け取らないでくださいね
もっと良い例があると思うので脳内変換してください
あとこのレスは>>498の通りです
507 = :
素数……ソース……
ふふっ
509 = :
>>505
見事に「ウェブ言語だけでシリアルナンバーとか生成」が意味不明なままなんだが
コンテンツに対するプロテクトのくだりだけ拾っても
>シリアルキーを認識できる
>シリアルキーを解読できる
ってどんな処理を想定してんの
暗号化分野に関わらないほうがいいと思う
510 = :
「ソースコードが」読まれないからなんだっつーんだよ
511 = :
はじめから最後まで処理フローを書き起こしてみると問題点がわかるようになると思うよ
書く能力があるならね
514 = :
>>512-513
他人の企画にタダで添削してあげる趣味はないんだけど
あえて言うと
原則的にファイルとしての取得をさせずブラウザ上でのみ閲覧/使用等が可能、
・・・と出来なければ、絵に描いた腐った餅では
それをなんとかできないのであれば
「.wasm・シリアルキー・暗号化済み製品コンテンツ、以上3つが揃わないとコンテンツを復号化できない」
という仕組みにする意義がない
既存の方法の改悪に過ぎなくなり、>>512の5段目などは根拠に欠ける論理飛躍となる
あと、そんな仕組み想定だとて「ウェブ言語だけでシリアルナンバーとか生成」「シリアルキーを解読できる」は意味不明のまま
説明スキルの欠如なども鑑みると、正直いって企画・設計に携わらないほうが良いと言っておきたい
515 = :
擁護レスが皆無
516 = :
> >>512の5段目などは根拠に欠ける論理飛躍となる
あれ・・?そうですかね
例えばBtoCサービスによるCtoCの補助サービスな感じで
.wasmの生成や配布が企業により保証されていれば、ハードルが低いというか
「うちのサービス使うならこのアプリ使ってね」や
「こちらからユーザに紐付いたコンテンツ別の.wasmを生成してね」
なんかは自然な流れだと思いますね
完全CtoCかつ個人で決済もシリアル発行も、は利用者のリテラシ上ハードルは高そうです
ですが、上にも書いたよう.wasm生成・配布サービスが保証されていれば
インストールする前に、企業連携でハッシュ値の確認をすればいいだけのような
>ウェブ言語だけでシリアルナンバーとか生成
そもそも始まりの、自分の認識が
「WebAssemblyのソースコードって読めちゃうの?」
「逆汗で中で何やってるか丸わかりなの?」
みたいなところから来てるのでとくに深い意味もなく
説明としては>>491ですね
要は、webassembly使えばお手軽にシリアルキー発行できるか否か
程度の話です
>シリアルキーを解読
これはよくあるプロダクトキーの照会と捉えていいかもですね
ただ、キーを.wasmに投げた後の処理が照会→キーの解析→閲覧などあります
コンテンツ売買のくだりも、企画設計を想定しているというか
>ってどんな処理を想定してんの
という質問が来たので、例えばこういうのできたら面白そうだなと
即席で考えた感じです。もっと単純に言えば
「複数のIDが事前に登録されており、ランダムにechoするだけの.wasm」
これが実行される前に
・バイナリデータから全登録IDを取得できるのだろうか?
・逆アセで全登録IDはバレバレ(丸見え)なのだろうか
というが知りたかっただけです
517 = :
単純な話、
ウェブ上でみんな同じファイル(.wasm)を読み込んでいるのに
キー発行のアルゴリズムがバレずに独自キーを発行できる
って何かすごい気がする
と思っただけというか
518 = :
今の心境を語るなら、仕様バグに突っ込みを入れたときの、担当者の言い分を聞いている感覚に似ている
519 = :
>>484
そうです
自分がやりたいのは英語の置換なので、
英語の活用形と何の繋がりもないのに綴りが同じ名詞がないこともないだろうと。
あと単純に、形態素解析なら、原形に置換するための辞書を用意する必要がないというのもあります
一度で、二度おいしい
520 = :
ということで今週中にお願いします
納期が迫ってるんです
522 = :
>>520
だからやりすますのやめて下さい
納期なんてないです
524 = :
確かにWASMにすればソースコードはわからないけど、
バレたくないのって特許的なアルゴリズムだったり、計算に纏わる各種数値でしょ
そのくらいであれば簡単に解析できるよ
バイナリとは言えasm.jsを圧縮したようなもんだから、アセンブリとは違って逆コンパイルも単純だし
その状態でも確かにメモリアクセスを理解するのはやや煩雑だがロジックは簡単に読める
528 = :
この長文の人って>>502と同一?
構ってもらえる訳ないだろ
529 = :
今ちょっと試せないで草
530 = :
そのままコードを置き換えてるという点では
既存のミニマライザ程度の難読化効果はあるだろうがそこまでだからな
その状態でも通信すれば内容は抜けるし
どんなに難読化しようと最終的にCanvasに書き出せばそれは簡単に取得できる
そしてでっかいABをメモリに見立てて使うと言う点では
その1つのABさえ監視しておけば全ての重要なデータがそこに含まれてるのだから
ネイティブのゲームなんかのハックでCheat Engine使ってプロセスメモリ解析するようにABを解析するようにすれば、
むしろミニマイズされたコードの流れをデバッガで必死に追いかけていくよりもチートが容易いかもしれない
既存のチート対策のようにメモリ管理を丸ごと自前で構築して
頻繁に割当を移動させるだとか、値をXORしたりする方法はあるかもしれない
でもWASMの問題は逆コンパイルが容易でそういうコードもバレやすいし、ランタイムの改ざんも非常にしやすい
531 = :
つまりjavascriptの難読化するやつは悪人ってことですね
533 = :
協力会社の人に聞くことにします
534 = :
強力な協力会社です
535 = :
>>532
コンパイル最適化で定数の120にされるのでそれはわからない
わからないと言うか実際はただ120をかけてるだけ
でもそこが分かっても分からなくても大したこと無いだろうよ
540 = :
変換テーブルだけ使わせてもらうのもアリかと思い>>539のソースを見てみたのですが、
どういう基準が選ばれたのか分からない、不思議な連語が結構含まれていて、謎みがあります
おそらく、元になったライブラリから流用されたものだと思いますが。
それでふと思ったのですが、語を一つ一つ英和辞典で引くことでも、変換テーブルは作成可能ですよね?
英和辞典なら、複数形で引けば単数形が出るし、過去形で引けば現在形が出るはずです
コマンドラインで引ける(プログラムから引きやすい)英和辞典はないものでしょうか?
541 = :
自演臭い
543 = :
>>541
「JavaScript 英語 動詞 原形」とかで検索したら最初に出てくるページですが?
>>542
ありがとうございます
語幹だけを取り出すプログラムはstemmerっていうんですね
そういうキーワードになる術語も知らなかったので助かります
545 = :
ajaxでよくある、クロスドメインの問題です
ぐぐりましょう
546 = :
node.jsのnaturalっていうのは、自然言語関係の一般的なアルゴリズムを集めたもので
辞書は含まれていないようですね
すべてをアルゴリズム的に処理するので、不規則動詞を原形にしたりは出来ないようです
WordNetにアクセスするモジュールもあったので期待したのですが
WordNeは意味を中心に語を体系づけたものなので、語の外形についての情報はないっぽいです・・
547 = :
そうかそりゃすまんかった
549 = :
これなら今週中の納期に間にあうかな?
550 = :
というかwebapiに丸投げとかしちゃいけないの?
類似してるかもしれないスレッド
- + JavaScript の質問用スレッド vol.131 + (1000) - [97%] - 2017/1/25 8:01
- + JavaScript の質問用スレッド vol.137 + (1003) - [97%] - 2019/3/26 11:46
- + JavaScript の質問用スレッド vol.130 + (974) - [97%] - 2016/10/26 14:18
- + JavaScript の質問用スレッド vol.114 + (1001) - [97%] - 2014/5/3 10:45
- + JavaScript の質問用スレッド vol.130 + (1001) - [97%] - 2017/11/25 20:45
- + JavaScript の質問用スレッド vol.131 + (1004) - [97%] - 2018/3/7 13:30
- + JavaScript の質問用スレッド vol.132 + (1001) - [97%] - 2018/4/19 11:00
- + JavaScript の質問用スレッド vol.133 + (1001) - [97%] - 2018/6/8 10:45
- + JavaScript の質問用スレッド vol.136 + (1001) - [97%] - 2019/1/8 11:30
- + JavaScript の質問用スレッド vol.135 + (1002) - [97%] - 2018/11/23 10:30
- + JavaScript の質問用スレッド vol.138 + (1004) - [97%] - 2019/4/20 23:45
- + JavaScript の質問用スレッド vol.139 + (1001) - [97%] - 2019/5/27 15:15
- + JavaScript の質問用スレッド vol.104 + (1001) - [97%] - 2013/1/28 4:00
- + JavaScript の質問用スレッド vol.124 + (1001) - [97%] - 2015/7/16 1:30
- + JavaScript の質問用スレッド vol.144 + (288) - [97%] - 2020/5/17 20:00
- + JavaScript の質問用スレッド vol.113 + (1001) - [95%] - 2014/3/15 21:30
- + JavaScript の質問用スレッド vol.119 + (1002) - [95%] - 2014/10/3 15:30
トップメニューへ / →のくす牧場書庫について