質問: {0xb3,0xe2,0x0f,0x39,0xf2,0x92,0x11,0xd6,0x97,0xa4,0x00,0x30,0x65,0x43,0xec,0xac}; 最後に、このファイルを取得して作業ディレクトリに追加しました http://www.opensource.apple.com/source/xnu/xnu-1456.1.26/bsd/hfs/hfs_fsctl.h
回答: 私はこれに取り組みました。 hfs.utilのソースをダウンロードし、(コンパイルできるように)言及した変更を加え、uuid機能を再度有効にし(現在のソースで無効になっている-sなど)、新しいコマンドを追加しました(- uuidを指定するために使用されるs)。新しいコマンドの形式は次のとおりです。sudo hfs.util -s disk0s2 xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx sudoを使用するか、rootとして実行する必要がありますが、ボリュームをマウント解除する必要はありません(現在のシステムボリュームであっても)。しかし、私はまだそれをデバッグしています(私はcでひどいです)。エラーなしで実行できますが、それでも-sを使用して新しいuuidを効果的にランダム化しています。指定したuuidに関係なく、まだ別のuuidを取得しています。動作するようになったら、ここに差分を投稿するか、変更したソースをアップロードする場所を見つけて、ここからリンクします。失敗した場合でも、おそらく差分を投稿し、他の誰か(cの方が優れている)がそれを修正できる可能性があります。編集: ok。 apple hfs.utilのソースコード)のuuid文字列<->バイナリ関数を処理する関数の主要なバグと思われるものを見つけました。バイナリ値として、4が必要です。 (符号なし)128ビットuuidを格納する32ビットワード。appleソースは16個の16進文字のみを処理するように見えます(それぞれ2つの16進文字の16オクテットである必要があります)。また、欠陥のある構造を使用してuuidを保持しているようです(「高」32ビットワードと「低」32ビットワードのみを格納しているように見えますが、4つの(符号なし)32ビットワードが必要です)。修正できると思いますが、構造体とその構造体を使用するすべての関数を変更する必要があります(時間がかかる場合があります)。編集#2:デバッグに多くの時間を費やした後、apple hfs.utilのソース(私は実際にはcプログラマーではありません)apple意図的にはuuidを処理するときに64ビットのみを処理します。残りは64ビット定数のハッシュから生成されます。コンピュータコンポーネントの値、現在の時刻など。したがって、同じ64ビットの「キー」を2回使用した場合、2つの異なるuuidが発生します(同じコンピュータを使用した場合でも、時刻は変更されています)。 。ボリュームヘッダーへの実際の書き込みが実際のuuid(キーだけでなく)を送信する限り、およびボリュームヘッダーが実際のuuid(および計算に使用できるキーや値だけでなく)を格納する限りuuid)、それなら希望があります。私のデバッグはまだそれほど進んでいません。もっとわかったらまた投稿します。