The debug target's oep has been parsed and disassembled correctly, however, neither ollydbg nor x64dbg are disassembling the buffer out of the oep by default, why? #168
Comments
|
测试载入cli可复现问题，发现x64dbg不是停留在oep，等start命令通过测试后再来处理这个 |
|
Hi,
Do you mean that x64dbg could not get the entrypoint either? Or just
HyperDbg cannot intercept it?
你好，
你的意思是 x64dbg 也无法获取入口点？还是 HyperDbg 无法拦截它？
…On Thu, Jul 11, 2024 at 1:18 PM ddkwork ***@***.***> wrote:
测试载入cli可复现问题，发现x64dbg不是停留在oep，等start命令通过测试后再来处理这个
—
Reply to this email directly, view it on GitHub
<#168 (comment)>, or
unsubscribe
<https://github.com/notifications/unsubscribe-auth/AIJP5JFPK3HQN2CDLGIWMM3ZLYBR5AVCNFSM6AAAAABKORXI52VHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZDEMRRHE4TENRXHE>
.
You are receiving this because you were assigned.Message ID:
***@***.***>
|
|
标题可能需要更改，具体问题应该是这样描述的:
当载入exe到x64dbg和ollydbg之后，发现他们默认停留的地址有的是oep，有的不是。
复现步骤为:拖放cli.exe 到gui，看它呈现的反汇编发现，我们解析的oep和buffer是正确的，反汇编也没什么异常。然而另外两个调试器它不是取原始oep的buffer来停留在调试器的入口点。
经过测试有些app他俩反汇编的入口点和我们的又是一样的，因为他俩又取了真实的oep buffer来显示。
这可能是调试器设置页面的:是否停留在系统断点还是oep的设置。
我不知道这个差异这会有什么副作用，但是他们的调试器应该是我们的参照物。
…---Original---
From: "HyperDbg ***@***.***>
Date: Thu, Jul 11, 2024 12:40 PM
To: ***@***.***>;
Cc: ***@***.******@***.***>;
Subject: Re: [HyperDbg/gui] The debug target's oep has been parsed anddisassembled correctly, however, neither ollydbg nor x64dbg are disassemblingthe buffer out of the oep by default, why? (Issue #168)
Hi,
Do you mean that x64dbg could not get the entrypoint either? Or just
HyperDbg cannot intercept it?
你好，
你的意思是 x64dbg 也无法获取入口点？还是 HyperDbg 无法拦截它？
On Thu, Jul 11, 2024 at 1:18 PM ddkwork ***@***.***> wrote:
> 测试载入cli可复现问题，发现x64dbg不是停留在oep，等start命令通过测试后再来处理这个
>
> —
> Reply to this email directly, view it on GitHub
> <#168 (comment)>, or
> unsubscribe
> <https://github.com/notifications/unsubscribe-auth/AIJP5JFPK3HQN2CDLGIWMM3ZLYBR5AVCNFSM6AAAAABKORXI52VHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZDEMRRHE4TENRXHE>
> .
> You are receiving this because you were assigned.Message ID:
> ***@***.***>
>
—
Reply to this email directly, view it on GitHub, or unsubscribe.
You are receiving this because you were assigned.Message ID: ***@***.***>
|
|
或许我应该录制一个gif来展示这个困惑。有点难以描述。 |
|
okay |
SinaKarvandi
assigned SinaKarvandi and ddkwork and unassigned ddkwork, HyperDbgBot and SinaKarvandi
I just found out why, the address it stays at is the tls callback |
|
Do you mean the address is modified in TLS? Is the target binary packed or protected by anti-debugging methods? 你的意思是地址在 TLS 中被修改了吗？目标二进制文件是否被加壳或受到反调试方法的保护？ |
|
It's not tls that's been modified. I don't know the correct logic at the moment, but I think it's something like this: the
The tls callback shouldn't be in every app?I will take out the tls when pe is parsed and see if the x64dbg takes the same address as mine. If it's the same then I also ignore the oep disassembly and in turn take the buffer of the tls callback address and disassemble it?
I'm not sure if the logic is correct yet, I'll verify it after a while.
…---Original---
From: "Sina ***@***.***>
Date: Thu, Jul 11, 2024 13:37 PM
To: ***@***.***>;
Cc: ***@***.******@***.***>;
Subject: Re: [HyperDbg/gui] The debug target's oep has been parsed anddisassembled correctly, however, neither ollydbg nor x64dbg are disassemblingthe buffer out of the oep by default, why? (Issue #168)
Do you mean the address is modified in TLS? Is the target binary packed or protected by anti-debugging methods?
你的意思是地址在 TLS 中被修改了吗？目标二进制文件是否被加壳或受到反调试方法的保护？
—
Reply to this email directly, view it on GitHub, or unsubscribe.
You are receiving this because you were assigned.Message ID: ***@***.***>
|
|
目标应该没有被保护，因为我测试的是hyperdbg cli.exe
…---Original---
From: "Sina ***@***.***>
Date: Thu, Jul 11, 2024 13:37 PM
To: ***@***.***>;
Cc: ***@***.******@***.***>;
Subject: Re: [HyperDbg/gui] The debug target's oep has been parsed anddisassembled correctly, however, neither ollydbg nor x64dbg are disassemblingthe buffer out of the oep by default, why? (Issue #168)
Do you mean the address is modified in TLS? Is the target binary packed or protected by anti-debugging methods?
你的意思是地址在 TLS 中被修改了吗？目标二进制文件是否被加壳或受到反调试方法的保护？
—
Reply to this email directly, view it on GitHub, or unsubscribe.
You are receiving this because you were assigned.Message ID: ***@***.***>
|
|
你现在对start命令验证了吗？结果怎么样？说说测试的步骤，我也来验证一下😁👍
…---Original---
From: "Sina ***@***.***>
Date: Thu, Jul 11, 2024 12:54 PM
To: ***@***.***>;
Cc: ***@***.******@***.***>;
Subject: Re: [HyperDbg/gui] The debug target's oep has been parsed anddisassembled correctly, however, neither ollydbg nor x64dbg are disassemblingthe buffer out of the oep by default, why? (Issue #168)
Assigned #168 to @ddkwork.
—
Reply to this email directly, view it on GitHub, or unsubscribe.
You are receiving this because you were assigned.Message ID: ***@***.***>
|
|
After testing the tls callback table is empty, which shouldn't have any side effects, so abandon this plan |
|
Yes, I tested it without the '.start' command but it seems that it didn't start at the original entrypoint. That's expected since our process start methodology doesn't support TLS yet. 是的，我测试了没有使用“.start”命令，但它似乎没有从原始入口点启动。这是意料之中的，因为我们的进程启动方法尚不支持 TLS。 |
|
For your information, HyperDbg doesn't use DEBUG flags to CreateProcess since it negatively influences the debugger's transparency. We have our own method for running the target process without any help from Windows. 供您参考，HyperDbg 不使用 DEBUG 标志来 CreateProcess，因为它会对调试器的透明度产生负面影响。我们有自己的方法来运行目标进程，而无需 Windows 的任何帮助。 |
|
If you're interested to know how it's designed, I sent you a PDF (email). You can read this section: "6.1 Finding Entry Points". It describes how HyperDbg's '.start' command works. |
|
ok
…---Original---
From: "Sina ***@***.***>
Date: Thu, Jul 11, 2024 16:06 PM
To: ***@***.***>;
Cc: ***@***.***>;"State ***@***.***>;
Subject: Re: [HyperDbg/gui] The debug target's oep has been parsed anddisassembled correctly, however, neither ollydbg nor x64dbg are disassemblingthe buffer out of the oep by default, why? (Issue #168)
If you're interested to know how it's designed, I sent you a PDF (email). You can read this section: "6.1 Finding Entry Points". It describes how HyperDbg's '.start' command works.
如果你有兴趣了解它的设计，我给你发了一个 PDF（电子邮件）。你可以阅读本节：“6.1 Finding Entry Points”。它描述了 HyperDbg 的“.start”命令的工作原理。
https://arxiv.org/pdf/2405.00298
—
Reply to this email directly, view it on GitHub, or unsubscribe.
You are receiving this because you modified the open/close state.Message ID: ***@***.***>
|
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
The problem this causes is that the disassembled code displayed after loading the target being debugged is not the same as in other debuggers.
The text was updated successfully, but these errors were encountered: