爲什麼沒有oracle Forms或Reports反編譯器？ （技術上）

Question

我不明白爲什麼我找不到這樣的工具（oracle Forms或Reports decompiler）

這很有價值，因爲很多企業都使用基於oracle的系統。

有沒有人知道.FMX或.REP格式文件結構中有什麼特殊之處，可以防止爲它們構建反編譯器？

Answer 1

考慮到$ 13億獎勵他們剛剛對SAP侵犯知識產權，甲骨文可能不是最好的人選。一家公司擁有自己的內部開發系統，包括源代碼，或者他們從一家大公司購買第三方應用程序（加上支持）。他們爲後者付出了很多代價，一家大公司會考慮採取非法手段來欺騙另一家大公司。

因此，此類軟件的合法市場將非常小。

從技術角度來看，在Forms 3.0之後，'source'也不是直接文本，所以你很難將FMX解碼爲可理解的東西，然後將它重新組裝成有效的FMB 。

加上Forms的多個版本（包括主要版本和單個補丁集），創建可在各種平臺上運行的可執行文件。

很多的努力，小市場，法律問題....

---

沒有資源，但模糊的記憶。

早在Forms 3.0的日子裏，您可以手動編輯INP文件（源代碼，FMB的等價物），因爲它們是平面文本。

當他們轉移到FMB時，我記得將FMB轉換爲FMT（文本格式），進行更改，然後再返回。但轉換成可以接受的FMB是一個問題。如果你從.class創建一個.java文件，你會得到一個你通過編譯器運行的文件，它會告訴你源代碼有什麼問題（如果有的話）。 java編譯器設計用於從外部創建（例如在文本編輯器中）並解析它並返回任何解析問題。

如果您手動創建FMB並且它是錯誤的，它會在加載時發生錯誤或者只是崩潰。它的目的不是告訴你「源代碼」有什麼問題，因爲它不打算加載在外部創建的東西。

因此，構建一個有效的FMB（更不用說FMX的FMB）是非常棘手的。

將FMX解析爲可讀格式而不是FMB可能是可行的。但絕大多數Forms用戶將擁有FMB，並且有更多用例將FMB解析爲可用的東西而不是FMX。還有一些實用程序可以做到這一點（包括來自Oracle自己的Forms-to-Apex遷移工具，以及來自PITSS的一些第三方應用程序）。

Answer 2

我敢肯定你回答了你自己的問題：It's very valuable because many enterprises use oracle based systems.
這也是非常有價值的神諭，你不能反編譯他們的系統