jump to navigation

OllyDbg 2.00.01 (Final) July 26, 2010

Posted by reversengineering in DEBUGGER, TOOLS.
add a comment

OllyDbg 2.0 is a 32-bit assembler-level analyzing Degugger with intuitive interface. It is especially useful if source code is not available or when you experience problems with your compiler.

Requirements. Developed and tested mainly under Windows 2000 and Windows XP, but should work under any Windows version: 95, 98, ME, NT, 2000, XP, 2003 Server, Vista, Windows 7 and so on. For a comfortable debugging you will need at least 500-MHz processor. OllyDbg is memory hungry. If you debug large application with all features enabled, it may allocate 200-300 megabytes for backup and analysis data.

Supported instruction sets. OllyDbg 2.0 supports all existing 80×86-compatible CPUs: MMX, 3DNow!, including Athlon extentions, and SSE instructions up to SSSE3 and SSE4.

Configurability. More than 120 options (oh, no! This time it’s definitely too much!) control OllyDbg’s behaviour and appearance.

Data formats. Dump windows display data in all common formats: hexadecimal, ASCII, UNICODE, 16 and 32-bit signed/unsigned/hexadecimal integers, 32/64/80-bit floats, addresses, disassembly (MASM, IDEAL, HLA or AT&T). It also decodes and comments many Windows-specific structures, including PE headers, PEB, Thread data blocks and so on.

Help. OllyDbg 2.0 includes built-in help on all 80×86 integer and floating-point commands. If you possess Windows API help (win32.hlp, not included due to copyright reasons), you can attach it and get instant help on system API calls.

Startup. You can specify executable file in command line, select it from menu, drag-and-drop file to OllyDbg, restart last debugged program or attach to already running application. OllyDbg supports just-in-time debugging and debugging of child processes. You can detach from the debugged process, and it will continue execution. Installation is not necessary!

Code highlighting. Disassembler can highlight different types of commands (jumps, conditional jumps, pushes and pops, calls, returns, privileged and invalid) and different operands (general, FPU/SSE or segment/system registers, memory operands on stack or in other memory, constants). You can create custom highlighting schemes.

Threads. OllyDbg can debug multithread applications. You can switch from one thread to another, suspend, resume and kill threads or change their priorities. Threads window displays errors for each thread (as returned by call to GetLastError).

Analysis. Analyzer is one of the most significant parts of OllyDbg. It recognizes procedures, loops, switches, tables, constants and strings embedded in code, tricky constructs, calls to API functions, number of function’s arguments, import sections and so on. It attempts to determine not only the number of stack arguments in the unknown functions, but even their meaning. Analysis makes binary code much more readable, facilitates debugging and reduces probability of misinterpretations and crashes. It is not compiler-oriented and works equally good with any PE program.

Full UNICODE support. All operations available for ASCII strings are also available for UNICODE, and vice versa. OllyDbg is able to recognize UTF-8 strings.

Names. OllyDbg knows symbolic names of many (currently 7700) constants, like window messages, error codes or bit fields, and decodes them in calls to known functions.

Known functions. OllyDbg recognizes by name more than 2200 frequently used Windows API functions and decodes their arguments. You can add your own descriptions. You may set logging breakpoint on a known or guessed function and protocol arguments to the log.

Calls. OllyDbg can backtrace nested calls on the stack even when debugging information is unavailable and procedures use non-standard prologs and epilogs.

Stack. In the Stack window, OllyDbg uses heuristics to recognize return addresses and stack frames. Notice however that they can be remnants from the previous calls. If program is paused on the known function, stack window decodes arguments of known and guessed functions. Stack also traces and displays the chain of SE handlers.

Search. Plenty of possibilities! Search for command (exact or imprecise) or sequence of commands, for constant, binary or text string (not necessarily contiguous), for all commands that reference address, constant or address range, for all jumps to selected location, for all referenced text strings, for all intermodular calls, for masked binary sequence in the whole allocated memory and so on. If multiple locations are found, you can quickly navigate between them.

Breakpoints. OllyDbg supports all common kinds of breakpoints: INT3, memory and hardware. You may specify number of passes and set conditions for pause. Breakpoints may conditionally protocol data to the log. Number of INT3 and memory breakpoints is unlimited: in the extreme case of hit trace, OllyDbg sometimes sets more than 100000 INT3 breakpoints. On a fast CPU, OllyDbg can process up to 20-30 thousand breakpoints per second.

Watches. Watch is an expression evaluated each time the program pauses. You can use registers, constants, address expressions, boolean and algebraical operations of any complexity.

Execution. You can execute program step-by-step, either entering subroutines or executing them at once. You can run program till next return, to the specified location, or backtrace it from the deeply nested system API call back to the user code. When application runs, you keep full control over it. For example, you can view memory, set breakpoints and even modify code “on-the-fly”. At any time, you can pause or restart the debugged program.

Hit trace. Hit trace shows which commands or procedures were executed so far, allowing you to test all branches of your code. Hit trace starts from the actual location and sets INT3 breakpoints on all branches that were not traced so far. The breakpoints are removed when command is reached (hit).

Run trace. Run trace executes program in the step-by-step mode and protocols execution to the large circular buffer. Run trace is fast: when fast command emulation is enabled, OllyDbg traces up to 1 million commands per second! Run trace protocols registers (except for SSE), flags, contents of accessed memory, thread errors and – for the case that your code is self-modifying – the original commands. You may specify the condition to stop run trace, like address range, expression or command. You can save run trace to the file and compare two independent runs. Run trace allows to backtrack and analyse history of execution in details, millions and millions of commands.

Profiling. Profiler calculates how many times some instruction is listed in the run trace buffer. With profiler, you know which part of the code takes most of execution time.

Patching. Built-in assembler automatically selects the shortest possible code. Binary editor shows data simultaneously in ASCII, UNICODE and hexadecimal form. Old good copy-and-paste is also available. Automatical backup allows to undo changes. You can copy modifications directly to executable file, OllyDbg will even adjust fixups.

UDD. OllyDbg saves all program and module-related information to the individual file and restores it when module is reloaded. This information includes labels, comments, breakpoints, watches, analysis data, conditions and so on.

Customization. You can specify custom fonts, colour and highlighting schemes.

And much more! This list is far from complete, there are many features that make OllyDbg 2.0 the friendly debugger.

Author website http://www.ollydbg.de/

new olly moded October 14, 2009

Posted by reversengineering in DEBUGGER, TOOLS.
add a comment


odbg110 moded by Sabre-Gold October 14, 2009

Posted by reversengineering in DEBUGGER, TOOLS.
add a comment


OllyICE v1.10 October 14, 2009

Posted by reversengineering in DEBUGGER, TOOLS.
add a comment

new olly modified


OllyDbg 2.0 beta October 14, 2009

Posted by reversengineering in DEBUGGER, TOOLS.
add a comment

The second beta. I’ve planned that it will come with the more or less complete help file. Unfortunately, I had no time to write it. Therefore there will be also the third beta release… soon.
There are many – over 20 – bugfixes in the beta 2, some of them are really critical. As promised, there are no significant changes, with two exceptions. The recognition of UNICODE strings is vastly improved, they are no longer limited to ASCII subset (option “Use IsTextUnicode()”. Also I recognize strings in the UTF-8 format. By the way, if you have some small sample program with the free source that uses UTF-8 strings, please send it to me (together with the screenshot of displayed strings) so that I will be able to test OllyDbg.
The second new feature is in the run trace. New option “Pause when EIP points to modified command” helps, for example, to find the real entry point of the SFX-ed code. Just don’t forget to create backup first (or use another new option, Auto backup user code)!



new olly moded October 14, 2009

Posted by reversengineering in DEBUGGER, TOOLS.
add a comment

new olly modified by ygs


IceStealth February 26, 2009

Posted by reversengineering in DEBUGGER, OTHER, TOOLS.
1 comment so far

Last updated: Feb 25, 2009

Author: Daniel Steinhäußer

IceStealth is a SoftICE hiding tool, that should protect from:

CreateFileA, CreateFileW, NtCreateFile, also nmtrans.dll wont find SoftICE with these methods
OpenServiceA, OpenServiceW, EnumServicesStatusA,EnumServicesStatusW,EnumServicesStatusExA, EnumServicesStatusExW
UnhandledExceptionFilter (2 Options)
SEH BPM protect
int 41 killed + DPL 0
int 1 DPL 0
Basic Registry Protection (if ever needed)

OllyDRX 1.10 Ultimate February 11, 2009

Posted by reversengineering in DEBUGGER, TOOLS.

OllyDbg 1.10:
+ New look
+ Modified code for almost perfect hiding
+ Win32 API help reference
+ Modified code for expanded windows
+ Modified code for %s overflow RCE exploit
+ Modified code to make symbols load properly
+ ON2O Plugin Patcher
+ Plugin Development Kit & Script Editor v2.0

DUP2.18.3, uPPP 0.5, LordPE Deluxe b, PEiD 0.95 + database, Resource Hacker, .NET Reflector, DeDe 3.50.04 Build 1635, Universal Extractor 1.6, VB Decompiler Lite 7.0, Import Reconstructor 1.7c + 1.6 final, PE Tools 1.5 RC7, VeoVeo 3.4, HxD, W32Dasm 8.93 fixed, SND Reverser Tool 1.4, Wark 1.3, Numega Smartcheck 6.20 RC2 Build 1286, Hiew 7.26, RDG Packer Detector v0.6.6 2k8, 32bit Calculator 1.7, ProtectionID 6.1.6, ASCII Converter, TMG Ripper Studio 0.03, FPU Calculator 1.0, Table Extractor 1.34, Cheat Engine 5.5, CrypTool 1.4.21

+BP-OLLY Ver 2.0 beta 4, Olly Advanced 1.26 beta 12, AnalyzeThis! v0.1, Bookmark v1.06, CommandBar 3.20.110, ODbgScript v1.66.3, OllyDump v3.00.110, Olly TBar Manager (Gold), Olly More Menu 1.3b, DataRipper 1.3, CleanupEx 1.12.108, PhantOm 1.54, IDAFicator 1.2.12

647 Scripts

Stripper 2.11 RC2, Armageddon 1.5, Unpacker Execryptor 1.0 RC2, UnThemida 2.0, ASPackDie 1.41, UnPECompact 2, UnSafeDisc 4.60, AMDecryptor 1.1, AMDump62 2.2, UPX 3.0.3W

Sysinternals Suite, OllyDbg Plugin Collection (148 Plugins)


Mb 126

i dont upload this so  be careful about virus or…

best regards

req. link December 9, 2008

Posted by reversengineering in DEBUGGER, Request, TOOLS.
add a comment


ImmunityDebugger 1.73 RemoveAD KuNgBiM November 19, 2008

Posted by reversengineering in DEBUGGER, TOOLS.
add a comment


1.70 Build 0

New Features:

- Debugger
o Added support for variable decoding when second pass analysis enabled

- Immunity Debugger API
o Added getVariable/setVariable methods
o Added driverlib.py for analyzing drivers

- PyCommands
o activex.py for auditing ActiveX controls

- Bug Fixes
o Fixed Python pathing issue when JIT debugging/spawning from right-click
o Fixed Module.getName() method to return only the module name
o Fixed length check error in imm.Assemble()

1.60 Build 0

New Features:

- Debugger
o Added ‘Use Symbol Server’ option
o Improved Getallnames
o Added timestamp to log events

- Immunity Debugger API
o Added getAllSymbolsFromModule method
o Added libcontrolflow.py
Container for classes DominatorTree and ControlFlowAnalysis
o Added Clear function to FastLogHook.

- PyCommands
o Added findloop.py: Find natural loops given a function start.
o Added treedll.py: Creates imported dll tree.

- Bug Fixes:
o Fixed Arguments overflow (Thanks David Wetson for reporting this one!)
o Local Symbol Path issue
o Analysis second pass option now works
o Getallsymbols now correctly creates the PyDict [Import/Export/Library issue]

1.50 Build 0

New Features:

- Debugger:
o Added “Servers” folder with specific pycommand listeners

- Memory Pages:
o Working on Windows Vista

Immunity Debugger API:
o Added imm.vmQuery() wrapper [Query Virtual Memory pages]
o The MemoryPage class has been improved.
- Protect and Allocation Protect Flags are queried realtime
- You can get a human readable flag passing human = 1 to
page.getAccess() and page.getInitAccess()
o Added:
- searchOnExecute()
- searchOnRead()
- searchOnWrite()
These methods will search in any memory page with access = any combination.
o Modified:
- Search()
- searchShort()
- searchLong()
to receive an extra flag parameter to specify memory protection type
when searching.
o Added imm.isAdmin() : is ID running as admin?
o Added Thread class to debugtypes.py
o Added imm.getAllThreads() method
o librecognition.py : Improved REGEXP support for the indexed register search
o Added Function.findRetValue Find all the possible values on a Function
o GFlags class Handle Windows Global Flags.


o gflags.py: Enable/Disable Windows Global Flags
o recognize.py: Backward compatability
o Added hookssl.py
o Added ssl_listener.py to Servers directory
o Added hookndr.py Hooks the NDR unmarshalling routines and prints them
out so you can see which ones worked
o Added nohooks.py : remove all hooks from memory

Bug Fixes:

- Debugger Core
o The memory page protect information is correctly displayed now.
o Fixed Second Analisys pass repeated entries bug.
o Fixed thread state swap issue which was leading to a memleak.

1.40 Build 0

New Features:

- Debugger Core:
o Added Silent Debugging Flag [accesible via Debugging options ALT-O or via immlib]


o Added Analysis Second Pass [Decoding Functions]


- Debugger GUI Core:
o Now you can add headers + other useful information on every Row
displayed at the Disasm Window. The information will be saved
as part of dump struct.
o Dettach option added to File Menu: Go to File -> Dettach [You need to be attached to
gray out Dettach]


- Debugger GUI:
o Right click on disasm line -> Add Header will add headers to your line

- Immunity Debugger API:
o Row Headers / Adding Lines to CPU
- Added imm.addHeader() and imm.getHeader() methods.
- imm.addLine behaves like addHeader()
- Added imm.removeHeader()/imm.removeLine() && imm.getHeader()/imm.getLine()
- Added imm.getTraceArgs()

o Added imm.goSilent() method.
o Added imm.undecorateName() method: Undecorate symbol names


o Added imm.Dettach() method: Dettach current process from debugger
o Added imm.prepareForNewProcess() method: Prepare Debugger core for a fresh start
o Updated BoB’s UserDB.txt (http://peid.info/BobSoft/Downloads.html)

- PyCommands:
o Added namefunc.py : a simple samplescript that uses imm.addHeader to name
functions in module
o Added traceargs.py: find User supplied arguments into a given function.
o Added JMS’s Mike & Boo script
o User Contributed PyCommands:
- BoB (http://PEiD.info/BobSoft/)
* scanpe.py (http://forum.immunityinc.com/index.php?topic=137.0)
* hidedebug.py (http://forum.immunityinc.com/index.php?topic=140.0)
* bpxep.py (http://forum.immunityinc.com/index.php?topic=138.0)

Bug Fixes:

- Fixed error when adding knowledge and changing python enviroments later.
(__dict__ not accesible in restricted mode error)

1.30 Build 0
November 1, 2007

New Features:

- Immunity Debugger API
o Hooks
- Hooks can receive force flag to overwrite previously placed hooks
- Hooks can receive time to live in memory parameter when adding
(After the TTL expires, the hook is automatically removed from memory)
- Hooks has a runTimeout method to execute code after TTL expires
o Choose thread enviroment to execute the ttl code
- Added special kind of AccessViolation hook: RunUntilAV() class
o Added setHardwareBreakpoint method
o Address deleteBreakpoint method
o Process flow:
o Improved methods:
- stepOver
- stepIn
- Run
- Attach
o Added methods:
- openProcess
- restartProcess
- pause
- runTillReturn

- PyCommands
o search allows multiple line searching: !search add esp,const\nret
o Added sql_listener and sqlhooker
o Added Example processflow script

Bug Fixes:

- Fixed imm.ps() to correctly fetch udp port list


- Fixed Get references methods

1.20 Build 0
October 1, 2007

New Features:

- Immunity Debugger API
o immlib.getThreadId() method added: return the current debuggee thread id
o immlib.getCallTree() method added: return the call tree for given address
o immlib.setFocus() method added: focus ID window
o immlib.isValidHandle() method added: check if a HWND is still valid
o immlib.getInfoPanel() method added: get information from panel window
and optionally receives a type flag to force the kind of comment fetched.
o imm.findPacker() method added: find packers/cryptors on a file or a loaded
o imm.getMemoryPagebyOwner(): Find all the memory pages belonging to a module.
o immlib.ps() returns two extra objects: the tcp list and the udp list
o immlib.getComment() now will try to fetch all types of comments
o Added new HOOKTYPE: PRE_BP_HOOK, hooks exactly before the breakpoint is hit
(Decoding events timeline)
o New Vista support for libheap
o Custom Tables has “Clear Window” menu now
o Added several methods from librecognize

- PyCommands
o findpacker added. (Use of immlib.findPacker to get Packers from a module)
o recognize added. (Function Recognizing using heuristic patterns)
o Hippie now can filter by heap
o heap updated to work with new Vista Heap
o Optimized code for stackvars (Memory usage reduction during runtime)

- Core
o Pyshell can be focused once created with alt-F11
o Shortcut for attach process added: Ctrl+F1
o Added librecognition.py (Library for function recognizing)

- Graph
o immvcglib.generateGraphFromBuf() method added: play with your own vcg files!
o Redesign of VCG parser: easier to read, easier to use.

Bug Fixes:

o Return value (HWND) of createTable
o Fixed Attach Search Filtering :


o Grapher: Vertex lastline jumps correctly displayed now
o Fixed crash when searching on modules:


o Fixed search issue on protected binary:


o Fixed breakpoint/logpoint hooks issue (logic/stepping inside a hook)
o Fixed PyString_AsString() missbehaviour
o Fixed PyCommand Gui Arguments box to receive \x00 as argument
o Fixed imm.getModulebyAddress() to receive any module address and not only module entry point


1.1 Build 2
August 31, 2007

Python Thread entering the spiral zone has been fixed

1.1 Build 0
August 30, 2007

New Features:

o Interactive Python Shell added
o Lookaside enhanced output + Discovery option
o libdatatype “Get” Function
o Get OS information methods
o Ero Carrera’s pefile.py (http://code.google.com/p/pefile/)
o Python engine rewritten to properly use thread locking/unlocking
o Added ignoreSingleStep method for immlib (TRANSPARENT + CONVETIONAL)
o Attach process window is now dinamically searchable
o Added clean ID memory methods inside immlib
o Added Stack analize library (libstackanalize)
o Fixed some memleak on Disasm
o Fixed wrong arguments on Disasm operand
o Improved Patch command
o Safeseh moved into a PyCommand

New Scripts:

o searchcrypt PyCommand
o stackvars PyCommand
o search PyCommand

Bug Fixes:

o Solved ‘ij’ issue inside attach window
o Fixed VCG parser (Blocks display fully address now)
o Fixed traceback error when trying to graph and no attached
o Fixed printfloat() format error
o Fixed ret value of Getaddrfromexp in case of non-existand expression

1.0 Build 42
August 1, 2007

o Released as product
o Includes:
o Full Python API:
- immlib (main lib)
- internals
- immutils
- debugtypes
- libdatatype
- libanalize
- libhook
- libevent
- pelib
- immvcglib
- graphclass

o Command Box (with remote listener + command line client)
o Python Orthogonal Drawing
o Examples for PyCommands/PyHooks/PyScripts
o Ready to use PyCommands/PyHooks:

chunkanalizehook Analize a Specific Chunk at a specific moment
cmpmem Compare memory with a file (file been a dump from prettyhexprint)
dependencies Find a exported function on the loaded dll
duality Looks for mapped address that can be ‘transformed’ into opcodes
findantidep Find address to bypass software DEP
finddatatype funsniff
funsniff funsniff
getevent Get a log of current debugevent
getrpc Get the RPC information of a loaded dll
heap Immunity Heap Dump
hippie Syscall Fuzzer
hookheap – DESC is not defined for this command -
list List PyCommands
lookaside – DESC is not defined for this command -
mark Static Analysis: Mark the tiny ones
modptr !modptr Patch all Function Pointers and detect when they triggered
openfile Open a File
patch Patches anti-debugging protection , [-t TYPE_OF_PROTECTION]
pyexec Non interactive python shell [immlib already imported]
searchcode Search code in memory
searchheap Search the heap for specific chunks
safeseh Show exceptions handlers registered with SEH
pe_export Export Module

o Lib references and Documentation



ollydbg moded by DeRoX November 19, 2008

Posted by reversengineering in DEBUGGER, TOOLS.
1 comment so far

OllyDRX 1.0 Lite
Author DeRoX

+ New look
+ Modified code for almost perfect hiding
+ Modified code for expanded windows
+ Modified code for %s overflow RCE exploit
+ Modified code to make symbols load properly
+ OllyDRX Plugin Patcher


diablo2oo2′ OllyDbg updated October 29, 2008

Posted by reversengineering in DEBUGGER, TOOLS.
1 comment so far

diablo2oo2 :And last i also updated my custom ollydbg package.



Syser Debugger 1.99.1900.1095 October 29, 2008

Posted by reversengineering in DEBUGGER, TOOLS.

Syser Debugger is designed for Windows NT Family based on X86 platform. It is a core-level debugger with full-graphical interfaces and supports assembly debugging and source code debugging. Syser Debugger is able to debug Windows applications and Windows drivers. Don’t leech from kopona.netSyser Debugger perfectly combines the functions of IDA Pro, Softice and Ollydbg, which makes operations easier and faster and provides powerful functions. It supports multi-CPU and Intel Hyper-Threaded processors.

- Supports color disassembly.
- Source code debugging supports syntax coloring.
- Source code debugging supports collapsing mapping between source code and assembly instructions.
- Supports dynamic loading and unloading.
- entire keyboards operations support. (If is doing not have mouse equipment situation all operations all to be allowed to use keyboard to operate)
- Full mouse action support (if no keyboard is available, all operations can be performed through mouse commands).
- Commands are Softice-compatible
- Multi-language support, fully implemented unicode at low level.
- Supports plug-ins.
- Supports multi-CPU and Intel Hyper-Threaded processors.
- Supports startup scripts (similar to batch files).
- Supports clipboard function, able to copy data from Ring 3 debugger to Ring 0 debugger.
- Fully supports PDB debugging symbol files.
- Automatically load drivers to debug.
- Supports comments adding when debugging.
- Supports bookmark function.
- Don’t leech from kopona.net.
- Address navigation is supported in disassembly windows and users can browse different functions quickly by double-clicking.
- Source code debugging supports quick view of variables and users can view variable types and values by moving cursor over variable names.
- Syser is the perfect combination of IDA and Softice functions.
- Supports address cross-reference lists.
- Supports data reference lists.
- Supports the advanced processing modes of pointing devices, such as TouchPad, TrackPoint.
- Supports multiple data windows.
- Supports multiple code windows to facilitate the browsing of assembly code.
- Supports run trace mode for ollydbg.

Основные возможности:
• подсветка листинга дизассеблера
• динамическая загрузка и выгрузка
• поддержка работы с клавиатурой и мышью
• поддержка всех команд отладчика Softice
• поддержка юникода, многоязычный интерфейс
• поддержка плагинов
• поддержка многопроцессорных систем с Intel Hyper-Threaded процессоров
• поддержка скриптов
• поддержка буфера обмена, позволяющего копировать данные из уровня Ring 3 в уровень Ring 0
• корректная совместная работа с Softice
• автоматическая загрузка драйверов для отладки
• добавление комментариев в отладку
• закладки
• поддержка cross-reference и data reference
• многооконный интерфейс
• и многое другое

2008.10.01 Syser Debugger 1.99.1900.1083
1. Add thread command.
2. Add hwnd command.
3. Add objtab command.
4. Add bmsg command.
5. Add bmsg command.
6. Add TID public symbol in syser,support breakpoint in one thread . example: bpx CreateFileA if TID==54c
7. Fixed a BOSD bug on window 2000 in SDbgMsg.sys.
8. Fixed a BOSD bug in syser.sys.
Windows 2000/XP/2003/Vista



OllyDBG v1.10 plugin – StrongOD v0.18 [2008.09.18] September 19, 2008

Posted by reversengineering in DEBUGGER, OLLY'S PLUGINS, TOOLS.

[2008.09.18 v0.18]
1, to repair the Ctrl G calculation rva, offset when a small BUG
2, when the program is not running the state, Detach before running program
3, restoration of the original data OD zone copy BUG
4, repair od after the CPU running very high occupancy rate BUG
5, you can set it to skip some of the exception handling

[2008.09.02 v0.17]
1, to skip some of the improper handling of the abnormal OD
2, correctly handle the instructions int 2d

[2008.08.31 v0.16]
1, joined the drive to protect the process, the hidden window, over most of the anti-debugging
2, driver support for the custom equipment 000 (ollydbg.ini of DeviceName, equipment were not more than 8 characters)
ollydbg.ini of [StrongOD], you can set up their own
HideWindow = 1 to hide the window
HideProcess = 1 to hide the process
ProtectProcess = 1 protection process
DriverKey =- 82693034 and the key driver of communication
DriverName = fengyue0 who drives (not more than 8 characters)

3, OD will be the creation of the parent process into the process explorer.exe (copied from shoooo code)

The increase in the version of the driver, if a blue screen, set up minidump spread to the Forum, thank you
OllyDbg original use as much as possible, and other generally do not need the anti-anti plugin in conjunction with plug-in (including phant0m)



Immunity Debugger v1.73 September 17, 2008

Posted by reversengineering in DEBUGGER, Immunity Debugger, TOOLS.


We have put out the 1.73 release which is a maintenance release that has a few more bugfixes as well as a DLL injection function in the debugger API.

The list of changes are as follows:

- Immunity Debugger API
- Added inject_dll() method to load a DLL into the debuggee

- Bug Fixes
- Fixed pathing issue when updater.exe spawns debugger
- Fixed MemoryPage.getOwner() to return only the module name
- Fixed hang when opening Immlib-> Lib References menu item

You can upgrade your current Immunity Debugger by going to Help/Update
or directly downloading the new installer from


Thanks for using Immunity Debugger, and all your patience while we resolved these last few issues.

Team Immunity


PEBrowse Professional Interactive 8.10.2 September 15, 2008

Posted by reversengineering in DEBUGGER, TOOLS.
add a comment

It is a nice debugger if you want to use an alternative to OllyDbg. I don’t see many topics or posts on the subject but it is worth taking a look at.

Changes since V 8.10.2
- Added restricted operations setting to startup log.
- Fixed “missing” memory dump entries at frame boundaries in stack display.
- Added horizontal scrolling in attach to process dialogbox.
- Removed extra breakpoints perserved in session file after terminating a process – created by runto mode.
- Added debug menu item to create a breakpoint when a specific DLL is initialized.
- Restored commandline, startup directory, and additional environment variables persistence in session file.
- Always display suppressed exceptions in debug log.
- Fixed bug when newly-minted session files were not added to most recent list.
- Suppressing statusbar hints when debugger is not stopped.
- Added support for tracking user-specified values in the registers and memory displays.


Zeta Debugger v1.5 September 11, 2008

Posted by reversengineering in DEBUGGER, TOOLS.
add a comment
Zeta Debugger v1.5

Fixed bug: sometimes couldn’t run on Window 98.

Next version

The other thing that we plan to add in the nearest future is the checkpoint monitor. Imagine that you can set a check point at any address of code and then evaluate numeric expressoins valid for this address, and put all these results into a graph. That’s we are talking about. Also maybe we unite this monitor with the animation panel in some elegant way that simplifies the use of both.

There are also many other things we should add or fix. But we promise you that they will not complicate the interface in any degree. We will try to make the debugger’s system as automatic and intelligent as only possible. Keep watching for the new versions and you will know the other details.


ollydbg mod. 4 Execryptor & THEMIDA September 7, 2008

Posted by reversengineering in DEBUGGER, TOOLS.

ollydbg moded for Execryptor & THEMIDA
Modified  Execryptor
Modified THEMIDA
Add the possibility of deleting all points of stopping Remove all breakpoints
auto path UDD & plugin
Reference Search directly from the toolbar
Show offset in status bar
Amendment to show the number of additions to the list
Additions located

1 – advancedolly.dll
2 – analyzethis.dll
3 – API_Break.dll
4 – bookmarks2.dll
5 – cmdbar.dll
6 – HideOD.dll
7 – NonaWrite.dll
8 – ODbgScript.dll
9 – OllyBugfix.dll
10 – OllyDump.dll
11 – OllyMoreMenu.dll
12 – PhantOm.dll
13 – Poison.dll
14 – ustrref.dll

This amendment took me time so there is no difference between them and the original
They accept each others additions modified
Do not forget pray for me and my family

by phpbb3


OllyDBG The Best version September 4, 2008

Posted by reversengineering in DEBUGGER, TOOLS.

in this oly u can find all scripts and plugins u need ,plus more ( skins ,etc..)




MHS v5.002- Debug, Disassemble, Hex Edit, Search, Inject Code/DLLs, Etc. September 4, 2008

Posted by reversengineering in DEBUGGER, OTHER, TOOLS.
add a comment

MHS is a utility for searching, viewing, and modifying the RAM of other processes, and for disassembling and debugging other processes.
MHS sports the fastest and most efficient searches available, an advanced, colorful, and easy-to-use real-time Hex Editor, a Debugger with unique features, a Disassembler, and an extensive scripting language (L. Spiro Script) yielding unlimited potential.
The array of tools offered in MHS can make hacking any game easy.
Here is a compact list of tools and features:

  • Searching
    • Data-Type Searches
      • Fastest searches available.
      • Search for types char, byte, short, unsigned short, int, long, unsigned long, 64-bit integer, float, and double.
      • Search for exact values, values not equal to, ranges, greater than, less than, and unknown.
    • Group Searches
      • Find unordered sets of data.
      • Find relative lists of data.
    • String Searches
      • Find hex strings, ASCII strings, Unicode strings, Wildcard strings, and Regular-Expression strings.
      • Boyer Moore Algorithm for fast searching.
    • Pointer Searches
      • Fastest search possible.
      • Quickly find both static and dynamic pointers.
    • Script Searches
      • The most powerful searches possible.
      • You have full control over what values are found during a search.
      • Able to replicate all search types available in all software, now and forever.
    • All addresses shown after a search and without delay; no need to view “only the first 100” returns.
  • Converter
    • Convert from any type to any other type, both big and little endian.
  • RAM Watcher
    • View the RAM of the target process in real-time.
    • Multiple display types shown simultaneously.
  • Real-Time Expression Evaluator
    • Evaluates even the most complex of expressions.
    • Shows expression results in real-time; especially useful for following changing pointer locations or changing expressions.
  • Hex Editor
    • Edit files and RAM.
    • Files open instantly, regardless of size, and RAM is shown in real-time.
    • Multiple display types show you RAM and files in characters, bytes, shorts, ints, floats, doubles, and more.
    • Full undo/redo.
    • Many options and full customization.
  • Debugger
    • Breakpoint functionality can be assigned by the user, and breakpoints can call user-defined script functions for the ultimate do-what-you-want.
    • Hardware breakpoints.
    • Read/write software breakpoints (watchpoints).
    • The Debugger issues debugging events that can be handled by scripts, allowing the user to perform any and all operations he or she desires at key times during debugging.
  • Disassembler
    • Shows names of known functions.
    • Logging (to be finished).
    • Addresses of all imported/exported functions shown.
    • Auto-Hack shows you every read, write, or access to an address, and extremely advanced features will be coming soon (automatic back-tracking down to the root pointer).
    • Exlanations of ASM instructions are provided in real-time, explaining what each instruction is going to do and offering previews of the results.
    • Process threads are updated in real-time and useful information about them is displayed.
  • Injection Manager
    • Complete and feature-rich injection suite.
    • Code caves can be found automatically, defined by the user, or created.
    • Code preview shows you the code before injecting.
    • Automatically adds the JMP back to the original code and adds the overwritten code to the code cave.
    • Injections are automatically saved, and options allow to inject automatically when the process is reloaded later.
    • Automatic injections are always safe; injections are verified before being automatically injected.
  • Script Editor
    • Syntax coloring.
    • Code folding.
    • Functions listed and easily navigated.
  • Hotkeys
    • Many assignable keys and functions.
    • Two hotkey implementations in case the game blocks one or the other.
  • Stability
    • MHS is extremely stable. Currently there are no known issues.

But the biggest feature in MHS is that it is constantly updated.

Syser Debugger 1.98 Released August 31, 2008

Posted by reversengineering in DEBUGGER, NEWS, TOOLS.
add a comment

2008.8.24 Syser Debugger 1.98 Release

1. Fixed s command bug.
2. Fixed a BOSD bug on Vista (Bug Check 0×1: APC_INDEX_MISMATCH)
3. Add string reference windows of PE .
4. Enhanced mod command, display TimeDateStamp of PE module .
5. Fixed a BOSD bug of device,driver command.

odbg110 Inrev edition August 27, 2008

Posted by reversengineering in DEBUGGER, TOOLS.
1 comment so far

hi my freinds

odbg110 Inrev edition   modfied by INREv team .i dwonload this and test it these ollys its very simple and not modified for anti anti debug tricks like class name ,caption,filename etc.

so  i hope the new edition  of this will  work for defeating  OllyDbg’s detection from good protector!!!!


info from them:


Nothing special in this version of ollydbg, just adding some
plugin for anti-anti debug and optimized setting for better
cracking experience. If you are an advance reverser, theres
no need to try this one, I’m sure you can do that by yourself,
but on the other hand this edition might be very
usefull, especially for newbies.

Future plan:
- Adding more anti-anti debug trick
- Fixing some invalid setting or optimized current setting

Tested on:
- Themida (RDG scan)
- Exe protector v2.1.15 (RDG scan)
- Other protector which use standard anti debug trick

and beta2

scripted added

more plugin

new skin



ollydbg 2 pre alpha H August 23, 2008

Posted by reversengineering in DEBUGGER, TOOLS.
1 comment so far

Big update. Powerful run trace, profiling, analysis, many small improvements and multiple bugfixes. Support for AT&T syntax is experimental and limited to disassembler. If you find any errors, please let me know!

August 21, 2008


NOTE:  I suggest that you use a download manager to get the
.zip file. 

another link:


OllyICE TheMida MOD. By EvOlUtIoN August 18, 2008

Posted by reversengineering in DEBUGGER, TOOLS.
add a comment

OllyICE TheMida MOD. By EvOlUtIoN
Allora, a grande richiesta ecco il debugger che uso normalmente per “giocare” con programmi protetti con TheMida/WinLicense.

La mia patch è semplicissima ma è bene ricordare che OllyICE è stato creato per la prima volta da Hachno, un guru in fatto di Armadillo e di unpacking in genere.

Questa versione ha fondamentalmente 2 patch che la differiscono dal normale OllyICE:
1. Non crasha quando ci si carica un file protetto
2. Se si aggiunge al menù contestuale crea una voce chiamata “TheMida OllyDbg”, così a seconda del target si può aprire un olly od un altro.

Nella cartella plugin sono presenti tutti quelli necessari, i più importanti sono:
1. PhantOm plugin
2. HideOD
Senza questi non si riusicrà mai a caricare un target con TheMida senza essere scoperti.

Inoltre sono presenti 2 script, nessuno dei due dumpa la VM ma almeno trovano l’OEP e aaggiustano la IAT.Allora, a grande richiesta ecco il debugger che uso normalmente per “giocare” con programmi protetti con TheMida/WinLicense.

Translation: Italian » English

My patch is simple but it is good to remember OllyICE was created for the first time in Hachno, a guru in terms of Armadillo and unpacking in general.

This version has basically 2 patches that differ from the normal OllyICE:
1. Not crasha when you load a protected file
2. If you add to the context menu creates an entry called “TheMida OllyDbg”, so depending on the target can open a olly or another.

In the folder plugins are all those present, the most important are:
1. PhantOm plugin
2. HideOD
Without these not riusicrà ever to load a target with TheMida without being discovered.

In addition there are 2 script, neither dump VM but at least find the OEP and aaggiustano the IAT.Allora in great demand here is the debugger that normally use to “play” with programs protected by TheMida / WinLicense.




JDebugTool 4.1.1 August 17, 2008

Posted by reversengineering in DEBUGGER, TOOLS.
1 comment so far

The JDebugTool® graphical Java™ debugger

JDebugTool descriptionA standalone Java debugger, built on top of the standard JPDA and moreJDebugTool has a standalone Java debugger.
-Built on top of the standard JPDA (Java Platform Debugger Architecture).
-Is itself written in Java.
-Features an intuitive and graphical Java Swing GUI.
-Context sensitive Help Viewer.

Debug Applications, Applets, Servlets and EJBs.
Local and Remote debugging.
Run, Attach and Listen.
User friendly GUI.
Multi-Thread debugging.
Breakpoint Groups.
Data Tool Tips.
Hot Swap classes and Pop stack frames.
Save settings in Projects.
Modify primitive variables.
Display loaded classes.
Display toString() results.
Display Chained Exceptions.
Display Memory Usage and Java System Properties.
Evaluate simple Expressions including Method Calls.
Stop on Thread Start and Death events.
Stop on Class Load and Unload events.
Stop on Method Entry and Exit events.
Stop on Field Watchpoint events.
Launch External Text Editor.







Obsidian – Non-intrusive Debugger + src August 16, 2008

Posted by reversengineering in DEBUGGER, TOOLS.
1 comment so far

What is it?

Obsidian is a non-intrusive debugger, which means that it doesn’t change the targets process as a normal debugger would. Being in beta state there can be some minor issues but it should be mostly stable.


Just for the fun of it and the learning of new things. If you have questions, encounter problems or would like to make suggestions for improvements or new features please drop me a line. My mail address can be found at the bottom of the page.

What is it good for?

The main advantage would be that you don’t have to care anymore about those anti-debugger-tricks like:

  • IsDebuggerPresent() which boils down to checking the debugger-flag in the PEB
  • self-debugging: creating another thread or process which attaches itself to the target in order to keep other debuggers from doing so and probably doing some code ‘corrections’ during runtime.
  • timing checks to recognize delays due to an attached debugger.

How does it work?

Basic information

The basics for this project, or to be correct, about the workings of a debugger came mostly from MSDN with additional insight on the course of debugging from iczelion’s tutorials.

Windows API

The debugging functions are implemented by using standard Win32-API calls like:

  • CreateProcess
  • OpenProcess
  • OpenThread
  • CreateToolhelp32Snapshot
  • SuspendThread / ResumeThread
  • ReadProcessMemory / WriteProcessMemory
  • GetThreadContext / SetThreadContext


To implement breakpoints I used a trick I learned from a very interesting paper in Codebreakers Journal. Its name is “Guide on How to Play with Processes Memory, Write Loaders and Oraculumns” and was written by Shub Nigurrath. Shub Nigurrath references the trick itself to yates and his paper “Creating Loaders & Dumpers – Crackers Guide to Program Flow Control”, so kudos to him too. The trick is to place the opcode EB FE at the address you want to stop. This code stands for “jmp -2″ which is the shortest way to code a while(1); loop I know of.


To dis-/assemble the opcodes, I used the awesome code of the disasm zip-file Oleh Yuschuk, creator of OllyDbg, has put on his site. OllyDbg has rightfully gained a reputation for being intuitive and a real alternative to SoftICE when it comes to ring 3 applications.


To extract some information about code and data segments and other stuff about the process I used the information gained from the paper “Portable Executable File Format – A Reverse Engineer View” written by Goppit. This paper can also be found at Codebreakers Journal.

Singlestep and stepping into calls

Since I couldn’t use debug-events, I chose the simple way out and “just” set a breakpoint on the instruction which would be executed next. This involved checking for jumps, calls and returns to make sure to get the right instruction. Checking for conditional jumps was easy since the disasm files (mentioned above) could already do this for me with the Checkcondition function. The same applies for calls. With the exception of calls that got their destination from a register. After searching for a while I found that the lower nibble of the call-opcode gave away the register that should be used. Last time I wrote about StackWalk-function and I have to admit that I was wrong about using it for returns since intel-documentation states that ret in any case uses the first element form the stack. So there’s nothing to be done except reading the DWORD pointed to by the ESP.

Thread Local Storage (TLS)

The first piece of code that will be executed when a new process is started isn’t at the address pointed to by AddressOfEntryPoint. Actually DataDirectory[IMAGE_DIRECTORY_ENTRY_TLS] in the optional header points to a IMAGE_TLS_DIRECTORY32 structure which contains a pointer to a list of functions executed before going to the AddressOfEntryPoint.

Attaching to a running process

There are two handles which are needed to provide full functionality. The first one is the process-handle and the second one is the handle to the main-thread (as obsidian only supports single threaded debugging). In order to allow selection of a process, the set of process id, executable path and name for each process can be gained by employing the CreateToolhelp32Snapshot with TH32CS_SNAPMODULE as parameter. The process id from the selection can be passed to the OpenProcess-function in order to retrieve the process-handle. Getting the thread-handle required a bit more work. The OpenThread-function will return the handle if the thread id is known. Since OpenThread is only available from Windows 2000 Professional onwards the attach method will work only for those systems which provide this function. Finding the thread id can be managed by using the result of CreateToolhelp32Snapshot with TH32CS_SNAPTHREAD. Allegedly the first entry is always the main-thread of the process, so this will be the thread that’s going to be opened. By looking into the returned structure the member th32ThreadID provides the id for the thread that’s required by the OpenThread-function. With both handles and the process- and thread-ids available it is possible to provide complete functionality.

Process dumping

When I started writing the code, I was wondering why there didn’t seem to be any tutorial about dumping a running process with your own program. Most tutorials I found used existing tools for it. There are some really good papers about rebuilding the IAT by the way. Which I will keep in mind for one of the next releases. As I began to reread the PE documentation it occurred to me that this is about all you need to dump an unprotected process. You can get the headers directly from the imagebase of the module and from them you can gather all the other parts. So the job is reassembling the parts scattered through process space by the loader and writing them into a file. Just keep boundaries and offsets in mind.

Stack view

After a long time the makeshift memory display for the stack, it has been replaced by an improved version. To get a better impression of the stack frames the “special” values on the stack (stored EBP, stored EIP and the address pointed to by ESP) are highlighted in different colors. In addition, anything which is not part of the active stack is displayed in gray. Another little feature, long existant but not mentioned yet, is a simple guard to make you aware of a change in the saved EIP. For this to work you need to step into the call and single step through it until you reach the RET. When the EIP was changed a messagebox will pop up and warn you about the change.



Working with symbols is much easier than I first thought. Most work is done by the Sym*-functions provided by the imagehlp library (for example use SymGetSymFromAddr to get a symbols name by its address). So the only part which requires a bit of work, is to determine the levels of indirection so calls via a jumptable could be resolved correctly. The same goes for applying the IDA map file. Once it is parsed, it’s back to analysing references again. By the way, IDA is a very impressive disassembler by Ilfak Guilfanov (formerly DataRescue now at Hex-Rays). It provides a deeper analysis and another view to an executable than most debuggers do. Plus, as the name implies, you don’t need to actually execute the target, which is pretty cool, especially for malware analysis.

Basic block analysis

After the construction of the (more or less) needed basics I decided to take a shot at improving the code analysis. A short research yielded the magical words ‘basic block’, which is a term that originated from optimization concepts of compilers. But perhaps it’s better to first explain what basic blocks are. A basic block is, generally spoken, a sequence of commands that doesn’t contain any jumps and isn’t jumped into. Where jump doesn’t mean the jmp instruction but generally everything that explicitly moves the eip anywhere. The commands I used the determine the end of a basic block are:

  • all jumps, conditional and unconditional (e.g. jmp, je…)
  • call
  • ret

How are blocks and addresses handled? The analyser contains two lists, where one holds all addresses not analysed yet and the other contains the generated blocks. By doing this there is a clean separation between unknown and known blocks. To avoid an infinite loop e.g. when dealing with backward jumps the analyser only processes addresses that do not lie on the beginning of an already processed code-block. Also no processing of addresses out of the modules scope will be performed. This is done to keep the processing-time at an acceptable level. As this approach relies on splitting unknown blocks or dividable known blocks into several smaller ones, the code needs to search through the known and unknown block and check wether the current address implies a splitting or the creation of a separate block. When looking at the code I found that it is much more efficient to walk through the address list backwards (e.g. the latest blocks first) since most matches will occur in the vincinity of the last processed block. The analysis of the code starts at the entrypoint and moves onward from there on. Calls and conditional jumps both yield at best two addresses where the analysis of a new block could be started. The ‘at best’ results from the fact that at the time of analysis indirect addressing with register can’t be resolved, so this is a path that can’t analysed. When an address points into a known block this means that the block needs to be split, since an address can only come from a jump to this location which means the former block ends there and a new one begins. At the moment the analyser doesn’t make any assumptions about what could be meant but only cares for definate information. Thus there are blocks of code which haven’t been recognized and therefore are treated as filling. This affects the readability of the disassembled code. Since any opcode not flagged as code will be disassembled in byte steps. For example an opcode like 74 53 at address 00403F52 will result in the following output:

00403F52     74 53      JE  403FA7
00403F53     53         PUSH  EBX

Mind the addresses, that is what was meant by ‘in byte steps’. This can be fixed by telling the analyser to process the code from the current selection onwards.

General program aspects

Asynchronous messagehandling

The handling of the dialog is now a little more detached from the behavior of the target. Some calls won’t return in a defined time when stepping over them (like DialogBoxParam). Originally this caused the GUI to seem like it hangs but was actually waiting for the function to return. This has been fixed by replacing the blocking call with a polling approach.

Modular approach

After starting with a single executable, I decided to break it up into the GUI which in itself still contains a lot of intelligence and the basic obsidian class which contains all of the debugger- like functions. The main reason for this was to be able to pass the obsidian class to a plugin. But this way you can also easily use the obsidian class in other programs.

Plugin interface

At the moment there is only a by call interface available, which means that the plugin will only be called when the user selects the plugin from the list. To write a working plugin for obsidian you need to export the following two functions from a dll.

extern "C" void EXPORT GetName(char* p, unsigned int len);
extern "C" DWORD EXPORT Go(Obsidian* p);

As the name of the first function implies its only purpose is to store the name of the plugin in the supplied buffer. The second function gets called when the user clicks on the menu entry. This is the place where your plugin can do its work. The paramer you receive is a valid class pointer which should be used by you instead of the singleton construct. To make Obsidian recognize a plugin you need to create a folder called “PlugIns” in the Obsidian-directory and put the dlls into that folder.

to do / missing features

  • until now it’s only possible to debug single threaded applications
  • insert code to catch exceptions in the target
  • add a ‘set symbol-path’-option
  • implementing save and load session
  • creating a simple IAT rebuilder for the dump function
  • resolution of symbols in the stackview
  • storage of user defined settings


  • -

recent fixes / new features

  • added “attach”-functionality. Now you’re able to attach to a running process.
  • fixed malformed exported member from obsidian.dll
  • removed a few memory leaks

Thanks to…

  • morpheus for loads of suggestions and testing and for correcting this site ;-)
  • cryptocrack for further suggestions and testing
  • Thorsten for some ideas about this terribly stubborn CListCtrl.
  • cyrus-tc for discussing ideas and vantage points with me.
  • zaesar for his heap plugin

Where are the links?

As you may have noticed, there are no links on this site. That doesn’t mean that you can’t get to new pages from here. The paragraphs are written in such way to supply you with the needed keywords to find the papers even if the original site went offline. And who knows, perhaps you come across interesting new ones.

Last updated: 07.08.2008


new olly modified AddEd August 14, 2008

Posted by reversengineering in DEBUGGER, TOOLS.

by :korupt

“I decided to make it public :D…

DarkOlly is a modified version of the original OllyDbg(made by myself). changes include modified caption and class name to beat FindWindow() anti-debugging tactics as well as modified visuals and a few tweaks, I’ve posted a screen shot below:

DarkOlly, Click to enlarge

Please let me know of any improvements you think can be made :).

The following package is basically my OllyDbg directory packaged into one archive, just drop the directory from the archive and get started… I’ve included some of the plugins I use most frequently with the package.”


EDB Linux Debugger 0.9.4 August 14, 2008

Posted by reversengineering in DEBUGGER, TOOLS.
add a comment

This time it’s a two version bump to 0.9.4 since I was notified of some x86-64 compilation issues in the last version. Plus I’ve added a few things.


* Sped up analysis by avoiding redundant function analysis. It still isn’t
blazing fast, but is significantly better.

* Fixed a few previously missed 64-bit portability issues.
(toULong -> toULongLong). They were minor, but all of this type should be

* Added a symbol viewer plugin. Double click to see a symbol’s value in the
the current data view. Eventually, I’ll add a context menu to make it
so you can view it in the code view too depending on the type.


* Continued to make improvements to analyzer. It is more accurate, but also
slower at the moment. I will look into good ways to speed it up.


* Fixed some compilation issues on x86-64. Thanks to Stephan Hegel for working
with me to make sure that x86-64 users have a functioning EDB.

* Reworked analysis to have a higher initial favoritism towards findings
functions by recursivly tracing known functions
(symbols/main/entry point, etc). This will make the analysis more accurate
though it does have the side effect of making “percentage complete” at lot
less meaningful since while it will always stop, the number of iterations
during analysis is indefinite.


* Seems that <QtGlobal> needed to be included in QDisassemblyView.cpp for x86-64
targets. Simple fix, but it broke compilation for some platforms so I’m going
to make a release for it.



EDB Linux Debugger v 0.9.1 by Evan Teran July 29, 2008

Posted by reversengineering in DEBUGGER, TOOLS.
add a comment

* Intuitive GUI interface
* The usual debugging operations (step-into/step-over/run/break)
* Conditional breakpoints
* Debugging core is implemented as a plugin so people can have drop in replacements. Of course if a given platform has several debugging APIs available, then you may have a plugin that implements any of them.
* Basic instruction analysis
* View/Dump memory regions
* Effective address inspection
* The data dump view is tabbed, allowing you to have several views of memory open at the same time and quickly switch between them.
* Importing of symbol maps
* Plugins
o Search for binary strings
o Code Bookmarks
o Breakpoint management
o Check for updates
o Environment variable viewer
o Heap block enumeration
o Opcode search engine plugin has basic functionality (similar to msfelfscan/msfpescan)
o Open file enumeration
o Reference finder
o String searching (like strings command in *nix)

One of the main goals of this debugger is isolation of the debugger core from the display you see. The interface is written in QT4 and thus source portable to many platforms. The debugger core is actually a plugin and the platform specific code is isolated to just a few files, porting to a new OS would require porting these few files and implementing a plugin which implements the “DebuggerCoreInterface” interface. Also, because the plugins are based on the QPlugin API, and do their work through the DebuggerCoreInterface object, they are almost always portable with just a simple recompile. So far, the only plugin I have written which would not port with just a recompile is the heap analysis plugin, due to it’s highly system specific nature.


OllyICE 1.10 by Hacnho July 27, 2008

Posted by reversengineering in DEBUGGER, TOOLS.
add a comment

This is an updated release based upon the final OllyDbg release from Hacnho, his further enhanced OllyDbg Hacnho modification. It includes all the bug fixes from his original Hacnho. It is also compressed using the Themida 1.xx Ring-0 engine to help hide the debugger from detection. Be warned it runs quite slowly because of this and it is not very compatible with certain operating systems (WinXP SP2) and applications like anti-virus tools. Blue Screens of Death (BOD) are quite common with this Olly.



Get every new post delivered to your Inbox.

Join 41 other followers