Stored procedures Firebird，解密存储过程？

我进入了一个需要将一些功能从传统Firebird数据库移植到MSSQL的地方。表模式和数据是正常的，所有的都是可枚举的，对于sysdba是可选择的，但是，应用层被证明是一个难题。 该数据库有大约1000多个程序，我想通过一些回顾来移动它们，而不是重建整个DAL。问题是（你猜到了），它们似乎都是以某种方式加密的。当我要求修改它以生成脚本时，我得到了alter脚本，但过程的主体看起来像是一些二进制内容的base64字符串。我的第一个猜测是加密

有什么方法可以像MSSQL一样解密这些实体吗？请注意，Firebird数据库在其原始设备上运行，在其原始Firebird安装中，未复制或移动任何内容，以防需要访问某些密钥。

在Firebird中创建（或更改）存储过程时，Firebird将原始正文存储在表

RDB$PROCEDURE

的

RDB$PROCEDURE\u SOURCE

列中。这不会被加密。这个主体与Firebird本身无关，因为它将使用存储过程的编译形式（在列

RDB$procedure_BLR

中）；存储它只是为了允许isql（和其他工具）生成数据库的DDL脚本

一些软件供应商不喜欢人们有权访问他们的源代码，因此他们要么将此

RDB$PROCEDURE\u SOURCE

列设为空，要么（就像您的数据库一样）以某种方式对主体进行加密

如果这是一个内部开发的应用程序，则需要找到用于构建此数据库的原始脚本

否则，如果不确切知道供应商（或开发人员）做了什么，就无法撤消此操作。另一种可能的解决方案是从BLR（二进制语言表示，存储过程的编译形式）对存储过程进行反向工程，但我不知道有什么工具可以做到这一点（这可能不会产生非常可读的代码）

这样做可能违反许可协议，甚至可能违反当地法律。您最好与这个遗留应用程序的供应商联系，并向他们索要（或支付）此源代码

---

ISQL工具可以以“可读”的形式打印BLR，但由于它的级别非常低，我不知道这会有多大帮助。例如，请参阅。

自从Firebird 3.0以来，数据库加密现在是可能的…因此它与Firebird安装无关，而与它本身已加密的数据库无关，恐怕您需要加密密钥来解密数据阅读以下文章：

---

afaik公司没有法律问题，该软件在过去的某个时候已经过委托并支付了费用，因此afaik公司拥有该软件。您是对的，源列是加密的，这可以解释我们与前承包商之间的其他（非开发）问题及其行为。我将把所有这些都提交给法律部，让他们先处理。谢谢你的回答。这个答案并没有解决这个问题。数据库加密处于较低的级别，它阻止在没有解密密钥的情况下对数据库本身进行读取访问。如果涉及Firebird 3数据库加密，那么数据库要么完全不可访问，要么源代码是可读的，因为它将在读取时自动解密。