HyperDbg / gui

HyperDbg's Graphical User Interface (GUI)
Apache License 2.0
63 stars 10 forks source link

release #60

Closed ddkwork closed 2 months ago

ddkwork commented 3 months ago

我是git新手,不知道怎么操作action编译发布二进制文件而不是本地编译上传。

SinaKarvandi commented 3 months ago

No, please don't do that. It's not a good idea to compile the GUI on your own machine. The codes should be compiled by GitHub Action. We also do the same for HyperDbg itself, we won't compile it on our own machine: image

不,请不要这样做。在自己的机器上编译 GUI 不是一个好主意。代码应该通过 GitHub Action 编译。我们对 HyperDbg 本身也做了同样的事情,我们不会在自己的机器上编译它

SinaKarvandi commented 3 months ago

HyperDbg is primarily designed for reverse engineers and security researchers. Consequently, our systems are at a high risk of being infected by viruses that could compromise our releases. Building HyperDbg on our own machines might inadvertently introduce problems for all security researchers who rely on it. Therefore, as a matter of organizational policy, we will not build anything on our own machines. Instead, we will rely entirely on GitHub to handle the building process for us.

HyperDbg 主要为逆向工程师和安全研究人员设计。因此,我们的系统很容易被病毒感染,从而损害我们的发布。在我们自己的机器上构建 HyperDbg 可能会无意中给所有依赖它的安全研究人员带来问题。因此,根据组织政策,我们不会在自己的机器上构建任何东西。相反,我们将完全依赖 GitHub 来为我们处理构建过程。

SinaKarvandi commented 3 months ago

I will help set up the automated build process. First, please remove those compiled binary files. Then please bring any external dependency repositories into the codebase, or if it is an external git repository, please fork that repository into the HyperDbg organization, and let me know when you are done so we can get started with the GitHub Actions build process.

我将帮助设置自动构建过程。首先,请删除那些已编译的二进制文件。然后,请将任何外部依赖项存储库引入代码库,或者,如果是外部 git 存储库,请将该存储库分叉到 HyperDbg 组织,并在完成后通知我,以便我们可以开始 GitHub Actions 构建过程。

ddkwork commented 3 months ago

这个我目前还没准备好如何处理,我知道嵌入bin会增加仓库体积,但是我个人追求的是开箱即用的效果,不需要用户复制一大堆文件,所以我准备嵌入所有bin到go代码中,在gui.exe运行的同时,初始化的时候释放bin到tmp目录,就像ollydbg一样易于使用。然而,因为签名的问题,如果按我说的要求去做,任何人都可以在我指定的Windows系统内加载过期签名的驱动,不幸的是,这种操作可能会引起法律纠纷,我目前不确定。另外一种就是用户自己去签名他们自己购买的签名或者测试签名,但已这种方式的话,bin嵌入go代码就没有意义了,因为只有测试签名方式用户才能正常使用。

---Original--- From: "Sina @.> Date: Fri, Jun 14, 2024 11:55 AM To: @.>; Cc: @.**@.>; Subject: Re: [HyperDbg/gui] release (Issue #60)

I will help set up the automated build process. First, please remove those compiled binary files. Then please bring any external dependency repositories into the codebase, or if it is an external git repository, please fork that repository into the HyperDbg organization, and let me know when you are done so we can get started with the GitHub Actions build process.

我将帮助设置自动构建过程。首先,请删除那些已编译的二进制文件。然后,请将任何外部依赖项存储库引入代码库,或者,如果是外部 git 存储库,请将该存储库分叉到 HyperDbg 组织,并在完成后通知我,以便我们可以开始 GitHub Actions 构建过程。

— Reply to this email directly, view it on GitHub, or unsubscribe. You are receiving this because you authored the thread.Message ID: @.***>

ddkwork commented 3 months ago

好的,容我再思考一下如何易用

---Original--- From: "Sina @.> Date: Fri, Jun 14, 2024 11:47 AM To: @.>; Cc: @.**@.>; Subject: Re: [HyperDbg/gui] release (Issue #60)

HyperDbg is primarily designed for reverse engineers and security researchers. Consequently, our systems are at a high risk of being infected by viruses that could compromise our releases. Building HyperDbg on our own machines might inadvertently introduce problems for all security researchers who rely on it. Therefore, as a matter of organizational policy, we will not build anything on our own machines. Instead, we will rely entirely on GitHub to handle the building process for us.

HyperDbg 主要为逆向工程师和安全研究人员设计。因此,我们的系统很容易被病毒感染,从而损害我们的发布。在我们自己的机器上构建 HyperDbg 可能会无意中给所有依赖它的安全研究人员带来问题。因此,根据组织政策,我们不会在自己的机器上构建任何东西。相反,我们将完全依赖 GitHub 来为我们处理构建过程。

— Reply to this email directly, view it on GitHub, or unsubscribe. You are receiving this because you authored the thread.Message ID: @.***>

ddkwork commented 3 months ago

---Original--- From: "Sina @.> Date: Fri, Jun 14, 2024 11:40 AM To: @.>; Cc: @.**@.>; Subject: Re: [HyperDbg/gui] release (Issue #60)

No, please don't do that. It's not a good idea to compile the GUI on your own machine. The codes should be compiled by GitHub Action. We also do the same for HyperDbg itself, we won't compile it on our own machine: image.png (view on web)

不,请不要这样做。在自己的机器上编译 GUI 不是一个好主意。代码应该通过 GitHub Action 编译。我们对 HyperDbg 本身也做了同样的事情,我们不会在自己的机器上编译它

— Reply to this email directly, view it on GitHub, or unsubscribe. You are receiving this because you authored the thread.Message ID: @.***>

SinaKarvandi commented 3 months ago

I've set up a new repository where we can fork or store the necessary dependencies: https://github.com/HyperDbg/gui-dependencies Would you please move dependencies (those that are possible) into this repo?

我已经建立了一个新的存储库,我们可以在其中分叉或存储必要的依赖项: https://github.com/HyperDbg/gui-dependencies 您能否将依赖项(可能的)移到这个存储库中?

SinaKarvandi commented 3 months ago

For those repositories that cannot be moved, we can fork them directly into our organization. Please let me know the repositories that need to be forked.

This is also the way, we handled dependencies in HyperDbg: https://github.com/HyperDbg/HyperDbg/tree/master/hyperdbg/dependencies

对于无法移动的存储库,我们可以直接将它们分叉到我们的组织中。请让我知道需要分叉的存储库。

这也是我们在 HyperDbg 中处理依赖项的方式: https://github.com/HyperDbg/HyperDbg/tree/master/hyperdbg/dependencies

ddkwork commented 3 months ago

I will help set up the automated build process. First, please remove those compiled binary files. Then please bring any external dependency repositories into the codebase, or if it is an external git repository, please fork that repository into the HyperDbg organization, and let me know when you are done so we can get started with the GitHub Actions build process.

我将帮助设置自动构建过程。首先,请删除那些已编译的二进制文件。然后,请将任何外部依赖项存储库引入代码库,或者,如果是外部 git 存储库,请将该存储库分叉到 HyperDbg 组织,并在完成后通知我,以便我们可以开始 GitHub Actions 构建过程。

你好,我现在首先纠结的是这个议题 https://github.com/HyperDbg/gui/issues/59 让我们先来研究下这个问题好吗?我准备在这个星期内实现调试器可用的状态。根据我的理解,目前似乎是只有附加进程的方式调试吗?如何做到像ollydbg那样拖放文件进调试器窗口点击工具栏按钮的运行按钮,同时设一些断点。。。等等操作。根据我的理解,设断点这个sdk已经实现,但是对于模拟pe运行时,是否是这个过程:Windows sdk api创建一个线程,解析pe,然后我们打上断点等等,我很纠结我是否需要向unicorn那样模拟各种运行时环境?

ddkwork commented 3 months ago

让我们在往后一点时间内处理这个问题。

---Original--- From: "Sina @.> Date: Fri, Jun 14, 2024 12:21 PM To: @.>; Cc: @.**@.>; Subject: Re: [HyperDbg/gui] release (Issue #60)

For those repositories that cannot be moved, we can fork them directly into our organization. Please let me know the repositories that need to be forked.

This is also the way, we handled dependencies in HyperDbg: https://github.com/HyperDbg/HyperDbg/tree/master/hyperdbg/dependencies

对于无法移动的存储库,我们可以直接将它们分叉到我们的组织中。请让我知道需要分叉的存储库。

这也是我们在 HyperDbg 中处理依赖项的方式: https://github.com/HyperDbg/HyperDbg/tree/master/hyperdbg/dependencies

— Reply to this email directly, view it on GitHub, or unsubscribe. You are receiving this because you authored the thread.Message ID: @.***>

ddkwork commented 3 months ago

okay

---Original--- From: "Sina @.> Date: Fri, Jun 14, 2024 12:19 PM To: @.>; Cc: @.**@.>; Subject: Re: [HyperDbg/gui] release (Issue #60)

I've set up a new repository where we can fork or store the necessary dependencies: https://github.com/HyperDbg/gui-dependencies Would you please move dependencies (those that are possible) into this repo?

我已经建立了一个新的存储库,我们可以在其中分叉或存储必要的依赖项: https://github.com/HyperDbg/gui-dependencies 您能否将依赖项(可能的)移到这个存储库中?

— Reply to this email directly, view it on GitHub, or unsubscribe. You are receiving this because you authored the thread.Message ID: @.***>

ddkwork commented 2 months ago

I've set up a new repository where we can fork or store the necessary dependencies: https://github.com/HyperDbg/gui-dependencies Would you please move dependencies (those that are possible) into this repo?

我已经建立了一个新的存储库,我们可以在其中分叉或存储必要的依赖项: https://github.com/HyperDbg/gui-dependencies 您能否将依赖项(可能的)移到这个存储库中?

看来目前不需要依赖归纳仓库,因为gui顺利处理了模块依赖问题并成功构建。此外,https://github.com/HyperDbg/gui-dependencies 这个命名对于go模块路径来说不是个规范的命名,使用这个命名在导入模块路径的时候会看到转义字符或者乱码,因为我个人没有域名服务器,所以我们的模块路径解析强烈依赖GitHub网站。综上所述,go模块的仓库命名应该是小写的单词。与之类似的gui仓库的命名,记得很久以前我初次操作gui仓库的时候,发现我本机硬盘上有两个同名gui模块,当引用模块的时候发现来自GitHub的模块缓存内还有很多以gui命名的模块,这就导致很多命名冲突,如果使用go工作区将它们一起操作会出现错误,不使用工作区的情况下导入模块会让你选择多个gui模块。

ddkwork commented 2 months ago

这是目前gui的主要依赖

我自己的仓库,我个人有几十个模块依赖这两个,他们会在我的仓库个人仓库的实际使用中得到实时更新和不保证兼容性的更改,直到gui模块和我自己的模块得到稳定版本发布的时候。

https://github.com/ddkwork/app https://github.com/ddkwork/golibrary

其余的就是GitHub上的第三方模块,类似语法高亮库,ast词法解析库,跨平台的进程管理库,命名处理库,国际化语言配置库等等。

在start命令和gui完全结合之后,寄存器区域布局和hex editor布局以及堆栈布局将得到修正,目前就像您看到的那样,我还没来得及修正cpu标签页的布局。届时反汇编panel和脚本编辑器的语法高亮将得到实现,我已经封装了两个小部件来高亮语法,虽然还有很多细节要处理,但这只是时间问题。

https://github.com/ddkwork/codeEditor https://github.com/ddkwork/CodeView

ddkwork commented 2 months ago

此外,脚本引擎似乎在不断发生变化,从以前的自定义实现词法解析到现在的Scala,我不确定这两种方案是否都使用ast模式。比如像go的标准库那样输入源码路径解析得到ast语法树,根据ast操作各种token。Scala的官方有实现解析ast吗?这将会得到更少的错误。无论如何,就算我更倾向于api模式而不是脚本模式,我都会为脚本制作高亮语法的panel显示到gui中,我查看了词法解析库支持Scala,https://github.com/alecthomas/chroma 我将为脚本编辑器实施语法着色。

ddkwork commented 2 months ago

Screenshot_20240616_140857_com.realvnc.viewer.android.jpg

Finished

SinaKarvandi commented 2 months ago

此外,脚本引擎似乎在不断发生变化,从以前的自定义实现词法解析到现在的Scala,我不确定这两种方案是否都使用ast模式。比如像go的标准库那样输入源码路径解析得到ast语法树,根据ast操作各种token。Scala的官方有实现解析ast吗?这将会得到更少的错误。无论如何,就算我更倾向于api模式而不是脚本模式,我都会为脚本制作高亮语法的panel显示到gui中,我查看了词法解析库支持Scala,https://github.com/alecthomas/chroma 我将为脚本编辑器实施语法着色。

The script engine didn't change from the start of the HyperDbg. This Scala is for something completely different (generator of hardware debugger). The only syntax highlighting that we need is for dslang or HyperDbg's script engine.

https://docs.hyperdbg.org/commands/scripting-language


从 HyperDbg 开始,脚本引擎就没有改变。这个 Scala 是为完全不同的东西(硬件调试器生成器)准备的。我们唯一需要的语法高亮是针对 dslang 或 HyperDbg 的脚本引擎。

https://docs.hyperdbg.org/commands/scripting-language

ddkwork commented 2 months ago

okay

---Original--- From: "Sina @.> Date: Sun, Jun 16, 2024 22:22 PM To: @.>; Cc: @.**@.>; Subject: Re: [HyperDbg/gui] release (Issue #60)

此外,脚本引擎似乎在不断发生变化,从以前的自定义实现词法解析到现在的Scala,我不确定这两种方案是否都使用ast模式。比如像go的标准库那样输入源码路径解析得到ast语法树,根据ast操作各种token。Scala的官方有实现解析ast吗?这将会得到更少的错误。无论如何,就算我更倾向于api模式而不是脚本模式,我都会为脚本制作高亮语法的panel显示到gui中,我查看了词法解析库支持Scala,https://github.com/alecthomas/chroma 我将为脚本编辑器实施语法着色。

The script engine didn't change from the start of the HyperDbg. This Scala is for something completely different (generator of hardware debugger). The only syntax highlighting that we need is for dslang or HyperDbg's script engine.

https://docs.hyperdbg.org/commands/scripting-language

从 HyperDbg 开始,脚本引擎就没有改变。这个 Scala 是为完全不同的东西(硬件调试器生成器)准备的。我们唯一需要的语法高亮是针对 dslang 或 HyperDbg 的脚本引擎。

https://docs.hyperdbg.org/commands/scripting-language

— Reply to this email directly, view it on GitHub, or unsubscribe. You are receiving this because you authored the thread.Message ID: @.***>