ジャップ真でくれ

スレをミスったわ

なーにが会話のボールだ
ボールにウンコ付けて投げといて相手がキャッチしないとブー垂れるバカかｗｗ
取るわけねーだろバーカｗｗｗｗ

「解析されにくい」が前提にあればできることなら
例えばflashなどで実現されてたはずの手法ってことにならんかね
あれわりとブラックボックスだろ

>>499
>>486は入力された文字列をトリップみたいなもので返してほしいな、
程度の話で、>>486の最後の行と>>491のシリアルキーのくだりはmd5云々とは別の話です
シリアルのくだりを強いて言うなら例えば、
（１）シリアルキーを発行するwasm
　　例）「3284443」や「7138751」という素数シリアルキーを発行する
（２）シリアルキーを解読できる圧縮解凍フォーマットwasm
　例）「3284443」や「7138751」を素数判定して解凍

みたいな感じです
仮に、素数も（１）（２）のソースコードもバレなければ、復号化が難しい
みたいな感じです
ただし、シリアルコードが流出することや復号化されたデータが流出することには対応できません
みたいな感じです

さすがにくどいと思いますが、もちろんシリアルキーが素数というのはあくまで例なので
そのままの意味で受け取らないでくださいね
もっと良い例があると思うので脳内変換してください
あとこのレスは>>498の通りです

素数……ソース……
ふふっ

http://blog.mbaas.nifcloud.com/entry/2018/01/31/104952
ちなみにこの記事
＞WebAssemblyとは？
＞バイナリ、つまりコンパイルされていますのでソースコードが読まれることはありません。
てあるけど

>>505
見事に「ウェブ言語だけでシリアルナンバーとか生成」が意味不明なままなんだが

コンテンツに対するプロテクトのくだりだけ拾っても
>シリアルキーを認識できる
>シリアルキーを解読できる
ってどんな処理を想定してんの

暗号化分野に関わらないほうがいいと思う

「ソースコードが」読まれないからなんだっつーんだよ

はじめから最後まで処理フローを書き起こしてみると問題点がわかるようになると思うよ
書く能力があるならね

>>509
＞ってどんな処理を想定してんの
一言でいうと、コンテンツのプロテクトです

まず、>>505の（１）.wasmと（２）.wasmをみんながインストール？する
（例えばchromeの拡張でもアプリでもなんでもいいので読み込む）

Aさんがコンテンツをアップロード（アップロード先の指定なし）
その際、（２）.wasmで圧縮（や暗号化など）　→　暗号化されたコンテンツA
（コンテンツAは公開されており、不特定多数がコンテンツAをダウンロードできる状態（＊１）。
が、内容の閲覧はシリアルキーがないので、できない）

BさんがAさんのコンテンツを購入
→（１）.wasmによりシリアルキーが発行される
→コンテンツAをダウンロード
→（２）.wasmに従い、コンテンツAを復号化

これが可能ならば従来のデータサーバと決済プラットフォームの集中型BtoCではなく
（1）.wasmと(2).wasmと購入→発行.wasmを配布するコストだけなので、
決済もデータサーバも場所にこだわらないCtoCが可能なのではと思いました
（もちろんBtoCかつ、データだけ別というのもあり）

もちろんこのままだとコンテンツA以外のどのコンテンツ（BCDE、、、）も同じシリアルキーで閲覧できてしまうので
今はパス付きzipみたいなものとの差別化、程度です
もっと深い解決策は賢い人に任せます

（＊１）コンテンツ自体は暗号化せず、シリアルキーをログインに必要なデータにしてもよい

>>512-513
他人の企画にタダで添削してあげる趣味はないんだけど
あえて言うと

原則的にファイルとしての取得をさせずブラウザ上でのみ閲覧/使用等が可能、
・・・と出来なければ、絵に描いた腐った餅では

それをなんとかできないのであれば
「.wasm・シリアルキー・暗号化済み製品コンテンツ、以上3つが揃わないとコンテンツを復号化できない」
という仕組みにする意義がない
既存の方法の改悪に過ぎなくなり、>>512の5段目などは根拠に欠ける論理飛躍となる


あと、そんな仕組み想定だとて「ウェブ言語だけでシリアルナンバーとか生成」「シリアルキーを解読できる」は意味不明のまま
説明スキルの欠如なども鑑みると、正直いって企画・設計に携わらないほうが良いと言っておきたい

擁護レスが皆無

＞　>>512の5段目などは根拠に欠ける論理飛躍となる
あれ・・？そうですかね
例えばBtoCサービスによるCtoCの補助サービスな感じで
.wasmの生成や配布が企業により保証されていれば、ハードルが低いというか
「うちのサービス使うならこのアプリ使ってね」や
「こちらからユーザに紐付いたコンテンツ別の.wasmを生成してね」
なんかは自然な流れだと思いますね
完全CtoCかつ個人で決済もシリアル発行も、は利用者のリテラシ上ハードルは高そうです
ですが、上にも書いたよう.wasm生成・配布サービスが保証されていれば
インストールする前に、企業連携でハッシュ値の確認をすればいいだけのような

＞ウェブ言語だけでシリアルナンバーとか生成
そもそも始まりの、自分の認識が
「WebAssemblyのソースコードって読めちゃうの？」
「逆汗で中で何やってるか丸わかりなの？」
みたいなところから来てるのでとくに深い意味もなく
説明としては>>491ですね
要は、webassembly使えばお手軽にシリアルキー発行できるか否か
程度の話です
＞シリアルキーを解読
これはよくあるプロダクトキーの照会と捉えていいかもですね
ただ、キーを.wasmに投げた後の処理が照会→キーの解析→閲覧などあります

コンテンツ売買のくだりも、企画設計を想定しているというか
＞ってどんな処理を想定してんの
という質問が来たので、例えばこういうのできたら面白そうだなと
即席で考えた感じです。もっと単純に言えば
「複数のIDが事前に登録されており、ランダムにechoするだけの.wasm」
これが実行される前に
・バイナリデータから全登録IDを取得できるのだろうか？
・逆アセで全登録IDはバレバレ（丸見え）なのだろうか
というが知りたかっただけです

単純な話、
ウェブ上でみんな同じファイル（.wasm）を読み込んでいるのに
キー発行のアルゴリズムがバレずに独自キーを発行できる
って何かすごい気がする
と思っただけというか

今の心境を語るなら、仕様バグに突っ込みを入れたときの、担当者の言い分を聞いている感覚に似ている

>>484
そうです
自分がやりたいのは英語の置換なので、
英語の活用形と何の繋がりもないのに綴りが同じ名詞がないこともないだろうと。
あと単純に、形態素解析なら、原形に置換するための辞書を用意する必要がないというのもあります
一度で、二度おいしい

ということで今週中にお願いします
納期が迫ってるんです

>>520
だからやりすますのやめて下さい
納期なんてないです

確かにWASMにすればソースコードはわからないけど、
バレたくないのって特許的なアルゴリズムだったり、計算に纏わる各種数値でしょ
そのくらいであれば簡単に解析できるよ
バイナリとは言えasm.jsを圧縮したようなもんだから、アセンブリとは違って逆コンパイルも単純だし
その状態でも確かにメモリアクセスを理解するのはやや煩雑だがロジックは簡単に読める

WASM側（jsの方がわかりやすいので）
var atari={
'Z3845fHc':'アマギフコード１',
'83F8y838':'アマギフコード２',
・
・
・
];

JavaScript側
//WASM読み込み＆ためのコード
　console.log( instance.exports.atari[id] );
//WASM（ｒｙ

例えばこういうのでもWASMのバイナリコードを読み込んだ時点で
事前にアマギフコードが全部バレちゃうってこと？

この長文の人って>>502と同一？

構ってもらえる訳ないだろ

今ちょっと試せないで草

そのままコードを置き換えてるという点では
既存のミニマライザ程度の難読化効果はあるだろうがそこまでだからな
その状態でも通信すれば内容は抜けるし
どんなに難読化しようと最終的にCanvasに書き出せばそれは簡単に取得できる

そしてでっかいABをメモリに見立てて使うと言う点では
その１つのABさえ監視しておけば全ての重要なデータがそこに含まれてるのだから
ネイティブのゲームなんかのハックでCheat Engine使ってプロセスメモリ解析するようにABを解析するようにすれば、
むしろミニマイズされたコードの流れをデバッガで必死に追いかけていくよりもチートが容易いかもしれない

既存のチート対策のようにメモリ管理を丸ごと自前で構築して
頻繁に割当を移動させるだとか、値をXORしたりする方法はあるかもしれない
でもWASMの問題は逆コンパイルが容易でそういうコードもバレやすいし、ランタイムの改ざんも非常にしやすい

つまりjavascriptの難読化するやつは悪人ってことですね

さらにもうちょい具体的に知りたいです
例えば
http://webassembly.studio/?f=adur0vruy59
（上タグのBuildでmain.wasm化できます）

入力値をnとすれば
instance.exports.main(n);

１を入力したら１２０
３を入力したら３６０
１０を入力したら１２００
という具合に、単にnに120掛けているだけ
というのは予測できるが、
nに　2*3*4*5　を掛けているのか、60*2 を掛けているのかetc
かどうかは、Build後のmain.wasmからは読み取れない
という認識で合っていますでしょうか？

協力会社の人に聞くことにします

強力な協力会社です

>>532
コンパイル最適化で定数の120にされるのでそれはわからない
わからないと言うか実際はただ120をかけてるだけ
でもそこが分かっても分からなくても大したこと無いだろうよ

>>535
＞コンパイル最適化
なるほど　ありがとうございました

JavaScript Lemmatizer
http://github.com/takafumir/javascript-lemmatizer

このライブラリは英語の動詞や名詞の原形を取得できるものですが

http://takafumir.github.io/javascript-lemmatizer/html/lemmatizer_sample.html

このサンプルページを実行しても、今のchromeだとエラーになって動作しません
どうすればいいのでしょうか？

変換テーブルだけ使わせてもらうのもアリかと思い>>539のソースを見てみたのですが、
どういう基準が選ばれたのか分からない、不思議な連語が結構含まれていて、謎みがあります
おそらく、元になったライブラリから流用されたものだと思いますが。
それでふと思ったのですが、語を一つ一つ英和辞典で引くことでも、変換テーブルは作成可能ですよね？
英和辞典なら、複数形で引けば単数形が出るし、過去形で引けば現在形が出るはずです
コマンドラインで引ける（プログラムから引きやすい）英和辞典はないものでしょうか？

自演臭い

そんなどこの馬の骨とも分からんような未メンテ放置のライブラリよりnaturalのstemmer使えよ。
http://github.com/NaturalNode/natural

>>541
「JavaScript 英語 動詞 原形」とかで検索したら最初に出てくるページですが？

>>542
ありがとうございます
語幹だけを取り出すプログラムはstemmerっていうんですね
そういうキーワードになる術語も知らなかったので助かります

IPFSで簡単なサイト作ってみようとして疑問に思ったことがあります
ajaxでよくある、クロスドメインの問題です
IPFSにjsファイルをアップロードして読み込む場合、
これはブラウザ側で許可する以外に方法はないのでしょうか？

ajaxでよくある、クロスドメインの問題です
ぐぐりましょう

node.jsのnaturalっていうのは、自然言語関係の一般的なアルゴリズムを集めたもので
辞書は含まれていないようですね
すべてをアルゴリズム的に処理するので、不規則動詞を原形にしたりは出来ないようです
WordNetにアクセスするモジュールもあったので期待したのですが
WordNeは意味を中心に語を体系づけたものなので、語の外形についての情報はないっぽいです・・

そうかそりゃすまんかった

いえいえ、キーワードを知れただけでも助かりました、ありがとうございます
WordNetというキーワードからPDICという辞書ソフトを見つけて
それ用の辞書はCSVとして出力可能なので、データソースとして使えるかも？というあたりまできました

これなら今週中の納期に間にあうかな？

というかwebapiに丸投げとかしちゃいけないの？