プログラミングについて話すスレ - 1079320292

1：名無しさん：2004/03/15(月) 12:11: なんでも
2：升屋な名無しさん：2004/03/21(日) 21:26: 図書館で「COM/DCOM 実践プログラミング」を借りてきました。
全然読んでないけど。COMのフックも全然取り掛かってません。
「WinSock2.0 プログラミング」も借りてきました。
これも全然読んでません。WSARecvとWSAOverlappedResultだけ
わかってればいいやｗ
3：升屋な名無しさん：2004/03/22(月) 10:38: おいらも、WSARecv,WSASendとWSAOverlappedResultだけしか読んでませんｗ
COMの方はアドレス固定式ってのが気に食わないけどフックできちゃったんで、
もうどうでもいいって感じｗ

自分でCOM使うことは、周りが全部COMにならない限り無いだろうな～
4：升屋な名無しさん：2004/03/25(木) 21:51: たしかに、
DirectXとか使ってプログラミングするならCOMは使わざるを得ないけど、
そうでないなら自分でCOMを作る事はまずないでしょうね。DLLで十分だし。
そのうちCOMは消えるそうです。聞きかじりですが、.NETとかいうわけの
わからんものに取って代わられるそうです。
5：升屋な名無しさん：2004/04/04(日) 20:06: 「WinSock2.0 プログラミング」他の箇所も読んだら、
結構(･∀･)ｲｲ!感じだったのでつい買ってしまいました。
5800円なり。winsockレベルでプログラム書いて見たく
なってしまった。
6：升屋な名無しさん：2004/04/04(日) 23:08: おいらは、まんどくさいんでコンポーネントで出来る事は全部やってもらいまつｗ
7：升屋な名無しさん：2004/04/08(木) 02:03: 寝ﾏｸﾛ中に異常があったら携帯鳴らしてくれる機能
いいですね。
8：升屋な名無しさん：2004/04/08(木) 21:59: コンポーネント使えば直ぐに出来るよ
9：升屋な名無しさん：2004/04/08(木) 23:44: それが、うちの開発環境にはメールコンポーネントついてないのよ。
(´･ω･`)。ソケットコンポーネントはあるのだけど。
だから、SMTPのプロトコル調べてちまちまと作らないといけないので、
ちとまんど臭いのですorz
10：升屋な名無しさん：2004/04/09(金) 12:03: ﾗｸﾞﾝｼﾞｬｰのDLｻｲﾄ教えてーーーーー
11：升屋な名無しさん：2004/04/09(金) 17:24: ttp://www.ne.jp/asahi/mars/phoebe/
検索でLagngerで出るけど。
12：升屋な名無しさん：2004/04/16(金) 20:10: エタカはさすがにもういいや。
次はリネやろうかな。
でも、リネの升ツール作るのまんどくさそうなんだよね。
それともWPEみたいなツール作ろうかな。
もちろん、WinSock2.0対応でWSARecv完璧対応のやつ。
でも、需要はありそうだけど、これもまたまんどくさそうだなorz
13：升屋な名無しさん：2004/04/17(土) 01:14: 最近のゲームは暗号が標準装備みたいになって来たんで
WPE風のツールでは力不足になるんじゃないかな
個別に暗号対応できるように、susieのプラグインのような機能があれば
大丈夫だと思うけど
14：升屋な名無しさん：2004/04/17(土) 14:51: ですね。今までやったネトゲの中で、暗号が
掛ってなかったのは巨商伝とコルムかな。
リネの暗号が一番コワヒ。そこまでやるのかと。

今思いついたんだけど、いろんなネトゲのパケ
の暗号解読出来る人募集して升軍団作りたいなｗ
15：さむらい鼠：2004/05/03(月) 11:43: OS間の差異を吸収するのってものすごく、まんどくさいのね(-_-;)
ＸＰでは動くのに９８だとめっちゃくちゃ変な動作するんだよね。
困ったもんです。
16：升屋な名無しさん：2004/05/11(火) 18:23: Winnyの作者がﾀｲｰﾎされちゃったね。びっくり。あんなプログラム書けるなん
て天才だと思う。東大の助手だったんだと。残念ですねぃ。
ﾀｲｰﾎの理由がこれまたわけわからんかった。著作権違反幇助罪？無理やりな
法律解釈を適用した感じ。そんなのあんのかと。でも、仕方ないんでしょう
ね。
17：升屋な名無しさん：2004/05/14(金) 23:15: OS間の壁を着々と克服してますな。すごいです。
おいらのＤＬＬのWin2000限定もなおしてくだたいｗ
18：升屋な名無しさん：2004/05/16(日) 06:21: >>17
こんど、DLLをCからパスカルに移植してみようかな。
ほとんど、やる気ないけどｗ
でも、パスカルだと遅そうな気がするんだよね。そ
んなことないですかね。移植できたら、ソース送り
ますねｗ
19：さむらい鼠：2004/06/09(水) 20:42: 童話王国の解析してるんだけど、カーバﾉﾚさんにどんどん
遅れとってるよぉ。デバッガ使いこなすのって難しいな。
なんでカーバルさんはあんなに仕事が早いのだろうか？ア
センブラ見てパッとやってることがわかっちゃうのかな。

でも、童話つまんないｗ　何か他のゲーム探そうかなorz
20：升屋な名無しさん：2004/06/09(水) 22:16: ターゲットのＡＰＩを探したら、その前後のループの先頭とかにブレークポイントを
置いて、どこでそのデータが作られてるのか場所を突き止めてます。
「ＡＰＩ発見」→「ＡＰＩのデータを書き換えてるＣａｌｌ場所発見」→
「コール先のＭＯＶ命令発見」ってパターンです。
「暗号 ⇔ 平文」を一文字ずつ書き換えてるＭＯＶ命令が見つかれば、その前後をノートに
メモリ、レジスタがどう変わるのか１行ずつ書き出しながらやってます。
頭の中だけでは４，５行読んだら最初の行の内容を忘れますｗ

あとね、有利なのはシーケンサで使ってた応用命令は、ほとんどアセンブラなので
命令名を見ればだいたい、その命令は何をする命令なのか？ってのは判ります。
21：さむらい鼠：2004/06/11(金) 19:22: // レシーブしたパケットをデコードする。
// numOfTable : 何枚目のテーブルを使うか。
// key : デコード用の暗号キー
// buff1 : パケットのバッファー
// buff2 : パケットのバッファー
// len : バッファーのサイズ

BYTE* pTable;//デコード用テーブル先頭へのポインタ

char DecodeRecvPacket(int numOfTable, DWORD key, DWORD* buff1, DWORD* buff2, int len)
{
int a;//暗号キーの処理結果を格納する変数
int b;//for文のカウンタ
int c;//バファ退避用

for(b = 0; b < len; b++){
//暗号キーの下位1バイトをビット操作
if ((a = key & 0x0ff & 0x80000007) < 0){
a--;
a |= 0xfffffff8;
a++;
}

//バッファを書き換える
(BYTE)buff1[b] = (BYTE)(pTable + numOfTable * 256 + (BYTE)buff1[b]);

if( key & 0xff & (1 << a) != 0 ) {
c = (BYTE)buff1[b];
//バファを書き換える
(BYTE)buff2[b] = (BYTE)((BYTE)buff1[b] ^ (key & Oxff));
//暗号キーの下位1バイトを書き換える
key = key & (BYTE)c;
continue;
} else {
if ((a = key & 0xff & 0x80000003) < 0){
a--;
a = a | 0xfffffff8;
a++;
}
}

if (key & 0x0ff & (1 << a) != 0 ) {
c = (BYTE)buff1[b];
//バファを書き換える
(BYTE)buff2[b] = (BYTE)buff1[b] - (key & 0xff);
//暗号キーの下位1バイトを書き換える
key = key & (BYTE)c;
continue;
} else {
c = (BYTE)buff1[b];
//バッファを書き換える
(BYTE)buff2[b] = (BYTE)((BYTE)buff[b] + key & 0x0ff);
key = key & (BYTE)c;
}
}

return key;
}
22：さむらい鼠：2004/06/11(金) 19:23: うわ。コピペしたらインデント狂ったｗ
23：さむらい鼠：2004/06/11(金) 19:38: 関数の戻り値型はcharじゃなくて,intでしたね。
なんか他にもいっぱい間違いありそう。
どなたか添削よろしこｗ

暇だったので丸1日かけて解析してみました。
ｾﾞｴｾﾞｴﾊｧﾊｧ。
やっとアセンブラに少し眼が慣れて来た感じ。

次は、この関数を呼び出すプロシージャを解析して、
その後は、Sendのエンコード方式を解析しないといけ
ない…。なんか1週間は掛りそうｗ　ムリポ…。
カーバﾉﾚさんは、これを全部1日で解析しちゃうんですね。
24：升屋な名無しさん：2004/06/11(金) 23:15: Ｃは良くわかんないけど、そんな感じだったぽ。
解析には２、３日くらい掛かってます。初めに大体の感じをつかんで
面倒くさそうなんで放置して、しばらくしてから悔しくなって詳しく
解析しましたｗ

片側でデコードパターンをつかむと、反対のSend側は比較的サクサク
出来ると思いますよ。

あと、おいらの解析は、トライアンドエラーの繰り返しってのもあり
ます。Delphiで適当にデコード回路組んでやってみてダメだったら
修正の繰り返し。この作業中は深く検証せず、思いつきでもチャレンジ
してたりしますｗ
で、うまくいったときには完成！ってなってますｗ
25：さむらい鼠：2004/06/13(日) 09:58: Recv側の暗号キーはパケごとに、鯖から送られてくる
んですね。なんか不思議な仕様。
レシーブしたパケの1バイト目がキー。そのキーを
10で割った余りが、何枚目のデコードテーブルを使う
のかを決定する数値。テーブルの内容は、005F9180か
らの.rdataセクションに書いてあるのでそのまま使え
そうですね。

いまは、Send側をやってます。かなりアセンブラに眼
が慣れてきたﾎﾟﾙﾇ(^o^)
26：さむらい鼠：2004/06/13(日) 14:22: var
pTable: PChar; //テーブルへのポインタ

//Sendパケをエンコードする関数。
//num:何枚目のテーブルを使うかを指定する。
//key:暗号キー
//buff1:バッファ
//buff2:バッファ
//len:バッファの長さ
function EncodeSendPacket(num :Integer; key :Char; var buff1 :PChar;
　　　　　　　　　　　　var buff2 :PChar; len :Integer):Char;
var
　　i :Integer;
　　tmp :Integer;
begin
　　for i := 0 to len - 1 do
　　begin
　　　　tmp := ord(key) and 7;
　　　　if (ord(key) and (1 shl tmp)) <> 0 then begin
　　　　　　buff2[i] := Char(ord(buff1[i]) xor ord(key));
　　　　　　key := buff2[i];
　　　　　　buff2[i] := pTable[num * 256 + ord(buff2[i])];
　　　　　　continue;
　　　　end;

　　　　tmp := ord(key) and 3;
　　　　if (ord(key) and (1 shl tmp)) <> 0 then begin
　　　　　　buff2[i] := Char(ord(buff1[i]) + ord(key));
　　　　　　key := buff2[i];
　　　　　　buff2[i] := pTable[num * 256 + ord(buff2[i])];
　　　　　　continue;
　　　　end;

　　　　buff2[i] := Char(ord(buff1[i]) - ord(key));
　　　　key := buff2[i];
　　　　buff2[i] := pTable[num * 256 + ord(buff2[i])];
　　end;
　　result := key;
end;
27：さむらい鼠：2004/06/13(日) 14:43: sendの場合は１バイトずつ上の関数が呼ばれる。

パケットの１バイト目と２バイト目が特別な意
味を持っていて、３バイト目からがデータ本体
ぽ。この関数を呼び出す側の処理を解析しない
と１バイト目と２バイト目の意味がわからない。
予想では、１バイト目がキー、２バイト目がテ
ーブルナンバーを導き出すキー。
28：升屋な名無しさん：2004/06/13(日) 19:59: なぬ！
パケの1、２バイト目にそんな秘密があったとは！
まったく気付いてませんですたｗ
29：升屋な名無しさん：2004/06/15(火) 01:27: なんか、違うような気がするぽ
30：さむらい鼠：2004/06/15(火) 16:39: orz
31：さむらい鼠：2004/06/15(火) 17:56: デバッガーでアセンブラ見て解析してるばかり
でなく実際のパケを見ないと、解析も捗らない
ということがいまさらながら、よくわかって来た
今日この頃。
パケ横取りソフトを作ってみようかな。面倒だな～。

ところで、1バイト目、2バイト目の意味はともかく、
3バイト目からデータ本体が始まるっていうのは間違
ってるでしょうか？
32：升屋な名無しさん：2004/06/15(火) 22:37: わかった！
その部分はゲーム前のログイン情報の部分だよ。
ゲームが始まってからは、そのデコードコールは使われなくなり
その下のコール文でデコードが実行されます。

＞3バイト目からデータ本体が始まる
そこがまた落し穴なんですよｗ
その部分がおいらの６月８日の日記ですｗ
33：さむらい鼠：2004/06/16(水) 17:50: >わかった！
>その部分はゲーム前のログイン情報の部分だよ。

おっしゃる通りでしたｗ
34：升屋な名無しさん：2004/06/18(金) 20:44: おいらのDLLがXPに対応できますた！
いりますか？
35：さむらい鼠：2004/06/18(金) 21:17: >>34
おめでと～。関数のordinal値はdumpbinで調べたの？
よかったら、鶴欲しいです＾＾

ちなみに私のツールはやっとデコード前のパケを表示
できるようになったばかり。暗号処理はそのうちでき
るようにするつもりだけど、今度はその処理はDelphi
で書こうと思ってます。
36：升屋な名無しさん：2004/06/18(金) 22:19: メール発射しますた
37：さむらい鼠：2004/06/19(土) 12:56: >>36
うちの環境でも動いたー！すげっ
DLLのソースに少し目を通したけど、sendや
recvもそうだけど、特に興味深いのはGetMe
moryDataでしたねｗ
あと、DLL初期化後1秒後に、GET_MESSAGEの
フックを掛けるところとか。

ありがとうございました。
COMのフックの仕方を私もいずれはよく研究
してみたいと思いますた。