0f 85 takes a dword or rel32 or 4 bytes in 32 and 64 bit mode
and two bytes or rel16 in 16 bit mode
I assume 32 /64 bit because (hex view in your screen shot has a selection of 6 bytes highlighted )
0f 85 b5 00 00 00
to jmp with e9
change 0f 85 b5 00 00 00 to e9 b6 00 00 00 90
0:000> eb .
00007ffc`01d82dbc cc 0f
00007ffc`01d82dbd eb 85
00007ffc`01d82dbe 00 b5
00007ffc`01d82dbf 48 00
00007ffc`01d82dc0 83 00
00007ffc`01d82dc1 c4 00
00007ffc`01d82dc2 38
0:000> u . l1
ntdll!LdrpDoDebuggerBreak+0x30:
00007ffc`01d82dbc 0f85b5000000 jne ntdll!LdrpGetProcApphelpCheckModule+0xab (00007ffc`01d82e77)
0:000> eb .
00007ffc`01d82dbc 0f e9
00007ffc`01d82dbd 85 b6
00007ffc`01d82dbe b5 00
00007ffc`01d82dbf 00 00
00007ffc`01d82dc0 00 00
00007ffc`01d82dc1 00
0:000> u . l1
ntdll!LdrpDoDebuggerBreak+0x30:
00007ffc`01d82dbc e9b6000000 jmp ntdll!LdrpGetProcApphelpCheckModule+0xab (00007ffc`01d82e77)
0:000>
or as igorsk edited in nop the first byte and modify the second and third byte
0:000> eb .
00007ffc`01d82dbc e9 90
00007ffc`01d82dbd b6 e9
00007ffc`01d82dbe 00 b5
00007ffc`01d82dbf 00 00
00007ffc`01d82dc0 00 00
00007ffc`01d82dc1 00 00
00007ffc`01d82dc2 38
0:000> u . l2
ntdll!LdrpDoDebuggerBreak+0x30:
00007ffc`01d82dbc 90 nop
00007ffc`01d82dbd e9b5000000 jmp ntdll!LdrpGetProcApphelpCheckModule+0xab (00007ffc`01d82e77)
0:000>
for an unconditional jump the byte immediately to the patched instructions do not matter if the patched bytes are less.
but for other instructions which will fall through to the next instruction the instruction boundaries do matter
suppose you patched add to sub and sub is one byte less.
so after executing sub which is one byte lesser the next instruction will start executing on the bogus rogue byte.
this is not what was intended.
we need to execute the byte which was the originally supposed to be executed and we cant fly in mid air.
we need to also execute the dummy rogue byte
so we change it to a one byte no operation instruction.
execute sub as well as nop and then we get to execute the actual original next instruction.
that is why the nop it may look silly here for this specific instruction but it is a good habit to patch all the bytes within instruction boundaries.
there are single byte nop as well as multibyte nops or instructions like
mov eax,eax which do not alter the state but provide space fillers.
btw when you read the instruction manuals rel32 is always a counter it is counted from the start of next instruction
a simple jump eb 00 at address 0x1000 jumps to 0x1002 because eb 00 is two bytes
adding 2 to 0x1000 will make the next $ip 0x1002
so eb 01->0x1003 , eb 02 -> 0x1004 and so on