これは日曜日の午後の楽しいプロジェクトのようだったので、試してみました。要点を簡単に説明すると、クエリを解析して実行するSQL Serverの関数の呼び出しスタックは次のとおりです（Windows 7 SP132ビットで実行されているSQLServer 2008 R2から取得したアドレスとオフセット）：

  0x7814500a msvcr80.i386！memcpyの+ 0x5a0x013aa370 SQLSERVR！CWCharStream :: CwchGetWChars + 0x5c0x013a9db5 SQLSERVR！CSQLStrings :: CbGetChars + 0x350x012ffa50 SQLSERVR！CParser :: FillBuffer + 0x3d0x0138bbfd SQLSERVR！CParser :: CParser + 0x3c80x01352e96 SQLSERVR！sqlpars + 0x7b0x013530f2 SQLSERVR ！CSQLSource :: FParse + 0x16d0x013531ed sqlservr！CSQLSource :: FParse + 0x2680x012ff9e8 sqlservr！ `string '+ 0x3c0x015894b8 sqlservr！CSQLSource :: Execute！serv5！8serv + 0x2c80x0158ad31 sqlservr！process_request + 0 0xdd0x015cf9ea sqlservr！SOS_Scheduler :: RunTask + 0xb40x015cf575 sqlservr！SOS_Scheduler :: IsShrinkWorkersNecessary + 0x480x77f06854 ntdll！ZwSignalAndWaitForSingleObject + 0xc0x77e479e2 kernel32！これについては、おそらく CSQLSource クラス、特にその Execute メソッドを詳しく調べたいと思うでしょう。 
この情報を武器に、私はまた、SQL Serverのメモリダンプからクエリ文字列を抽出する方法について、Microsoftの誰かによるブログ投稿をいくつか掘り下げることもできます。その投稿は、私たちが正しい方向に進んでいることを確認しているようで、介入する場所とクエリ文字列を抽出する方法を提供します。
 
方法論
これは、何らかの形式のDynamic Binary Instrumentation（DBI）を使用して最も簡単に対処できると感じました。クエリ文字列はSQLServerプロセスのどこかで処理されると思われるため、プロセスによって行われたメモリの読み取りと書き込みを調べて、クエリ文字列を読み書きするポイントを検索できます。次に、その時点でコールスタックをダンプして、どの興味深いアドレスが表示されるかを確認し、それらをシンボルにマップし直すことができます（Rolfが指摘しているように、SQL Serverにはデバッグシンボルがあります）。基本的にはそれと同じくらい簡単でした！
 
もちろん、コツは、プロセスを簡単に計測できる何かを身に付けることです。  QEMUに基づく（できれば間もなくリリースされる）システム全体の動的分析フレームワークを使用して、これを解決しました。これにより、SQLServerを PINなどで実行することに伴う不快感を回避できます。フレームワークには記録と再生のサポートが含まれているため、インストルメンテーションを使用してサーバープロセスの速度を低下させることも心配する必要はありませんでした。コールスタックを取得したら、 PDBParseを使用して関数名を取得しました。

トラフィックのみをスニッフィングするのは簡単です

トラフィックをスニッフィングしたいだけの場合は、 WireShark aに付属の TDSプロトコルスニファーを使用できます。 >。

怠惰があなたを導きましょう-怠惰はリバーサーの友達

パイプやTCP / IPを聞くことはこのオプションではありません瞬間;より高いレベル、できればSQLOSコンポーネントレベルで注入したいと思います。

すべての情報がすぐに利用可能で、すべてがすぐに利用できるのに、なぜこれを特定の方法で行うことを主張するのかわかりません。あなたがする必要があるのはジグソーピースを一緒にすることです。これは、最も簡単で最速の、つまり最も怠惰な方法のように思われます。 TCP / IPに加えて、 より高いレベルです。これは、SQLサーバーのIP /名前を乗っ取って、実際のSQLサーバーマシンに到達する前でも、TCP / IPを傍受できるためです。間に「プロキシ」を置きます。どのくらい高レベルにしますか？あなたが主張しているのは、実際にはMS SQLServerの下位レベルの内臓にドリルダウンすることです。

MSSQL Serverは、文書化されたプロトコルを使用し、 LSPを使用しますそのトラフィックをスニッフィング、傍受、さらには操作できるはずです。私が覚えている限り、LSPは、トラフィックをフィルタリングしているアプリケーションのプロセススペース内で実行されます。文字通り、それらをその場しのぎのアプリケーションレベルファイアウォールと見なすことができます。

あるいは、おそらく、とにかくより良い選択ですが、既存の無料の FreeTDS（ライセンス供与済み）に基づいてプロキシを作成できます。 LGPLの下で）。 tdspool プログラムは、この取り組みを開始するための良いポイントです。はい、これは転送されたトラフィックをスニッフィングするだけでなく、実際の傍受にも適しているはずです。ライブラリ（FreeTDS）を使用して、クエリをデコードおよび再エンコードできます。そのライブラリは、明らかにLSP内で使用するライブラリでもあります。

MS SQL Server 2008をインストールし、IDA Proで簡単に確認しましたが、逆アセンブリの詳細に入る時間を節約します。 ブレンダンの答えは、簡単な方法が利用できるこの過度に複雑な方法に同意できない場合でも、優れた概要を提供します。しかし、その後、あなた（ヘルナン）がそれを求めました。

一般的に言って、このような問題はアプリケーション固有のものです。したがって、ユーザーのブロードウェイが彼の答えに反対票を投じたという事実にもかかわらず、問題に固有の素晴らしい特別な解決策を知らなかった場合に私が与えるアドバイスとまったく同じでした。あなたがしなければならないことは、データがプロセスに入ってくるのを見て、それがプログラム全体でコピーされ操作されるときにそれに従うことです。このタスクは、SQL Serverでデバッグシンボルを使用できるため、一般的な場合よりも簡単です。これらの線に沿って何かを試みましたか？たとえば、SQL Serverのコンテキストでネットワーク受信タイプの関数にブレークポイントを設定し、ネットワーク経由で受信するデータにハードウェアRWブレークポイントを設定してから、データが大量のコードをどのように移動するかを監視しますか？

そのターゲットについて具体的な知識はありませんが、おそらく私が取るアプローチは、パイプ、tcp、および共有メモリを介して同じメッセージを送信し、ピンでそれらをトレースして、基本ブロックがヒットした場所を探すことです。すべてのトレースに収束すると、適切な注入ポイントを微調整するためのいくつかの開始点が得られるはずです。