5ちゃんねる ★スマホ版★ ■掲示板に戻る■ 全部 1- 最新50  

■ このスレッドは過去ログ倉庫に格納されています

「Macのセキュリティは最悪!」タンと遊ぶスレ

1 :エンジョイ、プレイ:02/04/11 19:24 ID:yiCUGso8
最近ご活躍の「Macのセキュリティは最悪!」タンと遊ぶスレ。
さあ、みんなで、エンジョイ、プレイ!

512 :名称未設定:02/04/15 20:14 ID:XcHW7t5H
おいこのスレで捕まえといてくれよ!
DTM板まで出張ってきたぞこの馬鹿。
それでなくても厨房多くて困ってるんだがあれはイタいぞ。
ほんとの基地外かコイツ!?

513 :名称未設定:02/04/15 20:15 ID:5rjBDnNO
つか、オフラインのセキュリティとオンラインのセキュリティ、
どっちを問題にしたいわけだよ?

オフライン:鍵を開けて侵入、マシンを壊しHDを持ち出す

オンライン:backdoor を用いて侵入し、データを盗み出す

どちらがやばいかというと、オンラインのセキュリティの
脆弱性が問題になってるんじゃないの?


514 :名称未設定:02/04/15 20:30 ID:l8oruSQs
>>511
たんなる警告文です。このスレもやめろというわけじゃないです。

でもこのスレにうまく囲い込んでおくのは無理だと思います。
このスレで「構う担当の人」が居なくなった瞬間に彼は別のスレへうつるでしょう。
餌を与えないで餓死させるしかないと思います。


515 :Macのセキュリティは最悪! :02/04/15 20:31 ID:PHylpLAe
どっちもだ。俺は欲張りだからな。
だいたいオフラインとオンラインを区別することにどんな意味があるんだ?
金庫にしまっといたってネットにダダ漏れじゃ意味ねーだろ、馬鹿。

516 :名称未設定:02/04/15 21:48 ID:LsKHO/fT
>>515
>このスレに囲っといたってDTM板にダダ漏れじゃ意味ねーだろ、馬鹿。
なにも自分でそこまで言わなくたっていいじゃないですか。

517 :名称未設定:02/04/15 21:52 ID:l8oruSQs
ほらほら餌を与えないで。

518 :名称未設定:02/04/15 21:56 ID:fUHMchya
モゥコネェヨ!!ヽ(`Д´)ノ ウワァァァァァァァァァァァァァァン!!!!!!!!!!!!!!!!


519 :名称未設定:02/04/15 22:24 ID:mDweH3aT
最悪タンは、某スレの
>142 名前: 名称未設定 メール: age 投稿日: 02/04/04 22:37 ID:o02C/EWu

>CPUの保護モードも使ってねぇOSなんて、そもそもセキュリティ議論に参加する資格すら
>ないっつーの。
>バッファオーバーフローやり放題、というかGarbage Collectionのない言語で書かれた
>プログラムすべてに、送りつけたコードを実行させることができる。

>保護モードを使っているOSでは、データセグメントがoverflowしてもそう簡単には
>実行させられない。

>洗脳されているとこんな基本的なことすらわからないまま一生を終える。
>もっとも、進入されても破壊されてもどうでも良いようなマシンだから、話題にすら上らないんだけどね。

を信じているみたいだけど、バッファーフローの問題とガベコレをまとめて逝っている時点でDQN
なんだけどなぁ。
ガベージコレクションてのは、ヒープ領域に動的に確保されたメモリブロックで既に使われなくなったもの
を領域解放したり集めたりまあ実装はいろいろだけど、そういうことをいうのであって、
プロセスが死んだときにその領域を解放したりするコトとは根本的に意味が違ってます。
だから、
>Garbage Collectionのない言語で書かれたプログラムすべてに、送りつけたコードを実行させることができる。
こんなことを逝っているのはアフォです。
そもそもバッファーがヒープに取られるか、スタックに取られるか、静的なメモリブロックに取られるかは
実装依存だし、言語がガベコレ持っててバッファがヒープに取られてたとしても、バッファがオーバー
させられた時にただちに言語に実装されたガベコレが働くか?といったらそんなことありません。
言語に実装されたガベコレは、メモリ保護違反の割り込みで起動してるわけじゃありません。
ガベコレあるなしにかかわらず、バッファーオーバーフロー自体は起こる可能性があるでしょ。



520 :MACオタ>519 さん:02/04/15 22:45 ID:YeHL2YOV
>>519
それなかなかスゴい勘違いすね(笑)
バッファオーバーフローで実行されるコードが機械語で書いてある
と思ってるすか。。。

521 :MACオタ:02/04/15 22:52 ID:YeHL2YOV
ところでこのスレざっと読んだすけど、一応、意見を述べている相手に対して、
 ・反論する
 ・煽る
 ・無視する
ってのわ個人の自由だと思うす。でも連続コピペやら、age荒らし以外を
 ・荒らし扱いする
 ・出て行けとか相手にするなとか排除を呼びかける
ってのわ違うと思うす。そういう方わご自身の荒らし耐性ののなさを
恥じるべきだと思うす。


522 :名称未設定:02/04/15 22:53 ID:yjR4IdEV
>>520
むぅ良くわからないのでMacオタさん解説キボンヌ

523 :MACオタ>522 さん:02/04/15 23:06 ID:YeHL2YOV
>>522
CPUのメモリ保護機能の一つわメモリ上のコード(機械語命令)と
データが相互に行き来不可能な別の場所にあるように見せるという
点にあるす。
いわゆるバッファオーバーフローというのわCPUにたくさんデータを
送りつけて、実行する命令の場所がどこだか判らなくさせる。。。という
ものなんすけど、この「命令」ってのわ"cp"とか"rm"とかCUIで送る
命令のことで、メモリ保護の話で出てくる機械語命令でわないすよ。

524 :名称未設定:02/04/15 23:11 ID:yjR4IdEV
>>523
なるほどTerminalの話ですね。ありがとうございます。

http://pc.2ch.net/test/read.cgi/mac/1018139530/630
ちょうどこちらのスレでマシン語コードによる
バッファオーバフローの話をしていたので興味を持ちました

525 :名称未設定:02/04/15 23:29 ID:UNWIH3J0
綺麗と読みやすいが相反するのが命題だがな
マックは明らかに読みにくいのは事実

526 :Macのセキュリティは最悪!:02/04/15 23:30 ID:a1PfSApE
だ〜か〜ら〜、
http://www.shadowpenguin.org/sc_documents/spsdocument08.html

これ最後まで読んだらわかるっつーの。

>523
そこ!
テキトーな説明しないように。
モダンOSのプログラムを何でも良いから逆汗してみるんだな。
IDA Proはおすすめだぞ。スタックの動きまで併記してくれる。

527 :名称未設定:02/04/15 23:32 ID:UsQF1AlA
おお!MACオタと最悪の対決か?

528 :Macのセキュリティは最悪!:02/04/15 23:38 ID:a1PfSApE
>519

おまえさ、現代ではガベコレってのは参照・ポインタ等のアクセスや
型の違反を動的にチェックすることを言うんだぜ?
c++程度しか使ったこと無いんだろ。

具体的には、言語自身の仕様としてデータへのアクセス時にチェックを行う
メソッドを経由しないアクセス方法を持たないものがあるんだよ。
perlなんかはよい例だ。
cやc++はそうではない。
だから、
>言語に実装されたガベコレは、メモリ保護違反の割り込みで起動してるわけじゃありません。

なんて寝言はもう少し勉強しておけば吐かずに済むわけだ。
より進んだガベコレでは、すべてのデータがObject Orientedなのでチェックするメソッドを持つ事により実現される。

529 :Macのセキュリティは最悪!:02/04/15 23:39 ID:a1PfSApE
「動的にチェックすることを」
じゃねぇな。
「動的にチェックすることも」
だ。

530 :519:02/04/15 23:40 ID:1cIE43C5
>>523
Macオタさん、勘違いしてますよ。
バッファーオーバーランで機械語を実行することは可能です。
でもそれはメモリ保護違反で割り込みが起きるうんぬんとは
無関係なんですよ。

ところで、
>148 名前: 名称未設定 メール: age 投稿日: 02/04/04 23:08 ID:o02C/EWu

> >146
> C言語やC++の通常のメモリアクセスでは、値が予想してない範囲になってポインタがどのようなアドレスを指すことになっても、
> プログラムした奴の責任問題で、何が起こるか予測不能。これはCPUの保護モードを使うOSが例外処理メッセージなりを出すことで
> 検出なり対処なりできる。

こんなこと書いているアフォがいますがヌルポインタアクセスとかのメモリ保護違反で割り込みが発生するのはMMUもっている
プロセッサなら常識です。(PowerPCもMMUを持っている)


> もう一つの問題は、動的に確保したメモリを解放しないままループから抜けたりした場合、CやC++では
> そのままその領域が残ってしまう。
> すべてをクラスライブラリで扱えば、デフォルトデストラクタが削除してくれるが、いかんせん言語レベルというわけではないので
> クラスでない物には適用されない。
> その事態もOSの保護モードがあれば例外停止なりメモリの掃除なりができる。

これもバカまるだしで、メモリリークの話とプロセスの持つメモリ空間の話をごちゃ混ぜにしてます。
MacOSXもプロセスとカーネルのもつメモリ空間は別になってます。
メモリリークはJavaのようなガベコレもっている言語でも発生することがあります。
ちなみにCocoaにはオートリリースポインターってのがあります。



531 :519:02/04/15 23:44 ID:1cIE43C5
>>528
最悪タン、デタラメもほどほどにしなよ。
VC++程度でいきがってる厨房だってことはバレバレなんだから。

>>528はどこ突っ込んでも穴だらけの恥ずかしい文章。
プログラム板に貼って晒したろか?

ガベコレがどういうタイミングで起動するのかいってみ?



532 :名称未設定:02/04/15 23:47 ID:UsQF1AlA
どうした?MACオタ
レスが遅いぞMACオタ
負けを認めるのか?MACオタ

533 :名称未設定:02/04/15 23:47 ID:j6/9Oo0F
お?マ板からの援軍か?

534 :519:02/04/15 23:53 ID:1cIE43C5
添削する気も起きないんだけど一応。

> おまえさ、現代ではガベコレってのは参照・ポインタ等のアクセスや
> 型の違反を動的にチェックすることを言うんだぜ?
> c++程度しか使ったこと無いんだろ。
> 具体的には、言語自身の仕様としてデータへのアクセス時にチェックを行う
> メソッドを経由しないアクセス方法を持たないものがあるんだよ。

ガベコレと動的型チェックの話をいっしょにすんなボケ。

> perlなんかはよい例だ。
> cやc++はそうではない。

Perlは暗黙の型変換。C++はDynamicCast。

> だから、
>言語に実装されたガベコレは、メモリ保護違反の割り込みで起動してるわけじゃありません。
> なんて寝言はもう少し勉強しておけば吐かずに済むわけだ。

全然つながってないじゃん。
どういう場合にガベコレが発動するかいってみろよ。

> より進んだガベコレでは、すべてのデータがObject Orientedなのでチェックするメソッドを持つ事により実現される。

全く話題に関係無し。


535 :Macのセキュリティは最悪!:02/04/15 23:58 ID:a1PfSApE
>こんなこと書いているアフォがいますがヌルポインタアクセスとかのメモリ保護違反で割り込みが発生するのはMMUもっている
プロセッサなら常識です。(PowerPCもMMUを持っている)

おまえ馬鹿だなぁ。
例外が発生しても特権モードをOSが使っていなければ例外を処理できねぇんだよ。
プロセスを殺す対処すら出来なくなる。



536 :名称未設定:02/04/16 00:01 ID:7LAZouQe
最悪タンってまだいたんだ?
相変わらず暇だね〜。
あれでしょ? 旧板荒らしてた
バチバチとかゆーやつじゃないの?

537 :名称未設定:02/04/16 00:02 ID:oAfDKwsU
意味不明だ

538 :名称未設定:02/04/16 00:03 ID:oAfDKwsU
>>535

539 :519:02/04/16 00:04 ID:Z1My6xA/
>>535
あーあまたバカさらしちゃった。
漏れのMacOSXのConsoleにはアクセス違反したプロセスが死んだときの
ログが出力されてますけど、どうやってるんですかぁ?


540 :MACオタ>190 さん:02/04/16 00:06 ID:38mgK4B8
>>530
それどうやってやるんすか?
仮にバッファオーバーフローで(バッファじゃなくて)スタックを溢れさせる
ことができたと仮定して、その結果というのわスタックが壊れるんじゃな
くて、スタック以外のデータなり、コードなりが壊れるだけでわないすか?
スタックで上書きされてしまう訳すから。。。

結果としてクラッシュ以外のことが起きないと思われるすけど。。。それに
OS9やCarbonのようなPEF形式のバイナリの場合、システムコールわ間接
参照すから直接バイナリで呼び出すことわ不可能に思うす。

541 :Macのセキュリティは最悪!:02/04/16 00:07 ID:L1Sz3xI0
>534

おまえ馬鹿だろ?
動的型チェックの話しなんぞ誰もしていないぞ。おまえ以外はな。
OOで参照・アドレス演算違反をチェックしてるという意味に決まってるだろ?
そのような言語では言語の実装が完璧ならOSのアクセス例外を発生させることはない。



542 :Macのセキュリティは最悪!:02/04/16 00:09 ID:L1Sz3xI0
>539
OSXの話はしていない。
話をよく読め。


543 :519:02/04/16 00:10 ID:Z1My6xA/
>>541
また関係ない話かよ。
言語側でアドレスチェックを実行時に行うのはOSの機能じゃないじゃん。



544 :519:02/04/16 00:11 ID:Z1My6xA/
>>542
Windowsの話か?


545 :名称未設定:02/04/16 00:12 ID:66a381ej
つーかこんな話、絶対的な知識持ってる奴がガツンと言えば
どっちに転ぶにしても速攻終了だと思うんだけど、ここまで続くってことは…










どいつもこいつも浅知恵だと(w

546 :519:02/04/16 00:13 ID:Z1My6xA/
がいしゅつだがMac OS9でも仮想メモリが入ってればメモリ保護は働くぞ。


547 :519:02/04/16 00:15 ID:Z1My6xA/
>>545
最悪タンが見苦しいだけです。
やつの知識のデタラメさはお話にならんレベルです。


548 :Macのセキュリティは最悪!:02/04/16 00:15 ID:L1Sz3xI0
>540

素人だなぁおまえは。
SPが通常の意味のリターンアドレスを指しているときは、
アクセス違反のせいでそこをつぶすことは出来ない。

ところが、SPをメモリアクセス用に使っており、SP自身がデータ領域を
指している状態というのが結構よくある。
命令体系にも依るがその方が少ない命令でメモリアクセスできるからだ。

で、SPを配列代わりに使っているようなコードのところで
想定している以上のアドレスにデータをあふれさせれば、
RETしたときに書いておいたアドレスにとばしたりとかできるわけだ。

ほかにもいろいろ出来るぞ。



549 :ゆみ:02/04/16 00:16 ID:SJlNELqu
ふりるのパンツ買ってきたよー

550 :MACオタ:02/04/16 00:17 ID:38mgK4B8
>>546
ついでに仮想メモリOFFでもOS以外特権命令わ使えないすよ。
G3カードドライバなんかわ特殊な裏技を使って特権レジスタに
アクセスしているすけど。

551 :MACオタ>最悪 さん:02/04/16 00:18 ID:38mgK4B8
>>548
スタックわデータヒープにあるすからSPがデータ領域を指している
のわ当たり前でわ(笑)

552 :名称未設定:02/04/16 00:19 ID:66a381ej
>>547
じゃあさっさと丸め込んでポイしてください

553 :519:02/04/16 00:19 ID:Z1My6xA/
最悪タンはどんなときにガベコレが発動するか説明しる。


554 :名称未設定:02/04/16 00:20 ID:D8aiHi72
サイアクタンには通用しません。麻原や高橋、サチヨと同系の頭の持ち主ですので。
T山と一緒といえば、この板ではわかりやすいでしょうか。

555 :Macのセキュリティは最悪!:02/04/16 00:24 ID:L1Sz3xI0
>553

だからcなら変数のスコ−プ終了とか、mallocした奴をfreeするときとかだ。
c++ならさらにクラスのデフォルトデストラクタとかだ。
言語によっていろいろだぞ。

より高級な言語では、データアクセス時にほぼ必ずガベコレ
を行うようにするのもある。


556 :519:02/04/16 00:26 ID:Z1My6xA/
>>540
レスするの忘れてた。
スタックを溢れさせたんじゃ意味がありません。
スタックには通常リターンアドレスと、ローカルな変数領域が確保されます。
もしバッファーがスタック上に確保され、リターンアドレスまでどのくらい
離れているかがわかっていれば、ちょうどリターンアドレスの手前まで、
バッファを溢れさせ、本来、リターンアドレスが保存されてるハズのアドレスを
クラック用のコードなりなんなりのアドレスに書き換えてしまいます。
そうすると、そのルーチンから抜けるとき、つまりスタック上のローカルな
データが破棄されリターンアドレスの場所へ戻るタイミングで任意のコードを
実行できてしまう場合があるということです。


557 :Macのセキュリティは最悪!:02/04/16 00:29 ID:L1Sz3xI0
>551

だからプロセッサやOSによってちがうんだっつーの。
スタック領域をほかのデータと別のアクセス権にしているものもある。


558 :519:02/04/16 00:31 ID:Z1My6xA/
>>555
Cでfreeするのは普通ガベコレとはいいません。
C++のデストラクタも明示的に解放しているわけで
ふつうはガベコレとは言いません。
ガベコレのライブラリを使っている場合は、また別ですけど。

> より高級な言語では、データアクセス時にほぼ必ずガベコレ
> を行うようにするのもある。

これは一応正解です。Lispなんかの場合にはそういう実装もあります。

で、メモリ保護違反割り込みで起動されるガベコレなんてあるんですか?


559 :Macのセキュリティは最悪!:02/04/16 00:34 ID:L1Sz3xI0
だから、別のアクセス権にしていないMacOSではより簡単に
exploitを実行させられるということだよ。

わかったかね? >MACオタ

CPUの保護モードとはこのように使うのだよ。
保護モードがあればクラックにより手間がかかる。
spの状態をより詳細に検討しなければならんからな。

560 :名称未設定:02/04/16 00:34 ID:7gaYzI9/
いるよね。自分の間違いは嘘吐いてでも無視してでも絶対に認めない奴って。

561 :MACオタ>最悪 さん:02/04/16 00:35 ID:38mgK4B8
>>556
で、そのクラック用のコードでどうやってシステムコールを呼ぶすか?
OS9のPEFバイナリわロード時になるまでシステムコールの関数ポイン
タが確定しないんすけど。。。

562 :Macのセキュリティは最悪!:02/04/16 00:38 ID:L1Sz3xI0
>558

クラスでは何にもしなくてもデフォルトデストラクタが抹消するぞ。
これはガベコレの一種。

>で、メモリ保護違反割り込みで起動されるガベコレなんてあるんですか?

これは言語のガベコレではなくて、OSからメモリを取得したときの話。
特権モードのあるOSではこの領域の溢れを検出できるし、そのようなプロセスを
殺すことも出来るというお話。


563 : :02/04/16 00:40 ID:KUpVgsYE
氏ね


564 :519:02/04/16 00:44 ID:Z1My6xA/
>>561
もちろんテキトーなアドレスに飛ばせるからと言って、必ずしもクラック
できるわけじゃないです。
やるとしたら機械語として意味のあるデータでバッファを埋めてリターンアドレスをそのバッファ中にするとかかな?
スタックに確保した領域の解放は気にしなければスタックポインタの書き換えだけの場合がほとんどだと思うから。
でもかなり制限されるでしょうね。



565 :名称未設定:02/04/16 00:45 ID:QmmrD2ba
要するにMacのセキュリティはどうなんだ?

566 :Macのセキュリティは最悪!:02/04/16 00:48 ID:L1Sz3xI0
>561

何しろネットワークからexploitを送り込むのだから、対象マシンの対象プロセスは
どんなOSであれネットワークにアクセスするシステムコールなりができるわけだ。
そこで特定のWebにおいておいた第2のコードをDLさせて実行させるというやり方がある。

その中ではかなりのことが出来るので、そのプロセスがどんなオフセットで
システムコールしているかは簡単にわかるわけだ。

OK?



567 :519:02/04/16 00:49 ID:Z1My6xA/
>>562
デフォルトデストラクタは見た目自動的に実行されるけど、
いわゆる「ガベージコレクション」じゃないです。
例外が発生してデストラクタが呼ばれない場合メモリリークが
普通発生しますよね?

参照カウンタとかマーク&スイープとかで孤立したオブジェクトなり
メモリブロックなりを掃除するのがガベコレでしょ。

> 特権モードのあるOSではこの領域の溢れを検出できるし、そのようなプロセスを
> 殺すことも出来るというお話。

これは普通ガベコレとはいいません。
MMUがあればできると言う話はもうしましたね。


568 :Macのセキュリティは最悪!:02/04/16 00:50 ID:L1Sz3xI0
>565

ほかのOSに比べると、劣っていると言わざるを得ない。


569 :名称未設定:02/04/16 00:50 ID:74h0P5hP
面白いことになってるな

570 :MACオタ>最悪 さん:02/04/16 00:50 ID:38mgK4B8
>>566
そのネットワークにアクセスするシステムコールわ外部からわ
知りえないすよ。プログラムをロードするときに確定するポインタ
をどうやってネットワークの向こうから知ることができるすか?
超能力が必要だと思うす(笑)

571 :名称未設定:02/04/16 00:51 ID:U5bF+Pdi
最悪ではないとすればそろそろ改名か

572 :名称未設定:02/04/16 00:51 ID:6JNpT7r+
結局最悪はアフォということで皆さん同意ですか?

573 :名称未設定:02/04/16 00:52 ID:Wi5gFtZU
>>568
勝ったつもりでいるよ。わわわわわら

574 :519:02/04/16 00:53 ID:Z1My6xA/
>>572
同意です。
そろそろ寝るです。
じゃ。


575 :MACオタ@補足:02/04/16 00:53 ID:38mgK4B8
OS Xわコンパイル時に関数ポインタが確定するXCOFFを採用している
すから、この点でわセキュリティに問題があるすね。。。


576 :Macのセキュリティは最悪!:02/04/16 00:53 ID:L1Sz3xI0
>567

そりゃ例外が発生したらガベコレが実行されないことはあるだろう。

MMUがあって例外を検出できても、特権モードがより高い
プロセスでないと制御が確実に渡せない。
つまり、例外が発生してもそのキャッチが保証されないということだ。

それが特権モードを使ってカーネルを動かす理由。


577 :Macのセキュリティは最悪!:02/04/16 00:57 ID:L1Sz3xI0
>570

だから自分のプロセス内を検索するコードを書くんだよ。
自分のプロセスでは呼び出せているんだから、どっかに確定した
モノが書いてあるだろ。Macのはよくしらんが。

当然、exploitを送り込むときは、送り込む奴が対象のプロセスと同じプログラムを
逆汗なりしておいて、事前に、何をすれば動的アドレスの確定値を調べられるか
を考えてコーディングしておくわけだ。


578 :519ーメンドイ:02/04/16 00:58 ID:Z1My6xA/
>>576
ダウト。


579 :名称未設定:02/04/16 00:59 ID:KWfYC0WS
とりあえず知識の無い便乗君が一番みっともないから
ちゃちゃ入れない方がいいと思われ。オレもなー。

580 :名称未設定:02/04/16 01:02 ID:D8aiHi72
>>576
検索し直しだな、アク造

581 :名称未設定:02/04/16 01:04 ID:D8aiHi72
>>577
そーゆー自分の狭い知識の範囲内での仮定に基づいての発言は
みっともないからやめれ。

そりはそうと、「maccer」を「まっかぁ」と発音できる根拠は
見つけられたかのぉ、アク造や。

582 :MACオタ>最悪 さん:02/04/16 01:06 ID:38mgK4B8
PEFの構造ご存知ないみたいすから教えてあげるす。
なんても良いすから、PPCのアプリケーションをお持ちならデータフォークを
バイナリエディタで開けてみるす。
そして、典型的なシステムコールである"NewPtr"あたりを文字列検索して
みて欲しいす。すると、その付近に文字列でMac OSの様々なシステムコールが
羅列されているすよ。この部分がTOCと呼ぶシステムコールの間接呼び出しテー
ブルをつくるためのヘッダになるす。
OSわアプリのロード時にこの文字列をシステムコールのポインタに置き換えて
TOCを作るす。ユーザーコードの中のシステムコールの呼び出しルーチンわ、
このテーブルのアドレスにジャンプするグルールーチンに過ぎないす。

つまりメモリの中を捜してもどのポインタがどのシステムコールの当たるのかわ
決して判らないすよ。


583 :Macのセキュリティは最悪!:02/04/16 01:12 ID:L1Sz3xI0
>582

そのTOCにはアクセスできないのか?
アクセスできれば簡単にわかると思うが。
特定のシステムコールの間接呼び出しを検索し、
つぎにそれが参照するテーブルを又引きする。

ダメなのか?




584 :名称未設定:02/04/16 01:14 ID:D8aiHi72
>>583
ちょっぴり謙虚モードのサイアクタンでございました。

ダメなのか?

585 :MACオタ:02/04/16 01:40 ID:38mgK4B8
それわそれとして、私にわどうもスタックを溢れさせてバイナリ
を実行するという概念が理解できないす。PPCコードの造りを
考えると戻り値のアドレスわスタック上でわなくLR(Link Register)
に入っているす。
スタックを破壊しても無駄だと思うんすけど。。。

586 :ななし:02/04/16 02:11 ID:meWVlKv8
>>585
LRは一個しかないから関数呼び出しが多段になるときはやっぱりスタックに積むのでは???
漏れは仕事でPowerPC使ったマルチレイヤスイッチのファームかいてるけど、タスクがこけたときにスタック辿るとリターンアドレスが入ってたような。
ちなみにOSはvxWorks、コンパイラはgccっす。


587 :名称未設定:02/04/16 02:58 ID:NjgDsVng
堂々めぐりと食い違いの嵐とはいえ、ある程度有意義な問答になっているのが驚異。

588 :名称未設定:02/04/16 08:25 ID:JGIsBX/v
ズバリ!最悪くんは専門学校生でしょ?

589 :名称未設定:02/04/16 08:48 ID:KS8W644s
このスレをム板の人に見せれば良い回答が返ってくるのでは?

590 :名称未設定:02/04/17 00:41 ID:x/8ZSV4f
さ、最悪タンが負かされたところでマターリドキュソウォッチいきますか。
オレ的ヒットはこれ。

>267 名前:Macのセキュリティは最悪! :02/04/17 00:27 ID:LvvRELLk
>灘高校だったりすると「体制派」だとかの「派」なんてぬるいモノじゃなくて、
>体制の具現者だな。
>青臭いのとレベルが違う。

イタタタタ‥

591 :名称未設定:02/04/17 18:42 ID:2lUOjb3B
ヲチすれとして再利用する?


592 :名称未設定:02/04/17 19:20 ID:LSbU8NMW
セキュリティうんぬんより、あの会社はスパイウェアとか平気で仕込むからなぁ。

593 :今日の最悪タン:02/04/17 19:23 ID:AsieW301
>170 名前:Macのセキュリティは最悪! :02/04/17 19:05 ID:LvvRELLk
>ウイルス対策って、チェッカ入れる以外に何か手間がかかるのか?

>それともおまえは、チェッカを買いに行ってからインストールし終えるまでの
>間に、100曲とか作れるのか?

すぐに煽りに反応して熱くなるんだからぁ。
「100曲」って、小学生かよ(笑)

594 :名称未設定:02/04/17 19:25 ID:AsieW301
おっ、最悪タン、>>592が煽ってるぞ!
はやくマジレスしなきゃ!はやくはやく!(藁

595 :名称未設定:02/04/17 20:43 ID:4VJcFlQV
あほくさー
全員、死んどけ

596 :Macのセキュリティは最悪!:02/04/17 22:32 ID:LvvRELLk
>590

マッカーが全敗だろ?


597 :名称未設定:02/04/17 22:41 ID:2n8aGOpl
いや、最悪は昨日の自称高校のPCクラブのやつに負けてただろ。
コテハン名乗る限りは、人気が何より大切なんだよ。

598 :名称未設定:02/04/18 00:44 ID:o5b13tAx
>>577

ttp://hsj.shadowpenguin.org/misc/ebp_overwrite.txt

ここで言及されてるバッファーオーバーランを使って侵入ってのがnimdaとかの
ウィルスで流行したろ?

で、

これはどのOSにもおこり得るが、むしろあっさり制御が奪えるのは
リトルエンディアンであるi386の利点だと言ってないか?



599 :名称未設定:02/04/18 00:48 ID:oYF5r3vm
俺の大腸のバッファオーバーランは、どうやったら防げますか。


600 :名称未設定:02/04/18 00:53 ID:8xFdIQ6I
オリゴ糖とビフィズス菌じゃないか、やっぱり。

しかし今日はパソコンクラブの高校生は来なかったね。

601 :名称未設定:02/04/18 01:40 ID:eIXwQf1U
>>598
興味深いね。
ビッグエンディアンなPowerPCだと1バイト書き換えではどっか遠くへの
リターンにしかならないからバッファ中にコードを仕込むわけにはいかな
いわけなのねん。



602 :名称未設定:02/04/18 01:44 ID:eIXwQf1U
>52 名前: Macのセキュリティは最悪! メール: age 投稿日: 02/04/>18 01:41 ID:uMQ509bt

> 検索しろ腐れ厨マッカーが

あ〜またやってるよ。
最悪タンは検索してコピペはできるけど内容は理解できてないって証拠が
このスレにたっぷり残ってるのに。(w


603 :名称未設定:02/04/18 01:49 ID:vauhIavS
>572 名前:Macのセキュリティは最悪! :02/04/18 01:32 ID:uMQ509bt
>押しつけと抱き合わせはappleの専売特許だからな。

俺が見たところ、こっちのほうが痛いと見たがいかがか?

604 :名称未設定:02/04/18 01:51 ID:eIXwQf1U
>>603
ああ、見落としてた。
そりゃイタイ(w。
抱き合わせの総本山はあちらさんなんだけどねぇ。


605 :Macのセキュリティは最悪!:02/04/18 01:53 ID:uMQ509bt
>598
引き算は出来るか?
SPの最下位アドレスと最上位アドレスの差は何バイトだ?

exploitを送る前のオーバーフローさせるループの回数が、
3回差があるとどうしてクラックしにくくなるんだか
説明してもらいたいモノだな。

>>601-302
内容を全く理解していないのはオマエ。

606 :名称未設定:02/04/18 01:54 ID:7t3rQIXi
主語=マッカー
で「得意技だろ」「お決まりの」的反論が
いまだ2ちゃんで通用すると思ってるのが
Win使ってる俺にも、すんげぇイタイよ「最悪」。
バカにすんな

607 :Macのセキュリティは最悪!:02/04/18 01:56 ID:uMQ509bt
日本語になっていないぞ。

608 :名称未設定:02/04/18 01:59 ID:eIXwQf1U
>>605
> 引き算は出来るか?
> SPの最下位アドレスと最上位アドレスの差は何バイトだ?

その問いかけ自体が無知を晒してるよ。32bit CPUなら4バイト差。
だけどリトルエンディアンだと最下位バイトがアドレスの小さい方にくるから
1バイトの書き換えで十分なのよ、あの場合。


609 :名称未設定:02/04/18 02:09 ID:7t3rQIXi
>>607
きみのお堅いアタマじゃね(w

610 :また出た最悪思想:02/04/18 02:11 ID:o8DVw1TA
62 名前:Macのセキュリティは最悪! :02/04/18 02:02 ID:uMQ509bt
自社規格もなにも、独自の発明とかじゃなくてすでにある原理を
商業化するだけの話なんだから、売れたもんがちだ。

611 :Macのセキュリティは最悪!:02/04/18 02:12 ID:uMQ509bt
>608
アホだろオマエ。
究極のアホだな。
ビッグエンディアンであったとしても、1が3になるだけの話であり、
それはループの回数を増やすだけの話だ。

な〜〜〜んにも理解できてないんだな。

で、クラックしやすさというのはループの回数が1から3になると
飛躍的に下がるのか?
どういう論拠だか示してもらおうか。

引用元の文章では、
「80386がほかのアーキテクチャに比べてクラックしやすい」
などということは一つも言っていない。

妄想が内容の取り違えを起こしているようだな。
やはり知能が低いと言わざるを得ない。



612 :飼育係:02/04/18 02:16 ID:1oNKsAN2


       注意!
       キチガイウィナ最悪タンにエサを与えないで下さい。



244 KB
★スマホ版★ 掲示板に戻る 全部 前100 次100 最新50

read.cgi ver 05.04.02 2018/11/22 Walang Kapalit ★
FOX ★ DSO(Dynamic Shared Object)