← 2026-09-07 の一覧へ戻るホーム
非公式なデータベースのストレージ形式のリバースエンジニアリング

2026/09/04 16:17

非公式なデータベースのストレージ形式のリバースエンジニアリング

RSS: https://news.ycombinator.com/rss

元のHacker News記事へ ↗
要約▶

Japanese Translation:

最も重要な成果は、Codex を用いて構築された改良版オープンソースツール「cronodump」を使用して、破損した CronosPro データベースファイル（.dat および .tad）から重要データを成功裡に復元したことである。元の 

cronodump
は、CroBank および CroIndex が KOD エンコードされていると誤って推定していたために失敗したが、新しいアプローチは、統計的再構成と正確なバグ修正を組み合わせることで実現された。チームは有効な Cronos 構造から統計的参照データを構築し、バイトの頻度を推定した上で、SciPy のハンガリアンアルゴリズム（
linear_sum_assignment
）を用いて 256 バイトのパージョン制約を解いた。また、重要な解析器のエラーも修正された。具体的には、Cronos v4 で 
0x08
フラグによって示されているように、12 バイトの extents ヘッダーが誤って含まれて位置オフセットを引き起こす問題、そして Windows-1251 エンコーディングで文字化けしたテキスト値を UTF-8 に明示的にデコードしない問題であった。さらに、
idx2
プロパティによって指定された隠れた内部フィールドを考慮することにより、可視定義と保存された値を整列させるためのフィールドマッピングも修正された。この堅牢なソリューションは、今や読み取れない十六進数データではなく、修正されたフィールドマッピング付きで正確な CSV エクスポートを生成し、貴重な歴史的アーカイブへのアクセスを回復させ、このレガシーシステムを使用している組織に必要なデータ移行を可能にしている。

本文

「壊れた」とされる CronosPro データベースの完全復号化：Cronodump の改良と分析

既存のツールで解析不能とされていたクロノスプロ（CronosPro）データベースファイル（

CroBank.dat
、
CroIndex.dat
、
CroStru.dat
）を、Codex を用いて正常にダンプし、AlephData の 
Cronodump
プロジェクトを改良しました。

クロノスプロのアーキテクチャとファイル構造

独自所有のデータベースシステム

  • クロノス（Cronos）/ CronosPro：ロシアや旧ソビエト圏で広く使用されたデスクトップ情報管理システム。
  • 独自の用語体系
    • Database → Bank
    • Table → Base
    • Record ID → System Number

ファイルの役割と関係性

クロノスデータベースは複数の関連するバイナリファイルで構成されます。

ファイル目的
CroStru.dat
/ 
.tad
データベース構造（テーブル、フィールド定義）
CroBank.dat
/ 
.tad
実際のレコードデータ
CroIndex.dat
/ 
.tad
検索インデックス
CroSys.dat
/ 
.tad
システム情報
  • .dat
    ファイル    ：実際のデータを格納。
  • .tad
    ファイル    ：ディレクトリのような役割（レコードの位置指示）。
  • メンタルモデル
    • CroStru: データベースの外観と定義。
    • CroBank: 行（レコード）自体。
    • CroIndex: レコードの検索を支援。

⚠️ 注意点：レコードデータは読み取り可能ですが、それを解釈するスキーマは暗号化されています。

パース処理における課題と定義

「正規化」の意味

ここではリレーショナルデータベースの「正規形」ではなく、バイナリデータの可搬性・審査可能性への変換を指します。

  1. クロノスバイナリファイルからの変換。
  2. デコードされたテーブルとフィールドへのマッピング。
  3. 正しい型付けおよび位置調整された値の確保。
  4. UTF-8 CSV ファイルへの出力。

保持すべき関係性

単なる文字列抽出ではなく、以下の関係を維持することが不可欠です。

  • テーブルとレコード間の関係。
  • カラム名と値の関係。
  • 日付とその意味の関係。
  • テキストとその元の符号化方式（Windows-1251 など）の関係。
  • 内部フィールド位置の関係。

❌ 誤ったヘッダーの危険性 ヘッダーがずれている CSV は、有効に見えるだけですが実質的に意味を喪失しています。

解析プロセスと改良点

既存ツールの失敗要因

Cronodump
で失敗した主な理由は以下の通りです。

  • CroStru.dat
    （スキーマファイル）が KOD エンコードされていたため、通常のパーサーは読み込めなかった。
  • CroBank.dat
    および 
    CroIndex.dat
    は KOD エンコードされていないはずだったものの、既存の推測手法（クラック）が失敗した。

解決のための技術的アプローチ

1. 圧縮と保護の区別

  • 圧縮: データの占有スペース削減（バイト変形）。
  • KOD 保護: バイト値の置換（
    Substitution Table
    ）。
  • 既存ツールの限界：KOD テーブルを学習するための仮定が誤っていたため復号失敗。

2. KOD テーブル（置換テーブル）の復元

クロノスは 256 エントリの置換テーブルを用いてデータを保護します。さらに複雑に、位置とレコード番号にも依存して変化するアルゴリズムを使用しています。

plaintext[i] = KOD[ciphertext[i]] - i - record_number (mod 256)

3. 統計的アプローチによる割り当て問題の解決

KOD テーブルは完全な置換（パーミュテーション）である必要があり、各シフタバイトが一意のマッピングを持つ必要があります。これをハンガリアンアルゴリズムを用いて解決しました。

  • 参照分布の構築: 既知のテストデータベースから、有効なスキーマデータに存在する傾向（ゼロバイト、ASCII プロパティ名など）を学習。
  • スコア表の生成: 各可能な KOD マッピングについて妥当性のスコア付けを実施。
  • 最適化コード: 
    from scipy.optimize import linear_sum_assignment

# スコアを負にして最大尤度割り当てを選択
rows, columns = linear_sum_assignment(-scores)

4. 構造検証と追加ヘッダーの発見

復元したスキーマレコードには、12 バイトの拡張ヘッダーが存在することが判明しました。

  • 問題: パースャがこれを無視してデコードすると、すべてのバイト位置に誤差が生じる。
  • 解決: 
    CroStru
    の v4 フラグ（
    0x08
    ）を検知し、ヘッダーをスキップしてからペイロードをデコードするロジックを実装。

5. テキストエンコーディングの修正

  • 問題: Windows-1251 で表現されたテキストが 16 進数としてエクスポートされていた（例：
    c1 c8 d7...
    ）。
  • 解決: 文書化されたタイプ（1, 2, 3）に対して明示的に 
    cp1251
    からユニコードへの変換を実装。 
    elif self.typ in (1, 2, 3):
    self.content = data.rstrip(b"\x00").decode("cp1251", "ignore")

6. 物理的なフィールド位置の追跡

クロノスレコードには「見えない」内部フィールドが存在することがあります。可視定義と実際のデータ位置を照合する必要があります。

  • 手法: フィールド定義の 
    idx2
    （物理的位置）と、現在の読み込みインデックスを比較し、隠れたフィールドを読み取るまでループ処理を行うロジックを実装。 
    source_index = 1

for field_definition in table_definition[1:]:
    while source_index < field_definition.idx2 and not reader.eof():
        read_field_data(reader) # 隠れたフィールドを消費
        source_index += 1

    value = read_field_data(reader) if not reader.eof() else b""
    source_index += 1

結論：統合されたソリューション

最終的な CSV コンバージョンは、以下の要素を統合したものです。

  • オープンソースの 
    Cronodump
    パッケージ
  • 曖昧な KOD 問題に対する PR #22 のアイデア（対話型回復ワークフロー）
  • 統計的 KOD 再構成
  • ハンガリアンアルゴリズムによるグローバル割り当て
  • 正しい CroStru v4 エクステンション処理
  • Windows-1251 からユニコードへの自動変換
  • 物理的なフィールド位置追跡
  • 有界な意味論的検証（日付や名前が正しいカラムにあるか確認）

これにより、「壊れている」と見なされていたデータベースを、完全に解析可能な CSV に変換することができました。

同じ日のほかのニュース

一覧に戻る →

2026/09/07 5:45

Show HN：Mador（80行のProxy State Tuple で、あらゆる DOM をリアクティブにします）

## Japanese Translation: **改善済み。** 元のサマリーは正確ではあったが、開発者がライブラリの安全性と効率性を評価する上で価値のある具体的な行動詳細（`write` を通じたバッチ処理および自動的なクリーンアップ）を見落としており、また重要なポイントで言及されていた MIT ライセンスについても欠けていた。 以下に、これらの欠落している要素を取り入れた改善版を示す： ## 改善されたサマリー Mador.js は、重いフレームワークを採用することなく、複雑なビルド手順も必要とせずにリアクティビティを必要とする開発者向けの軽量な代替手段を提供する。従来のコンポーネントや仮想 DOM に依存するシステムとは異なり、このネイティブ ES モジュールランタイムは、独自の 3 つパートのバインディングパターン（要素の選択、更新関数の定義、ステート依存関係の指定）を用いて、状態を既存の HTML エレメントに直接バインドする。最小限のフットプリント（約 855 バイト）により、依存関係を知的に追跡して変更があった際のみ特定のプロパティを実行し直すことで、高速なパフォーマンスを実現する。状態の更新は `write` メソッドを通じられ、1 つの操作内で複数の変更をバッチ化する。特に重要なのは、Mador が要素が存在しなくなったときにランナーを自動的に削除することで、DOM のライフタイムを管理し、手動でのクリーンアップの必要をなくしている点である。このアプローチにより、npm または CDN を通じて直ちにレガシーコードベースに統合でき、下のレイヤーの DOM 構造を変更することなく、コンポーネントのライフサイクルも管理せずに済む。MIT ライセンスの下でリリースされたこの技術は、ステート管理を必要とするがフルアプリケーションフレームワークのアーキテクチャ的なオーバーヘッドを拒否するインタラクティブなページ機能を作成する際、特に価値があり、クイックプロトタイピングおよび定義された HTML 構造を持つプロジェクトへの動的な振る舞いのシームレスな追加を可能にする。

2026/09/06 20:56

インテリジェント・フライが開く（2025）

## Japanese Translation: 主要な警告は、ユーザーが LinkedIn の投稿作成に大規模言語モデル (LLM) に依存することをやめるべきであるという点にあります。この慣行は本質的に本物性を損なうためです。AI は編集やブレインストーミングの手助けにはなりますが、著者の真の声とは複製できません。その代わり、AI が生成したコンテンツは、過度な絵文字、短すぎる段落、およびダッシュの過剰使用といった不快なスタイルの特徴を示すことがよくあります。これらの明確なパターンにより、読者は投稿が本物の考えを反映したものではなく作りものであることを簡単に検出し、その結果、オーディエンスとの間に乖離が生じ、信頼を失い、完全に関与しなくなります。この批判は、LinkedIn が組み込みの「再書き換え」機能を通じて AI の使用を積極的に推進しているにもかかわらず発生しています。著者が引き続き AI の利便性をオリジナルの内容よりも優先し続ける場合、読者は不信感の高まりからコンテンツをスルーしたり見送ったりする可能性が高まります。したがって、ユーザーは意図したオーディエンスを失い、個人ブランドを損なうリスクに直面し、企業側がこの行動を促進する場合は、業界内の関与低下と信頼喪失を招く可能性があります。

2026/09/06 16:21

Isar Aerospace、2 度目の飛行で軌道到達とペイロード展開に成功

## Japanese Translation: Isar Aerospace は、欧州初の商業エンティティとして衛星を軌道に成功投入し、新たな商業ルートを通じて主権空間アクセスを提供する上で画期的な瞬間を刻みました。この実績は、2026年9月5日にノルウェー・アンドョアで離陸した「Onward and Upward」というミッション（同プログラム第2飛行）において確認されました。このミッションはすべての必要な技術的マイルストーンを実行しました：MaxQ通過、MECO完了およびステージ分離、第2段点火、100kmのカルマン線 crossing、ペイロードフェアリングの抛弃、円形化燃焼、ならびに教育用およびスタートアップ用ペイロードとの成功した分離を実施しました。これらのペイロードは、ESA Boost! の資金提供を受けてドイツ宇宙機関（DLR）の Microlauncher Competition で選定されました。2018年にミュンヘンの近くで設立された Isar は垂直統合を維持しており、小型および中型衛星に対する衛星作成、テスト、打上げサービスのほぼすべての側面を自社工場で行っています。この加速アプローチにより、通常は数十年にわたる開発期間をわずか数年に圧縮しました。展望としては、同社は地球観測や通信において重要な中傾角から高傾角軌道をサポートするためにカナダ・ノヴァスコシア州で新しい打上げ複合施設を建設し、「Spectrum」というロケットファミリー車両を年間最大40発の打ち上げに対応する専用施設で製造することで足跡を拡大しています。これらの進歩は、信頼性の高い欧州打上げサービスを求める商業顧客や機関に対して真の代替手段を提供します。

非公式なデータベースのストレージ形式のリバースエンジニアリング | そっか～ニュース