| View previous topic :: View next topic |
| Author |
Message |
iPromise
Grandmaster Cheater
![]() Reputation: -1
Joined: 27 Jun 2009
Posts: 529
Location: Canada
|
 Posted: Mon May 30, 2011 7:23 pm Post subject: NOP |
 |
|
I'm one step away from completing my memory engine. I want to add a feature to my debugger allowing the user to NOP the address. I can do it all, but one thing that has got me thinking is knowing how many bytes the address occupies / is using.
I can just set the first byte at address ex: 00400000 to nop, I need to set nop to the total amount of bytes it occupies.
For example, sometimes we have addresses that have this inline asm:
add [eax], al
Which takes 2 bytes of memory.
How do I know how many bytes the address is using?
|
|
| Back to top |
|
 |
sponge
I'm a spammer
 Reputation: 1
Joined: 07 Nov 2006
Posts: 6009
|
|
| Back to top |
|
|
iPromise
Grandmaster Cheater
![]() Reputation: -1
Joined: 27 Jun 2009
Posts: 529
Location: Canada
|
| Posted: Mon May 30, 2011 8:03 pm Post subject: |
|
|
EDIT
I tried testing it on my own testing application, and it keeps displaying a length of 2 while CE displays a length of 1.
| Code: |
// just a test
DWORD dwBase = (DWORD) GetModuleHandleA ( NULL );
hde64s hs;
hde64_disasm ( (void*) dwBase, &hs );
cout << "dwBase: " << (LPVOID) dwBase << " " << (unsigned int) hs.len << endl;
|
EDIT AGAIN
I ran their example code. I don't think this library was meant for disassebling addresses. I think its for dissassembling a series of bytes. Check out their example code..
| Code: |
char fmt[] = "\n"
" mov rax,0x1122334455667788\n\n"
" length of command: 0x%02x\n"
" immediate64: 0x%08x%08x\n";
unsigned char code[] = {0x48,0xb8,0x88,0x77,0x66,0x55,0x44,0x33,0x22,0x11};
int main(void)
{
hde64s hs;
unsigned int length = hde64_disasm(code,&hs);
if (hs.flags & F_ERROR)
printf("Invalid instruction !\n");
else
printf(fmt,length,(uint32_t)(hs.imm.imm64 >> 32),
(uint32_t)hs.imm.imm64);
return 0;
}
|
|
|
| Back to top |
|
|
sponge
I'm a spammer
Reputation: 1
Joined: 07 Nov 2006
Posts: 6009
|
| Posted: Mon May 30, 2011 8:57 pm Post subject: |
|
|
(void*)dwBase is a series of bytes (sort of). It gets casted back to unsigned char* in hde64_disasm, which for all intents and purposes is unsigned char[].
_________________
Last edited by sponge on Mon May 30, 2011 9:05 pm; edited 1 time in total |
|
| Back to top |
|
|
Innovation
Grandmaster Cheater
![]() Reputation: 12
Joined: 14 Aug 2008
Posts: 617
|
| Posted: Mon May 30, 2011 9:00 pm Post subject: |
|
|
| iPromise wrote: | | I don't think this library was meant for disassebling addresses. I think its for dissassembling a series of bytes. |
A review of pointers might serve you well.
Anyway, you do notice that you're using the 64-bit version of the disassembler, right?
|
|
| Back to top |
|
|
sponge
I'm a spammer
Reputation: 1
Joined: 07 Nov 2006
Posts: 6009
|
| Posted: Mon May 30, 2011 9:07 pm Post subject: |
|
|
| Innovation wrote: | | iPromise wrote: | | I don't think this library was meant for disassebling addresses. I think its for dissassembling a series of bytes. |
A review of pointers might serve you well.
Anyway, you do notice that you're using the 64-bit version of the disassembler, right? |
The fact that he's using the 64-bit version should not matter as its actually geared for x86-64 (x86 is a subset of x64). Anyways, GetModuleHandle() will return the image base of the main module which is the PE header, which means its not really an instruction...
_________________
|
|
| Back to top |
|
|
Innovation
Grandmaster Cheater
![]() Reputation: 12
Joined: 14 Aug 2008
Posts: 617
|
| Posted: Mon May 30, 2011 9:31 pm Post subject: |
|
|
| sponge wrote: | | The fact that he's using the 64-bit version should not matter as its actually geared for x86-64 (x86 is a subset of x64). Anyways, GetModuleHandle() will return the image base of the main module which is the PE header, which means its not really an instruction... |
Might there be an unimplemented opcode in x86 that's implemented in x86-64?
|
|
| Back to top |
|
|
iPromise
Grandmaster Cheater
![]() Reputation: -1
Joined: 27 Jun 2009
Posts: 529
Location: Canada
|
| Posted: Mon May 30, 2011 9:39 pm Post subject: |
|
|
I used the base address as an example run. I used it to obtain the length of the bytes from that address.
I might be confused I dont know, but isn't the use of library to find the bytes taken up by an address, not an instruction?
For example, if address 00400000 had the following inline assembly:
add [eax], al
It would take up 2 bytes. CE would translate add [eax], al to 00 00. What i'm trying to do is i'm trying to find out how many bytes are used up for the address from its instruction without having to know its instruction.
For example address 00500000 is push eax, so its considered 50. So 1 byte.
etc.
Did i make any sense at all..?
|
|
| Back to top |
|
|
Innovation
Grandmaster Cheater
![]() Reputation: 12
Joined: 14 Aug 2008
Posts: 617
|
| Posted: Mon May 30, 2011 10:08 pm Post subject: |
|
|
| iPromise wrote: | I used the base address as an example run. I used it to obtain the length of the bytes from that address.
I might be confused I dont know, but isn't the use of library to find the bytes taken up by an address, not an instruction?
For example, if address 00400000 had the following inline assembly:
add [eax], al
It would take up 2 bytes. CE would translate add [eax], al to 00 00. What i'm trying to do is i'm trying to find out how many bytes are used up for the address from its instruction without having to know its instruction.
For example address 00500000 is push eax, so its considered 50. So 1 byte.
etc.
Did i make any sense at all..? |
An address is a memory location. It's an index. In x86, an address has a length of 4 bytes, ranging from 0x00000000 to 0xFFFFFFFF. In x86-64, an address has a length of 8 bytes, ranging from 0x0000000000000000 to 0xFFFFFFFFFFFFFFFF. The instruction pointer (EIP or RIP) is what tells the CPU what address the next opcode to execute is at.
Here's an abstract description:
Think of an application as a vast array of bytes (don't worry about whether they are all allocated are not). The CPU is provided an index into the array as to where an opcode is. First, the CPU determines what instruction it is based on the first few bytes (to illustrate what byte(s) means what, see http://ref.x86asm.net/). Using that, it determines what following bytes are operands. It increases the index by the length of the instruction and then executes the instruction. The only thing that the CPU knows with regards to the instruction cycle is that it needs to execute what's at that address (if you abstract away things such as branch prediction). If you gave the CPU an index into the middle of an opcode, it will not know that.
In short, you cannot know the length of an operation without knowing what the operation is, and the difference between what is an opcode and what is data is arbitrary since it's all the same in memory. The disassembler will work fine for your purposes as long as you provide an address to an actual opcode (something executed by the CPU).
|
|
| Back to top |
|
|
|
FAQ
Search
Memberlist
Usergroups
Register
Profile
Log in to check your private messages
Log in
