C#, C♯, C＃相談室 Part96

2021/12/20(月) 11:03:25.88

!extend:checked:vvvvv:1000:512
!extend:checked:vvvvv:1000:512

■Visual Studio 2017 Community(無償の統合開発環境)等はこちら
http://www.visualstudio.com/downloads/

■コードを貼る場合はこちら
http://ideone.com/

■前スレ
C#, C♯, C＃相談室 Part94
https://mevius.5ch.net/test/read.cgi/tech/1553075856/

■次スレは>>970が建てる事。
建てられない場合は他を指定する事。

VIPQ2_EXTDAT: checked:vvvvv:1000:512:: EXT was configured

2022/12/20(火) 16:05:38.86

>>937
どうやってやるの？

2022/12/20(火) 16:15:34.10

>>940
難易度ならそこまで変わらん

2022/12/20(火) 16:17:27.75

>>943
Regex.Replaceのオーバーロードにラムダ式を取るやつがあるから引数をキーにしてDictionaryから置換先を取り出せばいい

2022/12/20(火) 16:42:37.80

>>938
今のところネイティブコード作れるのはコンソールだけってのをどっかで見た記憶がある
違ってたらごめん

2022/12/20(火) 16:57:50.13

>>945
なるほど、サンクス

2022/12/20(火) 17:06:16.44

>>942
ストアアプリも読める？読めたらまずくない？

2022/12/20(火) 17:17:31.72

半分自己解決。UWPはnative codeになるようだ
非UWPはまだわからん。
.NET nativeのおかげだな。.NET7では全アプリ対応になってるのかも

https://microsoft.github.io/react-native-windows/docs/native-code
UWP apps written in C# or other managed languages submitted to the store must be built using the .NET Native toolchain. This is the default when building C# apps in Release mode, but not in Debug, so apps built in Debug will be rejected by the Store.

2022/12/20(火) 17:21:11.68

native codeじゃないと商用アプリリリースする気にならないわ
認証まわりとかコード見られたくない

.NET7でもしWPFとかもnative codeふつうにはけるのなら
c#人気復活する気がする

2022/12/20(火) 17:32:16.50

盗んだコードで売りに出す♪

2022/12/20(火) 17:33:48.40

>>948
visual studioで空のUWPプロジェクト作って
releaseで.NETネイティブツールチェインをオンにして生成されたApp1.exeをILSpyで見ても
普通に中身見れるなｗ

2022/12/20(火) 17:33:58.25

>>942
難読化を強い設定にしたらILSpyでファイルを開いただけじゃソースコードは読めないよ

2022/12/20(火) 17:37:55.97

>>952
MSのストア側でnativeになるとかじゃない？

2022/12/20(火) 19:28:27.61

C言語でボードゲームを作成する課題についてです。重力付き4目並べを最終的にコンピュータと対戦可能にするように、テンプレートのコードに穴埋めしていく課題です。
①横7x縦6の盤面を立てて使用②2人で対戦、以下の0~6のマスを交互に選択③縦横斜めいずれか4コマ並べれば勝ち。以下はテンプレートのコードです(長いので続きはGoogleドライブにも置いてます)、これらの空白部分の穴埋めが分かる方、どうか教えてくださいお願いします。元テンプレコード↓→ https://drive.google.com/file/d/1bTnbssantyf9dEV5DOugZuloiVUh7H3D/view?usp=share_link
#include <stdio.h>
#include <stdlib.h>
#include <time.h>
#define YMAX 6 // 縦方向のマス目の数
#define XMAX 7 // 横方向のマス目の数
int board[XMAX][YMAX]; // 0:未着手 1:先手のコマ● 2:後手のコマ○
int num[XMAX]; // 各列に置かれているコマの数
int choice = 1; // 0:未選択
// 1:人間(先手●)対人間(後手〇)
// 2:人間(先手●)対コンピュータ(後手〇)
// 3:コンピュータ(先手●)対人間(後手〇)
int turn = 0; // 先手か後手かを判定するための着手数
void InitBoard(void);
void DispBoard(void);
int CheckFull(void);
int SetXpos(int);
int CheckBoard(int, int, int);
int ComputeXpos(int);
int SearchConnect(int, int);
int main(void)
{
int xpos; // 入力したコマの置き場所，またはコンピュータが探したコマの置き場所
int player; // 1:先手の手番 2:後手の手番
int win = 0; // 0:プレイ中 1:先手の勝ち 2:後手の勝ち 3:引き分け
int ans;
while (1)
{
srand((unsigned int)time(NULL)); // 乱数を使う場合のseedの初期化

長いので続きはGoogleドライブにあります→ https://drive.google.com/file/d/1bTnbssantyf9dEV5DOugZuloiVUh7H3D/view?usp=share_link

2022/12/20(火) 19:43:57.01

>>955
名前とはうらはらにC#とCはぜんぜん違う
ここで聞くべきではない

2022/12/20(火) 19:53:21.19

課題についてですが

2022/12/20(火) 19:56:57.69

パクられるほどのアプリなんだろうか。
今日日、割られるとしたらパッチが広まるのも一瞬なんだから、それよりもちゃんと利用規約書いた方が良いんじゃないの？
はるかに金払うと思うよ。特に企業内ユーザは。

2022/12/20(火) 20:36:05.36

>>958
流行ってきてもすぐにコピーアプリつくられたら
収益激減しちゃうでしょ
利用規約なんて書いても少し変えてコピーアプリつくられたらおしまいだよ
実害がはっきりでる
例えば300円のアプリ、コピーされて100円で売られたらこっちは大損だよ

2022/12/20(火) 20:36:09.48

困るほど割られるならサーバー用意して認証するかな、俺なら
まあそんなアプリを公開できるとも思わんから取らぬたぬきなんだけどw

2022/12/20(火) 20:38:13.57

>>960
native codeじゃないとかんたんに
サーバーの認証のコードが漏れちゃうでしょ
セキュリティ大事

でもNET7でようやくC#でnative codeをMSが許可したのは大きいね

2022/12/20(火) 20:43:25.99

クライアントにAPIキーをハードコードしてるのか？ユーザー認証を実装しろよ
そんな初歩的な設計ミスしといてセキュリティもクソも

2022/12/20(火) 21:05:09.19

>>961
もしかして認証ってクライアントからサーバーにログインするような奴しか知らんのか？

2022/12/20(火) 21:41:02.29

>>955
馬鹿は死ね

2022/12/20(火) 21:55:47.97

>>959
実際Windows以外ではアプリ作っててそこそこダウンロードされてるけど、コピーアプリが追いついたこと無いぞ。
単純に品質と知名度でしょ。

2022/12/21(水) 02:19:07.37

.NET 7のNative AOTは今のところコンソールアプリとクラスライブラリで使えるらしい
今後範囲を広げていく計画だったと思うが
現状でWindowsアプリでも重要な部分だけクラスライブラリにすれば上で求められてることはできそうだな

2022/12/21(水) 08:11:43.60

>>966
それはちょっと誤解がある
NativeAOTはコンソールアプリとして発行されるアプリケーション、もしくは(.NETのクラスライブラリではなく)ネイティブの共有ライブラリを作るときだけ使える
つまり、仮にWindowsアプリで部分的に使うならPInvokeが必要
なお、NativeAOTはASP.NET Coreアプリを動かすことをゴールとしており、GUIアプリのサポートは全く計画にない

2022/12/21(水) 08:21:41.02

ネイティブのDLL作れるのはええな
わざわざその為だけにC++使う必要なくなるかな

2022/12/21(水) 10:09:22.51

ソースが見られるのを恐れてるのはパクられるのを恐れてるんじゃなくパクったのがバレるのを恐れてるんだよな
お前なんかの作った物をパクるやつなんかいねーよと言いたくなるやつしか難読化難読化言わない

2022/12/21(水) 10:17:43.01

あと.NETのリバースエンジニアリングがしやすいのは静的ライブラリじゃなくDLLを使ってるのと仮想メソッドを多用しているのも大きい
DLLで提供されるクラスを使う時や仮想メソッドを使う時は名前でアクセスせざるを得ないからどのクラスのどのメソッドを使っているかを隠すことができない
これはC++を使っても同じこと
本気で難読化したいなら標準ライブラリを使うのをやめた上でソースコードジェネレータを使ってソースレベルでクラス名や関数名をランダマイズするところから

2022/12/21(水) 10:20:28.49

https://mevius.5ch.net/test/read.cgi/tech/1671585518/
立てたけどこれ過去スレの履歴要らんだろ

2022/12/21(水) 10:50:38.22

>>967
ASP.NET Coreは.NET8でnative AOT対応してくるかもしれない。
Azure運営してるMSとしては欲しい機能だろうし。
GUI appsもゴールにないという事はないと思うよ
やっぱり速度とかメモリ使用とかでnative有利だし。

MAUIで作ったiOSかMacアプリはnative codeでbuildされるとか見た記憶ある。
他社がnativeで動くならGUI appも対応しないとc#開発者がC#使うのをやめてしまう。

2022/12/21(水) 10:52:45.19

ここみると.NET7の制限というニュアンスで書いてある。
最終的にはふつうのWPFとかもnative AOT目指してるように思える。
https://learn.microsoft.com/en-us/dotnet/core/deploying/native-aot/

2022/12/21(水) 10:54:27.51

>>969
コード見られるのを気にしない人はセキュリティに関して知識と意識が低いだけだと思う。
必要のない情報は極力見せないっていうのがセキュリティの基本だ。

2022/12/21(水) 10:59:36.26

>>974
何のセキュリティを気にしてんだよw
セキュリティの意味わかってないんじゃね？

2022/12/21(水) 11:21:48.38

>>974
その理論だとつまりオープンソースはセキュリティが低すぎて使い物にならないってことだな

極力見せない以前に、見せていいものと悪いものの判断ぐらいできるようになれよ

2022/12/21(水) 11:38:04.02

>>971
それよりVS 2017 からバージョンさせてほしい

2022/12/21(水) 11:46:13.92

まあ認証まわりとか、ライブラリを使ってるのか自作なのかすら見せたくないのはわかる
個人のアプリじゃないと重箱の隅をつつかれることにもなるしね

2022/12/21(水) 12:14:36.58

カジュアルな解読対策なら既存の難読化で十分だし、ガチのクラッカー相手ならマシン語になった程度じゃ無駄だよ

2022/12/21(水) 12:52:16.33

そもそもターゲットになるようなアプリを公開できる奴がこんなスレにいるのかと...

2022/12/21(水) 14:51:10.30

native AOTはスピードアップの恩恵も大きい。
C++くらい速いコードになるし欲しいに決まってる

2022/12/21(水) 15:00:09.00

ならんと思うよ
C++は最適化のやり方がえげつないし安全より速度に倒してるから

2022/12/21(水) 15:01:27.23

最適化に関しては言語単位ではなくコンパイラ次第だけどな

2022/12/21(水) 15:04:48.89

C言語でボードゲームを作成する課題についてです。重力付き4目並べを最終的にコンピュータと対戦可能にするように、テンプレートのコードに穴埋めしていく課題です。
①横7x縦6の盤面を立てて使用②2人で対戦、以下の0~6のマスを交互に選択③縦横斜めいずれか4コマ並べれば勝ち。以下はテンプレートのコードです(長いので続きはGoogleドライブにも置いてます)、これらの空白部分の穴埋めが分かる方、どうか教えてくださいお願いします。元テンプレコード↓→ https://drive.google.com/file/d/1bTnbssantyf9dEV5DOugZuloiVUh7H3D/view?usp=share_link
#include <stdio.h>
#include <stdlib.h>
#include <time.h>
#define YMAX 6 // 縦方向のマス目の数
#define XMAX 7 // 横方向のマス目の数
int board[XMAX][YMAX]; // 0:未着手 1:先手のコマ● 2:後手のコマ○
int num[XMAX]; // 各列に置かれているコマの数
int choice = 1; // 0:未選択
// 1:人間(先手●)対人間(後手〇)
// 2:人間(先手●)対コンピュータ(後手〇)
// 3:コンピュータ(先手●)対人間(後手〇)
int turn = 0; // 先手か後手かを判定するための着手数
void InitBoard(void);
void DispBoard(void);
int CheckFull(void);
int SetXpos(int);
int CheckBoard(int, int, int);
int ComputeXpos(int);
int SearchConnect(int, int);
int main(void)
{
int xpos; // 入力したコマの置き場所，またはコンピュータが探したコマの置き場所
int player; // 1:先手の手番 2:後手の手番
int win = 0; // 0:プレイ中 1:先手の勝ち 2:後手の勝ち 3:引き分け
int ans;
while (1)
{
srand((unsigned int)time(NULL)); // 乱数を使う場合のseedの初期化

長いので続きはGoogleドライブにあります→ https://drive.google.com/file/d/1bTnbssantyf9dEV5DOugZuloiVUh7H3D/view?usp=share_link

2022/12/21(水) 15:06:36.41

>>979
マシン語のリバースエンジニアリングできるやつなんて
プログラマーの1%もいないだろうし時間もかかるからほぼ回避できる。
解析する行為が割に合わなくなる
C#難読化だけとは安心度が全然違う

2022/12/21(水) 15:08:08.84

>>984
しつこい
死ねよ

2022/12/21(水) 15:46:41.58

>>986
ごめんち

2022/12/21(水) 15:57:46.46

>>985
マシン語に夢見すぎだしCのソースコードにデコンパイルできるぞ

2022/12/21(水) 16:15:55.40

まあガチで最適化されてたらまともなCコードにはならんけどね

2022/12/21(水) 16:23:28.08

>>989
少なくとも文法はCになる

2022/12/21(水) 20:14:45.78

文法はCだけど中身はマシン語と変わらないなら地獄だけどそういうものになるんだろ？

ifとgotoとreturnとラベルだらけ

2022/12/21(水) 20:17:20.13

式は漏れなく逆ポーランド記法的になるんだろうし

2022/12/21(水) 20:23:34.31

自分でやってみればわかるが、言うほど難しくない。

2022/12/21(水) 20:27:18.93

と言う妄想

2022/12/21(水) 21:29:01.38

Cとアセンブラの最も大きな違いはレジスタへのアクセスなんだよね。

2022/12/21(水) 21:48:30.78

>>994
慣れだよ。CTFとかやったら良い。

2022/12/22(木) 02:21:30.51

>>995
レジスターやスタックを気にしながらプログラムを組むのは地獄だわな

2022/12/22(木) 02:36:34.84

C++も終わりになるんじゃないの？
LinuxがRustで書くようになるとかいう噂？ニュースを見たよ
RustってOSも書けるんだな
Rustで安全で高速なコード書けたらC/C++ほぼ要らなくなるんじゃ？

2022/12/22(木) 02:37:22.51

>>999
LinuxのカーネルがRustで書かれるかもっていう噂、ニュースね

2022/12/22(木) 02:43:23.22

次
C#, C♯, C＃相談室 Part97
https://mevius.5ch.net/test/read.cgi/tech/1671585518/

**1001** · Over 1000

このスレッドは１０００を超えました。
新しいスレッドを立ててください。
life time: 366日 15時間 39分 58秒