User Tag List

Thread: ODB Hex Editor

Results 1 to 4 of 4
  1. #1 ODB Hex Editor 
    Master Developer superbadass's Avatar
    Join Date
    Aug 2014
    Thanked 530 Times in 32 Posts
    16 Post(s)
    0 Thread(s)
    No need to install it, only Download ODB Hexer and extract it.
    Now you can open it by doubleclick the Exe File.

    PrePs.: You also can use this simple Tool to only edit some Files Hex like the HxD Editor does.

    OllyDbg 2.0 supports all 80x86 commands, FPU, MMX, 3DNow!, SSE, SSE2, SSE3, SSSE3 and SSE4 extensions.
    Please note following peculiarities and deviations from Intel's standard:

    • REP RET (AMD branch prediction bugfix) is supported;
    • Multibyte NOPs (like NOP [EAX]) are supported. However, Assembler always attempts to select the shortest possible form, therefore it's hard to set the required NOP length;
    • FWAIT is always separated from the following FPU command. Assembler never adds FWAIT, for example, FINIT is in fact translated to FNINIT etc.;
    • No-operand forms of binary FPU commands are not supported, use two-operand forms (FADDP ST(1),ST instead of FADDP);
    • LFENCE: only form with E8 is accepted (0F AE E8);
    • MFENCE: only form with F0 is accepted (0F AE F0);
    • SFENCE: only form with F8 is accepted (0F AE F8);
    • PINSRW: register is decoded as 16-bit (only low 16 bits are used anyway);
    • PEXTRW: memory operand is not allowed, according to Intel;
    • SMSW: register is decoded as 16-bit (only low 16 bits are used anyway);
    • INSERTPS: source XMM register is commented only as a low float, whereas command may use any float;
    • Some FPU, MMX and SSE commands accept either register only or memory only in ModRM byte. If counterpart is not defined, Disassembler reports it as an unknown command. Integer commands, like LES, report in this case invalid operands.
    • SSE4 commands that use register XMM0 as a third operand are available both in 2- and in 3-operand formats, but Disassembler will show only the full 3-operand form;
    • Assembler accepts CBW, CWD, CDQ, CWDE with explicit AL/AX/EAX as operand. Disassembler, however, uses only implicit no-operand form.

    Dissambling Options

    OllyDbg supports four different decoding modes: MASM, Ideal, HLA and AT&T.
    MASM is the de facto standard of the assembler programming.
    Ideal mode, introduced by Borland, is very similar to MASM but differently decodes memory addresses.
    High Level Assembly language, created by Randall Hyde, uses yet another, functional syntax where first operand is a source and operands are taken into the brackets.
    AT&T syntax is popular among the Linux programmers.

    Undocumented commands
    OllyDbg recognizes several undocumented 80x86 commands:
    Command Hex code Comments
    INT1 (ICEBP) F1 1-byte breakpoint
    SAL D0 /6, D2 /6, C0 /6
    Arithmetic shift, identical with D0 /4 etc.
    SALC D6 Set AL on Carry Flag
    TEST F6 /1 Logical Test, identical with F6 /0
    F2:AD, F2:A5, ...
    String operations, REPNE is interpreted the same way as REP
    FFREEP DF /0 Free Floating-Point Register
    UD1 0F B9 Intentionally undefined instruction
    Disassembler supports all mentioned commands. Assembler will not generate non-standard SAL and TEST commands; if necessary, use binary edit to create binary codes.
    All constants in the OllyDbg are hexadecimal by default. If you want to specify decimal constant, follow it with the point:
    MOV EAX,1000. translates to MOV EAX,3E8
    Hexadecimal constant may begin with a letter (A-F), but symbolic labels have higher priority than hex numbers. Assume that you have defined label DEF at address 0x00401017. In this case,
    MOV EAX,ABC translates to MOV EAX,0ABC
    MOV EAX,DEF translates to MOV EAX,401017
    To avoid ambiguity, precede hexadecimal constants with 0 or 0x: MOV EAX,0DEF .
    There are only few exceptions to this rule. Indices of arguments and local variables are decimal. For example, ARG.10 is the address of the tenth call argument with offset 1010·4=4010=0x28. To memorize this rule, note that ARG and index are separated with a decimal point.
    Ordinals are also in decimal. COMCTL32.#332 means export with ordinal 33210.

    Other useful threds you can compare to this:

    I D A 6.6

    ARM Hex Translator
    Last edited by superbadass; 02-07-2015 at 01:15 AM.
    One Mod is good
    one Hack is better
    but Mods and Hacks
    forever are the best!

    You only live once
    so make the best of your life
    and be an ElementEvil VIP!

    Hidden Content

    Reply With Quote   ODB Hex Editor Send PM  

  2. ODB Hex Editor
    Join Date
    Jul 2014

  3. #2  
    Master Developer superbadass's Avatar
    Join Date
    Aug 2014
    Thanked 530 Times in 32 Posts
    16 Post(s)
    0 Thread(s)

    OllyDbg is an analysing debugger. For each module (executable file or DLL) it attempts to separate code from data, recognize procedures, locate embedded strings and switch tables, determine loops and switches, find function calls and decode their arguments, and even predict value of registers during the execution.
    This task is not simple. Some of the existing compilers are highly optimizing and use different tricks to accelerate the code. It’s impossible to take them all into account. Therefore the analyser is not limited to some particular compiler and tries to use generic rules that work equally good with any code.
    How is it possible at all? OllyDbg makes 12 passes through the program, each time gathering information that will be used on the next steps. For example, on the first pass it disassembles every possible address within the code sections and checks whether this can be the first byte of the command. Valid command can not start on fixup, it can’t be jump to the non-existing memory etc. Additionally it counts all found calls to every destination. Of course, many of these calls are artefacts, but it's unlikely that two wrong calls will point to the same command, and almost impossible that there are three of them. So if there are three or more calls to the same address, the analyser is sure that this address is entry point of some frequently used subroutine. On the second pass OllyDbg uses found entries as starting points for the code walk and determines other entries, and so on. In this way I locate commands that are 99.9% sure. Some bytes, however, are not in this chain. I probe them with 20 highly efficient heuristical methods. They are not as reliable, and analyser can make errors, but their number decreases with each release.


    Procedure is defined as a contiguous piece of code where, starting from the entry point, one can reach, at least theoretically, all other commands (except for NOPs or similar spaceholders that fill alignment gaps).
    Strict procedure has exactly one entry point and at least one return. If you select fuzzy mode, any more or less consistent piece of code will be considered separate procedure.
    Modern compilers perform global code optimizations that may split procedure in several parts. In such case fuzzy mode is especially useful. The probability of misinterpretation, however, is rather high.
    Procedures are marked by long fat parenthesis in the dump column. Dollar sign ($) to the right marks call destinations, sign "greater than" (>) - jump destinations, point (•) – other analysed commands.
    Three procedures on the picture below implement writing to the memory at address 0 (NULL pointer), INT3 and division by zero in the test application:
    Stack variables
    Usually call to the function with several stack arguments looks like this (assuming all doubleword arguments):
    ... PUSH argument3
    PUSH argument2 PUSH argument1 CALL F ...
    Called function creates new stack frame (not always!) and allocates N doublewords of local memory on the stack:
    After these two sequences are executed, stack will have the following layout:
    (unused memory) ESP-> local N [LOCAL.N] ... ... local 2 [LOCAL.2] local 1 [LOCAL.1] EBP-> Old EBP [LOCAL.0] Return address [RETADDR] argument1 [ARG.1] argument2 [ARG.2] argument3 [ARG.3] ...
    ARG.1 marks the address of the first function argument on the stack, [ARG.1] - its contents, ARG.2 address of the second argument and so on. LOCAL.0 is the address of the doubleword immediately preceding return address. If called function creates standard stack frame, then [LOCAL.0] contains preserved old ESP value and local data begins with LOCAL.1, otherwise local data begins with LOCAL.0. Note that ARGs and LOCALs have decimal indices - an exception justified by the point in the notation.
    Some subroutines tamper with the return address on the stack. If OllyDbg detects access to this location, it marks it as [RETADDR].
    When subroutine uses standard stack frame, register EBP serves as a frame pointer. LOCAL.1 is then simply a EBP-4, LOCAL.2 is EBP-8, ARG.1 is EBP+8 etc. Modern optimizing compilers prefer to use EBP as a general-purpose register and address arguments and locals over ESP. Of course, they must keep trace of all ESP modifications. Have a look at the following code:
    When procedure is called (address F, ESP points to the return address on the stack. Two doublewords below is the second argument, ARG.2. Command PUSH decrements ESP by 4. Therefore the last line accesses now ARG.1. The code is equivalent to:
    Of course, analyser makes this for you. Keeping trace of ESP, however, takes plenty of memory. If memory is low, you may turn off the ESP trace for system DLLs. As a negative effect, stack walk will get unreliable.
    Some compilers do not push each argument separately. Instead, they allocate memory on the stack (SUB ESP,nnn) and then write arguments using ESP as index. First doubleword argument is [ESP], second [ESP+4] and so on.
    This sample program was translated with MinGW (gcc).
    int main() { MessageBox(NULL,"I'm a little, little code in a big, big world...", "Hello, world",MB_OK); return 0; }
    Note the following: The order of arguments for MessageBox() is hOwner, Text, Caption, Type. MinGW has changed this order. Still, OllyDbg 2 was able to recognize the arguments.

    Known functions

    OllyDbg contains descriptions of more than 2200 standard API functions from the following libraries:
    It also knows more than 7800 symbolic constants, grouped into 490 types, and can decode them in the code:
    You can use known constants in assembler commands and arithmetic expressions. For example, CMP EAX,WM_PAINT is a valid command.


    Loop is a closed continuous sequence of commands where last command is a jump to the first. Loop must
    have single entry point and unlimited number of exits. Loops correspond to the high-level operators do, while and for. OllyDbg recognizes nested loops of any complexity. Loops are marked by parenthesis in the disassembly. If entry is not the first command in the loop, OllyDbg marks it with a small triangle.
    Below is the main loop of the threads created by the test application, together with the C code. Selected command is loop exit. Long red arrow shows its destination:
    ... while (1) { if (PeekMessage(&msg,NULL,0,0,PM_REMOVE)) { TranslateMessage(&msg); DispatchMessage(&msg); if (msg.message==WM_QUIT) break; }; if (GetTickCount()>t+100) { u++; t=GetTickCount(); sprintf(s,"Thread %i count %u",threadindex,u); SetWindowText(hw,s); }; Sleep(1); }; return threadindex;
    Note that sprintf() called at address 00401AC1 is a library function used by compiler and is not known as such. But there are other calls somewhere in the code, so analyser was able to decide that its second parameter is a format string, and has decoded the remaining parameters correspondingly.

    Switches and cascaded IFs

    To implement a switch, many compilers load switch variable into some register and then subtract parts of it, like in the following sequence:
    MOV EDX,<switch variable> SUB EDX,100 JB DEFAULTCASE JE CASE100 ; Case 100
    DEC EDX JNE DEFAULTCASE ... ; Case 101
    This sequence may also include one- and two-stage switch tables, direct comparisons, optimizations and other stuff. If you are deep enough in the tree of comparisons and jumps, it's very hard to say which case is it. OllyDbg does it for you. It marks all cases, including default, and even attempts to suggest the meaning of cases, like 'A', WM_PAINT or EXCEPTION_ACCESS_VIOLATION. If sequence of commands doesn't modify register (i.e. consists only of comparisons), then this is probably not a switch, but a cascaded if operator:
    if (i==100) {...} else if (i==101) {...} else if (i==102) {...}

    Prediction of registers

    Look at this code snippet:
    Analyser recognized that procedure at address 004012C0 is similar to printf: its first argument is a format string. (In fact, this function displays error messages). Such procedures may have variable number of arguments and use C-style conventions for the parameters, namely that arguments are remove from the stack by the calling program. Command ADD ESP,8 after the call does exactly this: it removes 8 bytes of data, or two doublewords from the stack. The first doubleword is the pointer to format string. Therefore this call must have one additional parameter. Format string indicates the same: it expects one pointer to the string.
    String address is the second argument in the call. By stating <%s> => OFFSET LOCAL.148 Ollydbg tells you the following: register EDX at the moment of PUSH EDX will contain address of the local variable 148 (148.-th doubleword preceding return address). Indeed, previous command (LEA EAX,[LOCAL.148]) loads this address to EDX.
    Symbol => in comments means "predicted to be equal to". For example, PUSH ECX will push address of the displayed format string... Wait! Operator at 0040960B just adds 0x1D37 to ESI. But where ESI is defined?
    If you look through the procedure, you will be able to restore the structure of the code:
    ... MOV ESI,OFFSET Ot.0045E7EC ; Here ESI is defined ... PUSH ESI ... ; Inlined strcpy() POP ESI ... CALL ... CALL OT.yyy ... LEA EDX,[LOCAL.148] ; Our code PUSH EDX LEA ECX,[ESI+1D37] PUSH ECX CALL Ot.004012C0 ADD ESP,8 ...
    At the beginning, program loads ESI with the address of static data block. This operation is not very meaningful here but would make more sense in the multithreaded applications that use thread local storage. Pair PUSH ESI/POP ESI preserves value of ESI from modification by inlined strcpy(): it uses MOVS. But then you see two calls to unknown functions xxx and yyy. Why analyser is sure that they leave ESI unchanged? Well, either analyser determined this directly from the code of xxx and yyy, or you told it by selecting corresponding analysis option. All API function and many separately compiled procedures use stdcall convention: functions should preserve registers EBX, EBP, ESI and EDI.

    Memory map

    General information
    Each 32-bit application runs in its own virtual 232-byte memory space. Only the lower part of this space (2 or 3 gigabytes) is available to the application. Windows fills it with executable modules, data blocks, stacks and system tables. Minimal allocation unit is a page (4096 bytes). Each page has several attributes that indicate whether page can be read, modified or executed. Except for this protection, there are no physical borders berween the memory blocks. If application allocates two blocks of data and they are adjacent by accident, nothing will prevent appplication from using them as a single data block.
    OllyDbg treats application's memory as a set of independent blocks. Any operation on the memory contents is limited to the block. In most cases, this works fine and facilitates debugging. But if, for example, module contains several executable sections, you will be unable to see the whole code at once.
    Memory map window displays all memory blocks available to the Debuggee. There are no standard means to determine where one block ends and another begins, so it may happen that OllyDbg will show several portions of allocated memory as a single memory block. But in most cases precise resolution is not necessary.
    Kernel memory
    Kernel (system) memory, allocated in the high memory area, is not directly accessible to the application. However, OS or driver may grant access to portions of this memory. For example, some antivirus programs redirect LoadLibrary, GetProcAddress and similar API functions to the kernel memory. OllyDbg can neither modify kernel memory, nor change memory attributes, nor set breakpoints of any kind. Redirected API calls are traced in a single-step trap mode.
    Ring 3 application has no means to get layout of the kernel memory, and direct scan can be very slow. For this reason, OllyDbg displays kernel memory as a single block where unavailable pages are filled with zeros instead of question marks, as in all other cases. The only available operation on kernel memory is search. Attention, full search may take several minutes!


    For each memory block, except for kernel, you can create a backup. This is a copy of the current memory contents. If backup is available, modifications are highlighted. You can view backup, restore modifications, save backup to disk or read it back. Saved backup is helpful if you want to see the differences between two runs.
    Backup is created automatically when you edit code or data in CPU window. Backup is necessary if you request run trace pause on modified command. See detailed description below in the section "Run trace and profiling".
    Break on memory access
    You can set one-shot breakpoint on access on the whole memory block. Any possible access (read, write or execution) will trigger a break and remove breakpoint.
    This kind of memory breakpoint is useful if you need to find calls to DLL or returns from such calls. Just place breakpoint on the code section.


    General information
    OllyDbg can debug multithreaded applications. Main thread of the Debuggee has ordinal number 1. Subsequent thread created by application are numbered 2, 3 and so on. If order in which application creates its threads is fixed, ordinal numbers remain the same in different debugging sessions.
    Sometimes OS creates its own threads, for example, if you pause the application with DebugBreakProcess(). OllyDbg calls such threads temporary and assigns them no ordinals:
    Column 'Window's title' contains title of the top-level window created by the thread. If thread creates several windows, OllyDbg will randomly select one of them.
    Column 'Last error' contains the most recent error code returned by call to API function. This is the value returned by GetLastError().
    You can manually suspend and resume threads. Note however that suspended threads are not resumed if OllyDbg detaches from the Debuggee.
    Stepping in multithreaded applications
    There is a caveat you must be aware when debugging multithreaded applications. All kinds of stepping, like step over, run trace, hit trace, or execute till return, are executed within the current thread. Imagine the following scenario: function xxx posts signal to the different thread and waits for answer. You step over the call to xxx. OllyDbg suspends all threads except for the current, sets temporary breakpoint on the command following call and continues execution. xxx posts signal, waits for answer, and... nothing happens, because thread that processes signal is paused.
    In this case pause program and run it in the all-threads mode. Temporary breakpoint remains active and will be hit shortly.


    Attaching to running processes
    You can attach OllyDbg to the running process, provided that you have sufficient privileges. From the main menu, select File | Attach... and choose process from the list of running processes. If main thread is suspended (for example, application was created as CREATE_SUSPENDED), OllyDbg will automatically resume it. For different reasons, this is not possible under Windows 2000. Attempt to attach to the suspended application will result in crash. While attaching, Windows creates new thread in the contents of the Debuggee. This thread executes DbgBreakPoint(), thus giving Debugger the chance to make all necessary preparations. The thread is marked as temporary by the OllyDbg. Under Windows 2000, OllyDbg is unable to recognize this thread as temporary and reports it as an ordinary thread.
    Attaching to running process is controlled by the following options:
    When attaching to application, make first pause at: System breakpoint - asks OllyDbg to pause application on the system breakpoint in the temporary thread. When attaching to application, make first pause at: Application code - asks to pause application in the main thread at the location that was executing at the moment of attaching. Usually this is ntdll.dll. When attaching to application, make first pause at: No pause - application should continue execution as soon as possible.

    Detaching from the debugging process

    Under Windows XP and higher OS versions, you can detach from the running process. From the main menu, select File | Detach. OllyDbg automatically removes all breakpoints, but does not resume suspended threads. Don't forget to do it manually!

    Debugging of child processes

    OllyDbg is a single-process debugger. To debug child processes, it launches new instances of itself, so that each child gets its own copy of the OllyDbg. This is possible only under Windows XP or higher Windows versions, and only if parent process was started by OllyDbg.
    Due to the limitations of the Windows, debugging of grandchildren is not supported. That is, if you debug process A and it spawns process B, B will be passed to the OllyDbg. If now B spawns process C, debugger will get no notification and C will run free. Of course, you can attach to the C later.
    Debugging of child processes is controlled by the option Debugging events | Debug child processes.


    OllyDbg supports three types of breakpoints:
    - INT3 breakpoints on code execution; - Memory breakpoints on memory access, write to memory or code execution; - Hardware breakpoints on memory access, write to memory or code execution.
    Additionally, you can set breakpoint on access to memory block (not available for DOS-based Windows versions). They are discussed previously.
    Number of INT3 and memory breakpoints is unlimited. Note that Windows protects memory only in chunks of 4096 bytes. Therefore, if memory breakpoint is set within the memory block with frequently accessed variables, OllyDbg will get many false breakpoints, which may significantly slow down the speed of execution. In some cases, run trace with allowed emulation of the commands may be faster! For details, see chapter "Run trace and profiling". Caveat: avoid setting memory breakpoints on the stack. If protected address is passed to the system, system call may fail, terminating the application.
    Number of hardware breakpoints is limited to 4 by the CPU.
    Simple breakpoint pauses execution each time the command is executed or memory is accessed. You may also set conditional logging breakpoints with many additional options. The picture below represents hardware breakpoint on the call to PeekMessageA() at address 0x0040191B in the main loop of the test application and corresponding protocol. Each time the breakpoint is hit, the parameters of the call are saved to the log. We want to pause application when received message is WM_LBUTTONDOWN. First parameter in the call is the pointer to the structure MSGA. It is pushed last and therefore has address [DWORD ESP], or simply [ESP]. Message identifier is the second element of the structure, doubleword at address [ESP]+4. Its contents, [[ESP]+4] is compared with the constant WM_LBUTTONDDOWN. If they are equal, execution will be paused:

    Run trace and profiling

    Run trace is the way to execute and protocol the debugged application command by command. In this way, one can locate the most frequently executed pieces of code, detect jumps to nowhere or just backtrace program execution that precedes some event.
    In its simplest form, run trace sets breakpoint on the next command and continues execution. This method, however, is very slow. Windows need up to hundred microseconds to pause application and pass debugging event to debugger. This limits run trace to 10-30 thousand commands per second.
    To accelerate run trace, OllyDbg can emulate commands internally, without passing control to the
    debuggee. The emulation is currently limited to the 55 frequently used integer commands, like MOV, ADD, CALL or conditional jumps. If command is not known or cannot be emulated (like SYSENTER), OllyDbg passes it to the application. Still, execution speed reaches 300-600 thousand, in simple loops up to one million commands per second. In many cases, this is sufficient for the "almost real-time" behaviour of Windows applications.
    Each traced command is protocolled to the large circular buffer. The protocol includes address, contents of the integer registers and flags. If you need, you may save command code, FPU registes and contents of the accessed memory. Note however that each additional option reduces the number of the commands in the buffer. For example, if buffer is 256 MB large and all extras are turned off, it keeps up to 16.7 million commands, and with extras on - only 7 to 10 million.
    Probably the most interesting feature of the run trace is its ability to pause execution when some event occurs (command Trace|Set condition... from the main menu):
    Option "EIP points to modified command" can be used to find entry point of the program packed by selfextractor. (By the way, hit trace in this case is much faster). When you start run or hit trace and option is active, Ollydbg compares actual command code with the backup copy and pauses when they differ. Of course, backup copy must exist. The simplest way to assure it is to activate Options|Debugging options|Auto backup user code.
    Pause on access to memory range can be implemented with memory breakpoints. Note however that 80x86 CPU protects memory only in 4096-byte chunks. If memory breakpoint is set on the small part of the actively used memory block, execution will cause large number of false debugging events. To recover, OllyDbg must remove memory protection, execute single command that caused exception and restore memory breakpoint again. This requires plenty of time. If command emulation is activated, run trace may be significantly - up to 20 times - faster than memory breakpoint.
    Condition is any valid expression, for example EAX==0 or ([BYTE 450002] & 0x80)!=0. Registers are taken from the actual thread. The evaluation of conditional expressions is very quick and has only minor influence on the run trace speed.
    If you need to know how frequently each traced command was executed, choose Comments | Show profile in the Disassembler, or Profile selected module or Global profile in the Run trace. In the first case, Comments column will show how many times this command is present in the trace data:
    In the two remaining cases Profile window will list traced commands, sorted by their frequency:
    As you can see, snippet at address 0040FF93 in module Test was executed most frequently.
    Run trace is controlled by the following set of options:
    Allow fast command emulation - allows OllyDbg to emulate some frequently used CPU commands internally, thus accelerating the debugging. Emulation is currently not compatible with the hardware
    breakpoints. If some hardware breakpoint is active, emulation is disabled;
    Size of run trace buffer - allocates memory for the circular buffer with run trace data. As a rule of thumb, one megabyte keeps 30000 - 60000 commands;
    Don't enter system DLLs - requests OllyDbg to execute calls to Windows API functions at once, in the trace-over mode. Note that if API functions call user-space callbacks, they will not be traced, too;
    Always trace over string commands - requests OllyDbg to trace over string commands, like REP MOVSB. If this option is deactivated, each MOVSB iteration will be protocolled separately;
    Remember commands - saves copy of the traced command to the trace buffer. Only necessary if debugged application uses self-modified code;
    Remember memory - saves actual contents of the addressed memory operands to the trace buffer;
    Remember FPU registers - saves floating-point registers to the trace buffer;
    Synchronize CPU and run trace - moves CPU selection and updates CPU registers each time you change selection in the Run trace protocol.

    Hit trace

    The sense of debugging is to find and remove all bugs from the debugged application. To approach this ideal, you need to execute every subroutine and every branch, otherwise latent errors are preprogrammed. But how do you know whether particular piece of code was executed? Hit trace will give you the answer.
    It starts from the actual location. OllyDbg sets INT3 breakpoints on all branches that were not traced so far. After trace breakpoint is reached, it removes it and marks command as hit. This allows to check at a glance whether some branch of code was executed. Here is an example: code at 004011CB was never executed.
    Hit tracing is astoundingly fast, after short startup period application runs with almost full speed. Problems may occur with indirect branches and calls, like CALL [0x405000] or JMP [0x123456+EAX*4]. In this case you have two options: either to check the destination each time, or use analysis results to guess the set of possible destinations. The first way is more reliable, the second is significantly faster. If you are in doubt, use the first option.
    Some malware and antivirus programs place the pieces of the code in the kernel memory (usually 0x80000000 and above). OllyDbg is unable to set INT3 breakpoints and continues in the step-by-step execution mode until the user memory is reached.
    Hit trace is controlled by the following set of options:
    Set breakpoints on known callbacks - if active, OllyDbg sets trace breakpoint on all known callback functions when hit trace starts, so that calls from Windows API functions, like SendMessage(), can be traced;
    When indirect or table-based jump or call is hit: Check destination each time / Use analysis data to guess destinations - controls tracing of indirect jumps and calls. The first option assures reliable hit trace, the second makes it faster;
    When next destination is analysed as data: Continue hit trace / Pause hit trace - this situation may happen either when Analyser erroneously recognized valid code as data, or if debugged program is selfmodified or creates code on-the-fly. In the second case, be careful: INT3 breakpoint may have disastrous effects on the execution!
    When next destination is outside the code section: Continue hit trace / Pause hit trace / Trace code
    command by command - if debugged program creates code on-the fly or loads it dynamically from the disc, setting INT3 breakpoints on it may lead to crash. Step-by-step tracing is the safest, but also the slowest option.


    Help on commands
    OllyDbg has integrated help on 80x86 commands. Select command and choose Help on command from the menu (shortcut: Shift+F1):
    OllyDbg attempts to describe exactly the selected command with its operands. Currently help is available for all integer, FPU and system commands. MMX, 3DNow! and SSE commands will be added in the next release.
    Help on API functions
    If you possess old Window's API help file win32.hlp, you can attach it to the OllyDbg in Options | Directories | Location of API help file. To get help on API, select call to system DLL and press Ctrl+F1 (or choose Help on API function from menu).
    Due to the legal reasons, API help file is not included into the distribution.
    One Mod is good
    one Hack is better
    but Mods and Hacks
    forever are the best!

    You only live once
    so make the best of your life
    and be an ElementEvil VIP!

    Hidden Content

    Reply With Quote   ODB Hex Editor Send PM  

  4. #3  
    Master Developer superbadass's Avatar
    Join Date
    Aug 2014
    Thanked 530 Times in 32 Posts
    16 Post(s)
    0 Thread(s)

    Imprecise Assembler search patterns
    When searching for command or sequence of commands, you can specify imprecise Assembler patterns that match many different instructions. For example, MOV EAX,ANY will match MOV EAX,ECX; MOV EAX,12345; MOV EAX,[FS:0] and many other commands.
    Imprecise patterns use following keywords:
    Keyword Matches
    R8 Any 8-bit register (AL,BL, CL, DL, AH, BH, CH, DH) R16 Any 16-bit register (AX, BX, CX, DX, SP, BP, SI, DI) R32 Any 32-bit register (EAX, EBX, ECX, EDX, ESP, EBP, ESI, EDI) SEG Any segment register (ES, CS, SS, DS, FS, GS) FPUREG Any FPU register (ST0..ST7) MMXREG Any MMX register (MM0..MM7) SSEREG Any SSE register (XMM0..XMM7) CRREG Any control register (CR0..CR7) DRREG Any debug register (DR0..DR7) CONST Any constant ANY Any register, constant or memory operand
    You can freely combine these keywords in memory addresses, like in the following examples:
    Memory address Matches
    [CONST] Any fixed memory location, like [400000] [R32] Memory locations with address residing in register, like [ESI] [R32+1000] Sum of any 32-bit register and constant 1000, like [EBP+1000] [R32+CONST] Sum of any 32-bit register and any offset, like [EAX-4] or [EBP+8] [ANY] Any memory operand, like [ESI] or [FS:EAX*8+ESI+1234]
    If you are searching for the sequence of commands, it's important to emphasize the interaction of the commands in a sequence. Suppose that you are looking for all comparisons of two memory operands. 80x86 has no such instruction (except CMPS, but it's slow and requires lengthy preparations). Therefore compiler will generate the following code:
    MOV EAX,[location 1] CMP EAX,[location 2]
    However, it is possible that compiler will choose ECX instead of EAX, or any other register. To take into account all such cases, OllyDbg has special depending registers:
    Register Meaning
    RA, RB All instances of 32-bit register RA in the command or sequence must reference the same register; the same for RB; but RA and RB must be different R8A, R8B Same as above, but R8A and R8B are 8-bit registers R16A, R16B Same as above, but R16A and R16B are 16-bit registers R32A, R32B Same as RA, RB
    For example, search for XOR RA,RA will find all commands that use XOR to zero 32-bit register, whereas XOR RA,RB will exclude such cases. Correct sequence for the mentioned example is
    There are also several imprecise commands:
    Command Matches
    JCC Any conditional jump (JB, JNE, JAE...) SETCC Any conditional set byte command (SETB, SETNE...) CMOVCC Any conditional move command (CMOVB, CMOVNE...) FCMOVCC Any conditional floating-point move (FCMOVB, FCMOVE...)
    Pattern Found commands
    Note that in the last line, [DWORD ESI-30] is equivalent to [DWORD ESI+0FFFFFFD0].


    Binary edit
    You have many ways in which you can edit code and data. The simplest is the binary edit, where you can edit your precious bytes as ASCII text, UNICODE text or directly in hexadecimal format. Select the piece of code or data and choose Edit | Binary edit from the pop-up menu:
    Data and modifications are displayed simultaneously in all supported formats. Note that default UNICODE font is Courier, which in most cases does not contain Far East characters. If you need them, please define new font (Options | Fonts) and select it as a UNICODE edit font in Options | Appearance.
    Small button on the left toggles between insert (INS) and overwrite (OVR) modes. Be careful, hexadecimal editor in insert mode shifts data in 4-bit nibbles!
    If Keep size is unchecked and you type more data than you have selected, or size of the data is increased because you have inserted some bytes, OllyDbg will update data beyond the selection. To prevent this, check Keep size.
    Maximal edit size is limited to 1024 bytes. To move from one control to another, use shortcuts Ctrl+UpArrow and Ctrl+DnArrow.


    Assembler is similar to the binary edit, and works both on code and data:
    Select block of data you want to modify and call assembler. It will show the first selected command. Edit this command, or type new, and press Assemble (or Enter key). If command is invalid, dialog will display an error. Otherwise, command will be written to the memory and selection updated.
    If new command does not fit into the integer number of the original commands and Fill rest with NOPs is checked, remaining bytes will be filled with code 0x90 (NOP). This is the preferrable way. If option is unchecked, residual bytes of the previous command remain unchanged.
    Assembler always attempts to select the shortest binary form. It automatically removes analysis from the modified code.

    Binary copy and paste

    Binary copy copies selection to the clipboard as a hexadecimal text. For example, operation on the selection:
    results in
    B8 01 00 00 00 BA 00 00 00 00 B9 00 00 00 00 F7 F1 C3
    Binary paste is strictly limited to selection. If selection is longer, remaining bytes are not modified. Note that paste ignores all characters that are not hexadecimal digits. This is what will happen if you attempt to paste the phrase "HEXADECIMAL CODE":
    OllyDbg automatically creates backup of the modified memory blocks. If you want to undo modifications, select it and press Alt+Backspace, or choose Edit | Undo selection from the menu.

    How to save modifications to executable file

    If your modification works, you need to transfer it from the memory back to the executable file. Select modified code or data and choose Edit | Copy to executable. OllyDbg creates copy of executable file and applies modification. It even corrects fixups. If fixups are not stripped, try to change code so that fixups remain on the proper locations within the new commands, otherwise modified code may fail if OS loads it to different memory location!
    If menu item Copy to executable is not available, this means that memory does not map to the executable. Windows usually align sections of the executable file on 4096-byte borders. If code section is shorter than n*4096 bytes, remaining bytes in the memory will be filled with zeros, but they have no counterpart in the executable file. Uninitialized data section are also not part of the executable.
    When all modifications are transferred, go to the dump of the executable file and choose Save file... from the pop-up menu. You will be asked to select file name. As old file is open by the Debuggee, you must select different name
    One Mod is good
    one Hack is better
    but Mods and Hacks
    forever are the best!

    You only live once
    so make the best of your life
    and be an ElementEvil VIP!

    Hidden Content

    Reply With Quote   ODB Hex Editor Send PM  

  5. #4  
    Junior Member
    Join Date
    Jan 2015
    Thanked 0 Times in 0 Posts
    0 Post(s)
    0 Thread(s)
    I don't know. Do you help by picture???
    Reply With Quote   ODB Hex Editor Send PM  

Similar Threads

  1. Memory editor tools is useless for Summoners War
    By iandrohacker in forum Trash Can
    Replies: 16
    Last Post: 05-04-2015, 03:26 AM
  2. hex editor / mod
    By find_beat in forum Forum Ideas / Questions / Bug Reports
    Replies: 2
    Last Post: 02-26-2015, 05:43 PM
  3. Replies: 1
    Last Post: 02-16-2015, 10:01 PM
Posting Permissions
  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts