Generate all command api functions using json with hierarchical command types and handle the respective arguments

[ddkwork]

This will parse the json with the longest example field too extract all the parameters and types, ideally like the current sdk's set breakpoint api function looks like, with all the parameters and types. This would make it easier to interact with ui widget events, as parsing the command return would require a temporary constructed structure? Some commands should not return anything at all, the execution structure and return value are not visible?

https://github.com/HyperDbg/gui/blob/main/sdk%2Fcc%2Fcommand_test.go#L44-L85

[ddkwork]

[ddkwork]

[ddkwork]

use this file https://github.com/HyperDbg/gui/blob/main/sdk%2Fcc%2FbugFixed.json

[ddkwork]

[ddkwork]

[ddkwork]

[ddkwork]

[SinaKarvandi]

Hi, I'm here now. Are you going to make a parser for the commands in GO? Am right? or do you just want to show them in a list?

嗨， 我现在就在这里。你要为 GO 中的命令制作一个解析器吗？对吧？还是你只是想将它们显示在列表中？

[ddkwork]

不，只是想将他们分类，就像您的源代码目录中那样

---Original--- From: "Sina @.> Date: Sun, Jul 7, 2024 16:32 PM To: @.>; Cc: @.**@.>; Subject: Re: [HyperDbg/gui] Generate all command api functions using json withhierarchical command types and handle the respective arguments (Issue #169)

Hi, I'm here now. Are you going to make a parser for the commands in GO? Am right? or do you just want to show them in a list?

嗨， 我现在就在这里。你要为 GO 中的命令制作一个解析器吗？对吧？还是你只是想将它们显示在列表中？

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

[SinaKarvandi]

Ah, I got what you mean. Honestly, this is really hard to make because I created this JSON file manually. Unfortunately, we don't have a separate parser for the commands in libhyperdbg and it's been on the to-do list for a long time, so right now each command doesn't have structured arguments and parameters format, and making such a structure for commands probably needs months of work!

I suggest not to use a unique function for each command. Instead, we could create a box and pass all of the user inputs to the 'interpreter' function. I started to export all of the commands in the SDK gradually (for now, I'm working on exporting essential functionalities like reading/writing memory, and right now, I'm working on providing read/write into registers for you). I think having functionalities exported in the SDK is better than passing them to the 'interpreter' functions since this way we could remove the interpreting phase and make it faster.

What do you think of it?

啊，我明白你的意思了。老实说，这真的很难做，因为我手动创建了这个 JSON 文件。不幸的是，我们没有 libhyperdbg 中命令的单独解析器，而且它已经在待办事项列表中很长时间了，所以现在每个命令都没有结构化的参数和参数格式，而为命令创建这样的结构可能需要几个月的工作！

我建议不要为每个命令使用一个唯一的函数。相反，我们可以创建一个框并将所有用户输入传递给“解释器”函数。我开始逐步导出 SDK 中的所有命令（目前，我正在努力导出读取/写入内存等基本功能，现在，我正在努力为您提供对寄存器的读取/写入）。我认为在 SDK 中导出功能比将它们传递给“解释器”函数更好，因为这样我们可以删除解释阶段并使其更快。

你觉得怎么样？

[ddkwork]

我觉得我们应该保持现状，因为那样会增加工作量，意思就是命令解析和检查保持让libhyperdbg继续解析。然而，在ui交互的时候，去脑海中拼接每个命令函数的参数个数和类型等等这有点难以记忆，所以我的做法是命令函数的参数个数，类型还是要写进json，然后我把他们封装在调用每个命令的形参位置，这样调用命令函数的时候相当于它有静态语法检查我是否误传了参数，在调用命令函数之前我会通过参数类型将所有参数格式化为完整命令，其余的检查事宜仍然由dll完成。

---Original--- From: "Sina @.> Date: Sun, Jul 7, 2024 18:08 PM To: @.>; Cc: @.**@.>; Subject: Re: [HyperDbg/gui] Generate all command api functions using json withhierarchical command types and handle the respective arguments (Issue #169)

Ah, I got what you mean. Honestly, this is really hard to make because I created this JSON file manually. Unfortunately, we don't have a separate parser for the commands in libhyperdbg and it's been on the to-do list for a long time, so right now each command doesn't have structured arguments and parameters format, and making such a structure for commands probably needs months of work!

I suggest not to use a unique function for each command. Instead, we could create a box and pass all of the user inputs to the 'interpreter' function. I started to export all of the commands in the SDK gradually (for now, I'm working on exporting essential functionalities like reading/writing memory, and right now, I'm working on providing read/write into registers for you). I think having functionalities exported in the SDK is better than passing them to the 'interpreter' functions since this way we could remove the interpreting phase and make it faster.

What do you think of it?

啊，我明白你的意思了。老实说，这真的很难做，因为我手动创建了这个 JSON 文件。不幸的是，我们没有 libhyperdbg 中命令的单独解析器，而且它已经在待办事项列表中很长时间了，所以现在每个命令都没有结构化的参数和参数格式，而为命令创建这样的结构可能需要几个月的工作！

我建议不要为每个命令使用一个唯一的函数。相反，我们可以创建一个框并将所有用户输入传递给“解释器”函数。我开始逐步导出 SDK 中的所有命令（目前，我正在努力导出读取/写入内存等基本功能，现在，我正在努力为您提供对寄存器的读取/写入）。我认为在 SDK 中导出功能比将它们传递给“解释器”函数更好，因为这样我们可以删除解释阶段并使其更快。

你觉得怎么样？

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

[ddkwork]

I think we should leave it as it is because that would increase the workload, meaning that the command parsing and checking stays for libhyperdbg to continue parsing. However, when interacting with the ui, it's a bit hard to remember the number and type of arguments for each command function, so what I've done is to write the number and type of arguments for the command function into the json, and then I've encapsulated them in the formal parameter of the call to each command, so that when calling the command function, it's equivalent to having a static syntax to check that I haven't passed the arguments by mistake, and I'll format all the arguments into the full command by their type before calling the command function.Before calling the command function, I will format all the parameters into full commands by parameter type and pass them to the dll, the rest of the checking is still done by the dll.

[SinaKarvandi]

okay, so anything else you need on my side? Right now, I'm working on providing the SDK APIs for the reading/writing registers. It's available here (https://github.com/HyperDbg/HyperDbg/tree/register-api), but it's not done yet. I need to make a comprehensive test to see if it works or not. I'll let you know once it's ready.

好的，您还需要我提供什么吗？目前，我正在努力提供用于读取/写入寄存器的 SDK API。它可在此处获得（https://github.com/HyperDbg/HyperDbg/tree/register-api），但尚未完成。我需要进行全面测试以查看它是否有效。一旦准备好，我会通知您。

[ddkwork]

json需要更改，我在之前的图片和gif中说明了怎么改了

---Original--- From: "Sina @.> Date: Sun, Jul 7, 2024 18:53 PM To: @.>; Cc: @.**@.>; Subject: Re: [HyperDbg/gui] Generate all command api functions using json withhierarchical command types and handle the respective arguments (Issue #169)

okay, so anything else you need on my side? Right now, I'm working on providing the SDK APIs for the reading/writing registers. It's available here (https://github.com/HyperDbg/HyperDbg/tree/register-api), but it's not done yet. I need to make a comprehensive test to see if it works or not. I'll let you know once it's ready.

好的，您还需要我提供什么吗？目前，我正在努力提供用于读取/写入寄存器的 SDK API。它可在此处获得（https://github.com/HyperDbg/HyperDbg/tree/register-api），但尚未完成。我需要进行全面测试以查看它是否有效。一旦准备好，我会通知您。

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

[SinaKarvandi]

ok

[SinaKarvandi]

I send you an updated version of the JSON (in email). We don't have such a thing as arguments separately in HyperDbg since it's not standard available in HyperDbg so other than the arguments, I think other issues are fixed.

我会向您发送 JSON 的更新版本（通过电子邮件）。HyperDbg 中没有单独的参数，因为它不是 HyperDbg 中的标准配置，因此除了参数之外，我认为其他问题都已修复。

[ddkwork]

好的

---Original--- From: "Sina @.> Date: Sun, Jul 7, 2024 19:30 PM To: @.>; Cc: @.**@.>; Subject: Re: [HyperDbg/gui] Generate all command api functions using json withhierarchical command types and handle the respective arguments (Issue #169)

I send you an updated version of the JSON (in email). We don't have such a thing as arguments separately in HyperDbg since it's not standard available in HyperDbg so other than the arguments, I think other issues are fixed.

我会向您发送 JSON 的更新版本（通过电子邮件）。HyperDbg 中没有单独的参数，因为它不是 HyperDbg 中的标准配置，因此除了参数之外，我认为其他问题都已修复。

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

[ddkwork]

我正在优化编译后的文件大小，这可能需要很久，因为要重构底层的ui库，不知道会不会成功 https://github.com/HyperDbg/gui/issues/167

---Original--- From: "Sina @.> Date: Sun, Jul 7, 2024 19:30 PM To: @.>; Cc: @.**@.>; Subject: Re: [HyperDbg/gui] Generate all command api functions using json withhierarchical command types and handle the respective arguments (Issue #169)

I send you an updated version of the JSON (in email). We don't have such a thing as arguments separately in HyperDbg since it's not standard available in HyperDbg so other than the arguments, I think other issues are fixed.

我会向您发送 JSON 的更新版本（通过电子邮件）。HyperDbg 中没有单独的参数，因为它不是 HyperDbg 中的标准配置，因此除了参数之外，我认为其他问题都已修复。

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

[SinaKarvandi]

Okay, I'm currently working on the registers SDK API.

好的，我目前正在研究寄存器 SDK API。

[ddkwork]

json seems very good👍🏻， it working now finally

---Original--- From: "Sina @.> Date: Sun, Jul 7, 2024 19:45 PM To: @.>; Cc: @.**@.>; Subject: Re: [HyperDbg/gui] Generate all command api functions using json withhierarchical command types and handle the respective arguments (Issue #169)

Okay, I'm currently working on the registers SDK API.

好的，我目前正在研究寄存器 SDK API。

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

[SinaKarvandi]

Great.

[ddkwork]

Great.

[ddkwork]

func InterpreterEx(command string) int32 { //todo decode command return status code as error string ? code := Interpreter(StringToBytePointer(command)) }

[ddkwork]

这个命令已经在sdk的导出api中了，重复了，

var __imp_hyperdbg_u_continue_debuggee bindlib.PreloadProc
func ContinueDebuggee() { bindlib.CCall0(__imp_hyperdbg_u_continue_debuggee.Addr()) }

[ddkwork]

Most fullnames need to be renamed, they are not easy to remember. naming rules for fullnames: shortest possible word, in the same order as the command name, in the case that the command script may be generated synchronously while calling the command wrapper function. I have written the renamed names in the unit test, you need to update the json again.

https://github.com/HyperDbg/gui/blob/main/sdk/bindgen/command_test.go

output:

https://github.com/HyperDbg/gui/blob/main/sdk%2FcommandWrapper.go

[ddkwork]

why dt command is cpu ?

    {
        "Name": "cpu",
        "Description": "cpu : collects a report from cpu features.",
        "Syntax": [
            "cpu "
        ],
        "Examples": [
            "dt nt!_EPROCESS",
            "dt nt!_EPROCESS fffff8077356f010",
            "dt nt!_EPROCESS $proc",
            "dt nt!_KPROCESS @rax+@rbx+c0",
            "!dt nt!_EPROCESS 1f0300",
            "dt nt!_MY_STRUCT 7ff00040 pid 1420",
            "dt nt!_EPROCESS $proc inline all",
            "dt nt!_EPROCESS fffff8077356f010 inline no"
        ],
        "Notes": [],
        "FullName": "CollectsReportFromCpuFeatures"
    },

// CpuFeaturesForCollectsReport
// Syntax:
// cpu
// Examples:
// dt nt!_EPROCESS
// dt nt!_EPROCESS fffff8077356f010
// dt nt!_EPROCESS $proc
// dt nt!_KPROCESS @rax+@rbx+c0
// !dt nt!_EPROCESS 1f0300
// dt nt!_MY_STRUCT 7ff00040 pid 1420
// dt nt!_EPROCESS $proc inline all
// dt nt!_EPROCESS fffff8077356f010 inline no
func CpuFeaturesForCollectsReport() { // cpu : collects a report from cpu features.
    InterpreterEx("cpu")
}

[ddkwork]

Now, all the commands have been loaded into event callbacks in ui widgets or context menus, but there are so many commands that I'm thinking of laying out new panels for the commands, and as far as the current layout of the cpu tabs is concerned, there are two options:. 1 Grouping the context menu, which fulfills the feature I requested from you before: group all commands according to your source code directory tree, then in the context menu that pops up with a right click I can just traverse the layout by group. So it makes sense to group the commands into a tree structure, i.e.: insert a parent field into the current json field to indicate whether it belongs to a debugging command or an expansion command or something.

2 In the middle of the disassembly layout and the register layout, I now reserve a certain width of area for the user to edit comments or for the engine to automatically annotate the disassembly with symbol parsing, or whatever other useful information. From experience with ollydbg, the comment function for the debugging process is very useful. So from a user-friendly design point of view, it makes sense that that area should be occupied by the function just described.

At first I thought about laying out all the commands in that area, but now I think about it it doesn't make much sense.

Currently I haven't tucked in the callback for editing disassembly comments, which should double-click on the disassembly's selected line to bring up a panel on which to edit comments or notes.

[ddkwork]