ふらっと C#,C♯,C＃（初心者用） Part131 [無断転載禁止]©2ch.net
レス数が950を超えています。1000を超えると書き込みができなくなります。
「どんなにくだらないC#プログラミングやVisual C#の使い方に関する質問でも誰かが優しくレスをしてくれるスレッド」です。
他のスレッドでは書き込めないような低レベルな質問、
質問者自身なんだか意味がよく分からない質問、
ググろうにもキーワードが分からないなど、勇気をもって書き込んでください。
内容に応じて他スレ・他板へ行くことを勧められることがあります。ご了承下さい。
なお、テンプレが読めない回答者は邪魔なので後述のC#相談室に移動して下さい。
C#に関係の無い話題や荒らしの相手や罵倒レスはやめてください
>>980を踏んだ人は新スレを建てて下さい。
>>980が無理な場合、話し合って新スレを建てる人を決めて下さい。
■前スレ
ふらっと C#,C♯,C＃（初心者用） Part130
https://mevius.2ch.net/test/read.cgi/tech/1500327645/
■関連スレ
C#, C♯, C＃相談室 Part94 [無断転載禁止]©2ch.net
http://echo.2ch.net/test/read.cgi/tech/1492843013/
■コードを貼る場合は↓を使いましょう。
http://ideone.com/
https://dotnetfiddle.net/
■情報源
https://msdn.microsoft.com/en-us/library/gg145045.aspx
http://referencesource.microsoft.com/ 皆さんありがとうございます
やっぱりweb系は覚えておいて損はないんですね
javascriptやphpはどうにも好きになれないんですが頑張ってみようかな。。 >>851
個人的には>>846が近いけど
何をやるにせよ新しいバージョンに対応した教材を TreeNodeで階層は分けれたのですがフォルダとURLの区別が付きません
お気に入りでURLとフォルダの区別をつけるようにするにはどうすればいいでしょうか？ >>853
Tagプロパティに何かしらのオブジェクトでも突っ込んどけ >>845
おれもLisp/JavaScriptに同意
JavaScript名前が某クソ言語に似ているが面白い言語だと思う。
海外のGeekたちがその毒気に当たって色々なライブラリーが開発されて今に至る。 需要は多いのにモジュールもろくに整備されないって変な言語だよな
Web系連中のいい加減さが現れた言語だ 最近は状況が変わって来てるよ
とにかく古い環境で古い知識を勉強するとロクなことにならん npm left-pad事件なんてわけわからんの起きるしなw >>851
Webアプリの本質的な所を理解するのにはc言語でcgiやるもの面白いぞ。 >>859
cgiレベルならCでもperlでもたいして違わない気がする
文字列操作が多い分Cでやってたら本質的でないところで面倒なだけだし >>860
c言語だとWebライブラリもないし全て自前で勉強にはなるだろ。
c言語でWebアプリなんか作っても難行苦行でしかないから作らんけどね。
サイボウズはc言語で作られてるらしいね。 べつに、perlでやってもライブラリ使わなきゃWebの勉強としては変わらんだろ。 C言語でやるメリットってあるのかな
サイボウズってそんなにCPU使うようなサービスだっけ >>863
サイボウズは20年も前に開発されたものだからな。
当時はc言語のcgiなんて普通にあった。2chもそうだったし。 「初心者の質問スレ」で「C#に関係ない話題はやめてください」
>>844みたいなのはマ板でやれよ。板の意図とも違う >>861
なんでいきなりWebライブラリの話が出てくるんだよ w
cgi って言ってるんだからhttpヘッダー+生のhtmlでやるって話だろ プログラムの勉強にC#で簡単なアプリ作ってみたのだけど、配布する前に難読化した方がよいと聞いてConfuseEx試してみたらマルウェア判定されて即消されちゃうのだけど、どうしたら難読化したアプリを配布出来るのか教えて下さい
もしかして難読化する方が少数派なのでしょうか？ >>868
難読化はITリテラシーの低い経営者を狙った詐欺
C#じゃ難読化しても技術保護にはならないし
そもそもリバースエンジニアリングされるほど高尚な物じゃないだろう？
本当に保護したい技術はサービスとして提供して物は一切公開しない >>868
何故難読化するのか理由がちゃんとあるのか？
隠さなければならないコードがない限り普通は難読化しない 難読化ってリフレクションには影響無いのか?
例外のスタックトレースまで難読化されるんだろ。 C#で難読化とか吹き込んだ奴に聞けよ
まともなコンサルなら耐タンパー性が必要ならまずC/C++で開発しろと言う 難読化ツールなんて誰も使ってないのが良く分かったw 偉そうにしょうもない解答する奴は馬鹿だから無視していいよw 難読化って言葉通り読み辛くしてるだけだからな
初心者じゃなければ解析できるんだからあまり意味がない フロー難読化もあるから初級者上級者関係ない
解析は根気があるかどうかが問題だよ やはり普通やらないような事なのですね
なんとなくですが理解しました！
アプリ内に書いてある文字列で別のアプリで暗号化したものを復号化してみるアプリだったのですが、文字列が丸見えらしく知り合いに聞いてみたら難読化してみたら？との事でした
要は文字列だけ隠したいのですが何かしら方法はあるものなのでしょうか？ >>879
本来の意図が分からないが元のアプリ内の文字列を最初から暗号化したら済む
解析もできないようにしたいのだったら難読化だろうが何だろうが無理
手間がどれだけかかるかだけの違いしかない パスワード c# プログラム内
でググったら
ハッシュがどうのこうのってのは出てきた
使えるかな？ 俺が書いたコードは難読化しなくても誰にも理解出来ないよ。 >>879
それは難読化じゃなく暗号化
君もだけどその知り合いもしばいときな ツールを使ってjsのコードを難読化し、ユーザーはツールを使ってそれを可読化する
人間って面白いね >>879
そもそも、復号キーをコードの中に埋め込んでいるのが間違いだろうけどね。
復号キーを暗号化しても復号アルゴリズムがコードの中にあったら無意味だよ。 >>887
そういう場合は秘密鍵をサーバーに、プログラムには公開鍵だけを持たせるやり方が簡単
ネットを介さない環境で使用するアプリとかなら仕様がわからんんがキーコンテナを使え みなさまありがとう
アプリAで暗号化、アプリBで復号化、他者はBしか持っていないという状況を想定して、アプリB内の復号化に使う文字列をなるべく隠したくて質問させて頂きましたが難しそうですね
いろいろ素人なりに調べてみたけれどやはり秘密鍵をどうにかサーバーに置いておくのが良さそうに感じました
ただ適当なサーバーに適当に秘密鍵をアップしてもあまり意味なさそうなのでその辺りもよく考えないとダメそうですね…
ゆくゆく作りたいアプリのために始めてみましたが、ある程度解析しづらいらしいC++などで最初から考え直しても良いのかもしれません
アドバイスありがとうございました >>890
鍵を外部ファイルにすればいいだけだろ
なんでcでやるとかサーバー使うみたいなトンチンカンな方向に行ってしまうんだ >>891
外部ファイルだと中身見れるから意味ないだろバカか 外部ファイルが許されるのは入力パスワードに対してのハッシュくらいだろ
879の案件には合わない Bで作った公開鍵をAに渡して暗号化させればいいだけの話でないのん
秘密鍵だけで無理にやろうとするから当たり前のように無理が出るのでは まあ、厳密にはその場合でも、一時共有鍵は使うだろうけど >>896
トンチンカンなバカレスするお前は初心者以下 ID:KtpP5XlM はただの荒らしだろ
もう構うな >>887
無意味ではないよ
文字列抜き出すのとアルゴリズムの解析とでは
必要な時間が全く違うからね
それこそ難読化の出番 >>890
Aに秘密鍵、Bに公開鍵で。
Aの秘密鍵を守る対策は別途必要 埋め込みでリソース持つのと、外部ファイルで持つのってセキュリティそんなに変わらんでしょ？ そもそも暗号化手順＋暗号キーを知られたくないならまだしも暗号キーをとにかく知られたくないというのが分からない
元の質問者は終了宣言しているし外野が条件変えながら議論しても無意味 暗号化通信の基本もわかってないのにプログラマ名乗っちゃダメだろ君たち 公開鍵で暗号化プログラムA
秘密鍵で復号プログラムB
Bの利用者は鍵ペアを生成
外部ファイルとして秘密鍵をプログラムに渡す
公開鍵を通信相手に渡す
終わり コード書けりゃプログラマじゃないぞ
お前らはC#なんてやっとらんでITパスか基本情報でも取ってこい >>911
だからそれなんの意味があるんだよ w
>>906の意味わかってないのか？ if(HashPasswordForStoringInConfigFile(パスワード, "sha1").ToLower() == ハッシュ文字列)
{/*編集可能処理*/}
って書いてあった >>916
>>879のデータの暗号化とパスワードの認証は別の話
ハッシュで認証するから元のパスワード持っていなくていいよ、てのはわかるが 認証したいなら個別に別ルートでパスワード発行
ユーザー全員に共通パスワード持たせたいならセキュリティ諦めてリソース持つぐらいで十分
できれば中間にAPI噛ませて何かあった時の被害をコントロールできるようにしておいたほうがいい >>917
単純にテキストだけの話なの？
バイナリファイル読み込め的な？ 以前List<T>オブジェクトをXmlシリアライズ・デシリアライズする拡張メソッドを作ったのですがユーザー定義クラスのときだけ動きません
public static void SaveXml<T>(this List<T> list, string path)
{
T[] xmldata = list.ToArray();
using (FileStream fs = new FileStream(path, FileMode.Create))
{
XmlSerializer xml = new XmlSerializer(typeof(T[]));
xml.Serialize(fs, xmldata);
}
}
こういった感じでList<MyData>型の変数myDataList.SaveXml("D:\hogehoge.xml")と呼ぶとxml.Serialize(fs, xmldata)のところで
System.InvalidOperationExceptionが投げられます。ただのList<string>型の場合投げられません。
どこがまちがっているでしょうか？ とりあえずその投げられた例外をToString()して全部読んでみて >>911
はあ？
秘密鍵丸見えじゃ無意味って理解出来ないの？ >>923
違う用途ならともかくこの件においては
データ改変できて無意味 >>920
型以外の条件を一切変更していないのに（ダメな人は他の条件も変えてたりするから困るw）
TがMyDataの場合だけ例外は発生するのであれば、
普通に考えてMyDataがXMLシリアル化可能な条件を満たしてないんでしょう。
例えばデフォルトコンストラクタがないとかそもそもpublicなクラスじゃないとか。 >>926
は？
間違ったやり方をやるわけないだろバカ >>921
できなかったのはコンストラクタ定義していたせいでした、すいません 馬鹿の壁みたいだ
初心者のためにかくと
公開鍵は暗号化する鍵で誰にみせてもいい
秘密鍵は暗号を解く鍵でみせてはいけない
B利用者は自分のための公開鍵と秘密鍵を作る
作った秘密鍵をプログラムBに渡す
公開鍵は誰にでも渡してプログラムAで鍵をかけてもらったものを送ってもらう
B利用者は送られたものをプログラムBで鍵を解く
送った内容は秘密鍵を持ってないと中身がみえないので安全 命名スレで暴れてた馬鹿おじさん
こんなところにいたのか 秘密鍵を相手に渡すのは馬鹿の極み
公開鍵は誰に見られてもいいので
難読化とかそういう以前の問題
セキュリティがどうこう言う前に勉強すべき
プログラムBが公開鍵持ってても何の問題ない >>929
アスペか？日本語すら出来ないバカは死んでろ
生きてる価値も意味も皆無だから 馬鹿は馬鹿同士でお互いにバカにしあっていればいい
俺は横から初心者のために解説してるだけ 実にどうでもいい話だけど、元の質問者のケースは別人の間の通信ではないので、
公開非公開の区別の意味はないね。
この分野全然知らんけど、サーバーに復号化のための情報を置いたら安全って発想は
ちょっと理解できんなあ。
それってハッキングする側から見たら、単にサーバーの認証を突破するひと手間が
増えただけの話じゃないの？ >>938
多分適当にググれば10分ぐらいで何を言ってるかわかるよ >>933
ユーザーに改変されたくないデータをやり取りする場合そのやり方だと無意味 うっわ無知な馬鹿に絡まれた
最悪・・・
無知でも考えれば何とか答えが出るのに… >>938
最初から読めばファイル配布の稚拙なシステム作ろうとして注意されたのが分かる
多分本人は問題の本質に気付いていない
そしてこの問題はC#以前の話 人間の基本行動原理
自分だけはバカじゃないという前提
自分だけは誰よりも常に正しいという前提 パブリックキーで暗号＆復号化するのはパケットの話
サーバに収めるデータやDBは別 >>938
そうじゃなくてサーバーに復号化の情報を置くのではなくサーバーで復号化させるってこと
A-B間で直接やり取りできるなら別にサーバーじゃなくてもいい
どうでもいいけど質問者の案件の詳細がわからない限りこれ以上の言い争いは不毛だぞ サーバーで復号したものを安全にBに持ってくるにはまた暗号化が必要なんでは？ ようやく自分の誤りに気づき終息させようとするの術
その前に嵐扱いした人に謝ったほうがいいんじゃないかなｗ >>949
一時的な暗号鍵を使う
その鍵は保存されないしユーザーにはわからない レス数が950を超えています。1000を超えると書き込みができなくなります。
