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?

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

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):



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

Thanks, I've understand the parts with virtual addresses etc. Think I've got to read some about that PE structure as well.

On all the hex editors I've used, the line width is 16 bytes, in the following standard format:
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)..