Log in

View Full Version : General help


nergal
January 28th, 2006, 11:42
I need some basic information regarding hexedit and patching.
How many bytes is one row if the exe file is opened in an hexeditor?
Is one row 16 bits (2 bytes)?

I've found some intresting jumps in the target application. If I wanna NOP out theese jumps that I found in the exe file, how do I know how much I should NOP? Is that common ASM knowledge how many bits a specific operation is?

naides
January 28th, 2006, 11:54
A1:
Your question is not clear. A row as in the rows of bytes you see in the hex editor?
it depends on the particular editor the size of the window and it may even be adjusted by the user.
Q2:
you need to know the length of that particular jmp instruction. in 32 bit code, there are 2 general types of jumps

short jmp will go within 128 bytes above or below the code. They are 2 bytes long, and need to be 'nopped' with two nop instructions

ie EB01: jmp XXXXXXXX
to
90: nop
90 : nop

And long jmp which are 5 bytes long, and can go anywhere in the memory space:

E945FFFFFFFF: jmp XXXXXXXXX

needs 5 nops

Admiral
January 28th, 2006, 14:26
I'll just reiterate what naides said:

The column width of a hex-editor is purely aesthetic and varies from one editor to the next. Common values will be powers of two and multiples of four.

Regarding instruction lengths: x86 instructions vary from one byte in length to (in theory) fifteen. Though you'll rarely see anything above eight. However, there should be no mystery as to how long your instruction is. Whatever debugger you're using, it should give you a few fields of information for every instruction, in its disassembly window. Usually these will include

The virtual address (VA) of the intruction
The opcodes of the instruction
The mnemonics of the instruction

along with information regarding branching, prefixes, comments and any references to remarkable memory locations. For example (a snippet from ntdll's exception handling code):

Code:
7C90EAFF 59 POP ECX
7C90EB00 6A 00 PUSH 0
7C90EB02 51 PUSH ECX
7C90EB03 E8 11EBFFFF CALL ntdll.ZwContinue
7C90EB08 EB 0B JMP SHORT ntdll.7C90EB15


Suppose you wanted to NOP the JMP SHORT.
You'd first locate the address of the instruction. Obviously, this is 0x7C90EB08 in memory, but it would be different if you wanted to patch ntdll.dll on disk... This, of course, isn't advisable
Second, you'd make sure that you have the bytes EB 0B at your cursor, next you'd overwrite the two of them with 90.

So in general, if you're planning to NOP an instruction, the number of 0x90s needed will be exactly the length (in bytes) of the entry in the opcode field.

However, if you're only patching in memory, you're taking three sides of a square. Any debugger worth the disk-space it's written on will have a one- or two-click (or one or two word) feature for NOPing the instruction at any given address. I know there are at least three easy ways to do this from OllyDbg, and I can only assume that SoftICE can do the same with a 1-parameter command.

Regards
Admiral

nergal
January 28th, 2006, 15:07
Thanks, I've understand the parts with virtual addresses etc. Think I've got to read some about that PE structure as well.

LLXX
January 29th, 2006, 06:00
Quote:
[Originally Posted by nergal]How many bytes is one row if the exe file is opened in an hexeditor?
Quote:
[Originally Posted by Admiral]The column width of a hex-editor is purely aesthetic and varies from one editor to the next. Common values will be powers of two and multiples of four.
On all the hex editors I've used, the line width is 16 bytes, in the following standard format:
Code:
0000 0A 05 54 B3 61 04 22 ED-00 F0 86 00 3C 05 15 16 ..T.a.".....<...
0010 00 00 56 96 01 00 64 94-69 9A 01 01 00 00 E0 25 ..V...d.i......%
0020 80 00 00 00 01 00 00 E8-00 7C 00 00 01 02 00 00 .........|......
0030 00 00 CC 03 7F 99 00 00-00 7E 00 00 00 02 00 80 .........~......
0040 00 00 FF 02 00 10 25 01-02 00 00 10 00 00 00 7C ......%........|
0050 01 00 80 00 00 00 00 00-00 00 05 00 01 00 80 00 ................
0060 01 00 00 7C E4 44 8B 42-00 F0 02 0C 10 42 02 00 ...|.D.B.....B..
0070 F8 03 F8 02 00 00 00 00-78 03 00 00 00 00 0F 02 ................
This "variable line length" must be a new trend in hexing...

Silver
January 29th, 2006, 08:12
Quote:
This "variable line length" must be a new trend in hexing...


Not too new, Ultraedit has had the option to set a custom line length for quite some time (years)..