HSPポータル
サイトマップ お問い合わせ


HSPTV!掲示板


未解決 解決 停止 削除要請

2014
1227
にゃんちゃん高度なDPMファイル操作について4解決


にゃんちゃん

リンク

2014/12/27(Sat) 15:56:46|NO.66673

こんにちは。
ソフトに使うアーカイブファイルをDPMに全部入れて、暗号化して配ることがよくあると思います。私も便利に使っています。
しかし、現在のHSPでは、既存の暗号化済DPMファイルの更新ができません。更新するときに同じ暗号化キーが分かるとしてもです。
hspcmp経由でパックファイルを開くとき、オープンに使う暗号化キーは指定できず、事前にchdpm命令でキーを渡したとしても、pack_viewで中身を見た時点でソフトが異常終了することを先ほど確認しました。ワトソン博士がお出ましになりました。
もしこれが成功すれば、pack_viewで取得した中身と、新たに指定した既存のファイルをpackfileに記述し、すでにDPMの中にあるファイルはDPMから、まだDPMに入ってないファイルはディスク上から取得し、更新されたDPMを再ビルドする実験をしようと思ったのですが、その前段階で失敗してしまっているので、こういう使い方は現在不可能なのではないかと考えています。
この作業のポイントは、更新の間にDPM内のファイルをディスク上に展開せず、直接更新を行いたいというところです。
また、DPMファイルは暗号化されており、更新時に同じ暗号化キーを渡す必要があるとします。
上記のような動作は、本当に現在のHSPでは不可能でしょうか?
また、もし不可能であれば、openHSPの資料でなんとかならないかとも考えているのですが、DPMファイルの構造が分かりそうな資料を見つけられませんでした。そのような資料はどこかにありますでしょうか?
これができるようになれば、自動アップデートで更新ファイルを取得してそのままアーカイブを更新、最小ファイルサイズでのアップデートができるようになって、とても画期的だと思います。
よろしくお願いします。



この記事に返信する


tds12

リンク

2014/12/27(Sat) 17:26:19|NO.66675

>そのような資料はどこかにありますでしょうか?
http://dev.onionsoft.net/trac/openhsp/browser/tags/3.4/hsp3/dpmread.cpp
暗号化については全くわかりませんが、
このページを見ることにより、構造程度ならわかるかもしれません。

DPMの構造は、
まず先頭に16バイトのヘッダがあります。
ヘッダの0バイト目から4バイトで$584d5044とあります。
4バイト目から4バイトでパックされたファイルの中身が並んでいる部分を意味する
ファイル先頭からのバイト数が書かれています。...実データ開始ポインタ
8バイト目から4バイトでパックされたファイルの数が書かれています。
...ディレクトリエントリ数
12バイト目から4バイトは現在(あるいは非暗号化時)使われていないようです。

次に32バイトのパックされたファイルの情報が、
パックされたファイルの数だけ書かれています。
情報の0バイト目から15バイトでパックされる前のファイル名が書かれています。
情報の24バイト目から4バイトはパックされたファイルのデータの位置を
実データ開始ポインタからのバイト数で表しています。
情報の28バイト目から4バイトはパックされたファイルのサイズを表しています。

実データ開始ポインタの指すところからは
ファイルの中身が並んでいます。



Flat

リンク

2014/12/27(Sat) 17:27:44|NO.66676

DPMの構造を自分なりに調べてみましたが暗号化/復号化のアルゴリズムが非公開に
なっていることもあり、できることはかなり限られると思われます。
ですので、個人的にはオリジナルのアーカイブファイルを開発したほうが楽だと思います。

一応、調べて分かったことを下に書きます。

+------------+ | | +------------+ これで4バイトを表します。 特に断りがない場合はINTです。 ヘッダ(16バイト) +------------+------------+------------+------------+ |"DPMX" ASCII|DATA OFFSET |NUM OF FILE | 0x00000000 | +------------+------------+------------+------------+ ※DATA OFFSETはファイル先頭からデータチャンクへのオフセットです ファイル情報チャンク(32バイト×ファイル数) +---------------------------------------------------+ |FILENAME (CHAR[16]) | +------------+------------+------------+------------+ | 0xFFFFFFFF | CRYPTO KEY | DATA OFFSET| FILE SIZE | +------------+------------+------------+------------+ |FILENAME (CHAR[16]) | +------------+------------+------------+------------+ | 0xFFFFFFFF | CRYPTO KEY | DATA OFFSET| FILE SIZE | +------------+------------+------------+------------+ (以下ファイル数分だけ続く) ※DATA OFFSETはデータチャンクからファイルデータへのオフセットです データチャンク (暗号化されたファイルデータが羅列されている)



Flat

リンク

2014/12/27(Sat) 17:41:46|NO.66678

ああ、かぶってしまったか。ではアプローチの方法を。

1. ヘッダチャンクのDATA OFFSET、ファイル数を変更
2. ファイル情報チャンクに追加ファイル分の情報を追加
3. データチャンクにデータを追加

おそらくこれでファイルの追加は出来ます。
ファイルを削除する場合も同様な手法で可能かと。

暗号化/復号化のアルゴリズムは公開されてないのでそこだけ注意。



にゃんちゃん

リンク

2014/12/27(Sat) 20:30:19|NO.66680

詳細な説明をありがとうございます。
暗号化アルゴリズムについてですが、hspcmpが吐き出す暗号化バイナリをうまく横取りして使えるのではないかと考えています。
DPMの中身は展開するとまずいですが、別のDPMファイルを経由してこれを実現します。
追加したいファイルだけを暗号化してDPMを作った後、そのファイルのヘッダ情報を元にデータチャンク内のバイナリを抜き取り、それを本命のDPMに追加するデータとして使えば、キーが共通である限り、暗号化アルゴリズムをhspcmpに丸投げできると思います。
ということで、これで実験してみたいと思います。お二方ともありがとうございました。



ONION software Copyright 1997-2018(c) All rights reserved.