You may be familiar with
ReplayDirector, http://www.replaysolutions.com/products/replaydirector-for-java-ee
Chronon, http://www.chrononsystems.com/products/chronon-time-travelling-debugger
they both advertise themselves as 'Java DVRs' - are there any open-source implementations that offer similar (even a subset of their) features?
The only ones I know of are
WhyLine
Not open source yet, but may eventually be, free download though
Omniscient Debugger
Jive
Diver
TOD
Omniscient debuggers record the trace data to query afterwards. They are often also called reverse-, back-in-time, bidirectional- or time-travel-debuggers, but I prefer to reserve those terms for debuggers that allow actual reversing in a live program.
TOD is an open-source omniscient debugger for Java.
JIVE is another free omniscient debugger for Java, though not open-source.
The GNU debugger, gdb. It has two modes, one is process record and replay, the other is true reverse debugging. It is extremely slow, as it undoes single machine instruction at a time.
And for Python, the extended python debugger prototype, epdb, is also a true reverse debugger. Here is the thesis and here is the program and the code. I used epdb as a starting point to create a live reverse debugger as part of my MSc degree. The thesis covers the details of the implementation, as well as most of the historical approaches to reverse debugging. It is available online: Combining reverse debugging and live programming towards visual thinking in computer programming.
Related
As part of the work I've been doing to answer this question about the technical workings of a glitch in Pokémon Red, I've been looking for a way to use a standard debugger to debug a Game Boy ROM. Although many of the emulators I've found have some support for debugging, nothing I've found so far has been helpful.
As a background, as of now I have tried to use the Visual Boy Advance built-in features to do debugging, but they aren't particularly useful for what I'm trying to do. VBA lacks the ability to set breakpoints, and since it steps forward at the level of frames rather than instructions I'm unable to see how the code is executing when I actually need it to. Although VBA says that it supports GDB debugging, I have been completely unable to get it working. I tried cross-compiling GDB for ARM as per the instructions, but could not get GDB to connect to the emulator (it would recognize that there was a program to connect to, but reported that the protocol had been violated). I repeated this with similar success in both Windows with Cygwin and on Ubuntu Linux. A friend and I tried to use Insight/GDB, but ran into exactly the same problems.
I also tried to use the NO$GBA debugger, but it refused to load my ROM for Pokémon Red (and then insulted me by saying that nothing I could try to do would fix it, as the file was just flat-out wrong).
Additionally, I tried downloading this version of Visual Boy Advance that claims to have a debugger in it, but for some reason I can't get it to enable the debugger. Pressing F11 as per its instructions has no effect whatsoever.
I believe that I've done my due diligence trying to get a debugger working, and I'm surprised that not a single one of them has worked. Does anyone know of a simple, straightforward way to debug Game Boy games using standard debugging techniques? I'm interested mostly in being able to put in memory write breakpoints (to see what routine is clobbering certain parts of memory). I would really appreciate it if someone with first-hand experience doing this could provide details on how to do this, as online resources on the subject seem pretty limited.
If you just want to debug your old gameboy games you can also use bgb which has several debugging options such as tracing, breakpoints, profiler and a lot more.
No$GBA is for GBA games; you want NO$GMB. Note that it's very buggy, and without a registered version (which may be impossible to get legitimately) rather crippled.
bgb is free and is very similar to No$GMB, but even buggier.
VBA is supposed to have a debugger, but there are a million different versions out there, so good luck finding the right one.
Check out the site GbaDev.org and look on the forums. This is the best spot on the web for GBA or even GBC questions. I can tell you that there are many versions of VBA and no$ out and about. The No$ you want was technically a pay for version, but Martin Korth hasn't been answering emails or anything for years now and I'm not sure of its status anymore. I can also answer some questions for you personally if you'd like or help you with the debugger.
I was able to go to the no$ main website, download the windows version of no$gmb, and use it to debug when run in B/W mode - should be sufficient for you needs. F12 opens roms, F2 toggles break points, space traces, F3 steps over, Ctrl-G takes you to an address (or symbol), and Ctrl_B allows conditional break points (by far the most powerful feature for you to use.) For instance, (3000)! would set a read/write breakpoint on address 0x3000. (0300..03003)! sets on a range. As you are looking for specific address changes, this is what you want.
VBA-M has a bunch of debugging tools under "Tools" menu, including memory & tile inspectors and a disassembler. It even has support for GDB. I didn't test with any frontends like gdbgui, or VSCode's GDB support, so YMMV, but the other built-in tools look pretty decent.
Go to the releases section for a build for your platform (arch linux also has it in AUR, for easy install in package manager.)
Here it is running some of the tools on a Mac:
It seems there are dozens of debugger and debugging tools that Microsoft produces, which creates a maze of choices and questions concerning which tool to apply, and when. For example, there is windbg - and the debugger built into Visual Studio. Both can access minidumps. Why would I choose one over the other?
Dr. Watson was the default post-mortem crash analysis tool of the past. It has now been replaced with "Problem Reports & Solutions". Which is in turn replaced with IIS Exception Monitor on servers? And perhaps all of this is built on top of "Microsoft CDB Debugger," or perhaps that is a another duplicate tool? ADPlus, yet another one, is built on CDB Debugger. The maze seems to go on endlessly.
Can someone provide a link to a taxonomy or roadmap of all these tools, with comments of which are being deprecated (Dr. Watson?) and what "tool direction" debug students should absorb? I'm sure there are a number of tools and base libraries I've not mentioned here. it would be nice to know the dependencies between them too (such as ADPlus using the CDB Debugger).
I've found this link to be helpful, since it answers some of the questions I'm asking - though the material is dated. Any other resources that give a similarly simple compare / contrast run-down?
There is no difference between CDB and NTSD, other than how they spawn new windows. Choosing when to use Visual Studio over the command line debuggers is sometimes a matter of personal choice, but sometimes the command line is a better tool for the job. Once you get good at using the command line debuggers, you can get things done much more quickly. I suspect there are a few scenarios that remain where you can only debug a specific problem with the command line debugger, but I can't think of any off hand. The third debugger you've missed is kd, which is the kernal debugger. If you want to debug kernal mode stuff (i.e. your device drivers you've written) it's really your only choice.
CDB, NTSD and KD are all part of the debugging tools for Windows, itself part of the DDK. Visual Studio does not depend on the other debugging package and vice-versa.
Watson and the like are not debuggers. They merely observe and report. I suspect the best advice there is use whichever one is appropriate to your problem. I mean, there are lots of tools for all sorts of different MS technologies. E.g. Orca for MSI databases. All of these products are unrelated, often released and maintained by different divisions, etc. As a result, I doubt you'll find a chart showing their relationships since they are so diverse.
I am using a rather obsure, proprietary langauge called WIL/Winbatch that had an awful IDE (winbatch studio).
I would like to develop an alternative environment; however, without the ability to set breakpoints, step, and examine variables, there is really no point. How does one begin even researching how to implementing a debugger for a proprietary language? Is it even legal?
I guess I'm kind of locked in a mindset that the debugger portion must be able to examine the statements that are provided to it in WIL as they are executed, right? So somehow i have to trap the output of the interpreter? Or is it just a matter of reading locations in memory using whatever language?
Thanks in advance.
Having been there and successfully completed the task, here are the things to keep in mind:
Build it as a plug-in/extension to an IDE your team is already familiar with and likes. They'll thank you for providing an interface consistent with what they really know how to use, plus you can focus entirely on the features that make your language different from others.
You'll have to learn the debugging protocol for your language. In our case, we had source access to the runtime for the interpreted language. In other cases, you may find documentation for GDB local or remote debugging interface, a library you can link to for the language's debugging protocols, or maybe even figure out what the call stacks look like and wrap the Windows Debugging API to analyze it behind the scenes.
Don't build in excess of what the language provides. Adding debugging features takes a lot of time, and they have a rather annoying habit of needing to be significantly altered or completely rewritten as versions of the target language are updated.
Why are you tied so closely to this language? If it's not well supported, there are many others you can use. Anyway, to actually answer your question, the difficulty depends on whether it is a compiled or interpreted language and whether or not you have access to any source code (which it seems of course, that you don't). That said, this would be a very challenging project as you would have to reverse engineer the compiled code for it to have any meaning. Your time would be better spent learning another (better) language.
Perhaps if you can give us an idea of why you want to use this language we could give you some help?
I'm interested in what tools and methods are used for diagnosing flaws in large scale functional programs. What tools are useful? My current understanding is that 'printf' debugging (e.g. add logging and redeploy) is what is typically used.
If you've done debugging of a functional system what was different about it then debugging a system built with an OO or procedural language?
Sadly, printf debugging seems to be the state of practice for Standard ML, Objective Caml, and Haskell. There's a little bit of debugging at the interactive read-eval-print loop, but once your app hits 25,000 or 50,000 lines that's less useful.
If you're lucky enough to be using Haskell, there's an exception: QuickCheck is indispensible for testing and deubgging. QuickCheck can be used even on combinations of Haskell and C code, as demonstrated by experience with the Xmonad window manager.
It's worth noting that around 1990 Andrew Tolmach built a very nice time-travel debugger for Standard ML of New Jersey, but that it was not considered worth maintaining. It's also worth noting that at one point the OCaml debugger (also a time-travel debugger) worked only on bytecode, which was inconvneient, and refused to violate abstraction barriers, which made it useless. This was around release 3.07 or so; perhaps things have improved.
Also in the early 1990s, Henrik Nilsson built an interesting debugger for Haskell, but mostly what it did was prevent the debugger from accidentally changing the evaluation behavior of the program. This was interesting, but only to lavzy-evaluation weenies.
As someone who has built or worked on large applications in all three of these languages, I find the state of play depressing.
The main tools we use at work (a Haskell shop) are:
QuickCheck
HPC: visual Haskell program coverage tool (we developed this in house)
Logging/printf/trace
Sometimes, the GHCi debugger
My current job is to implement new features and support a large system implemented in ocaml and C#. Most of the "logic" is implemented in caml and the GUI and data access is in C#. The debugging techniques are pretty much as you describe lots of logging and assert to work out what's gone wrong.
Additionally we have a large number of unit tests, which are just caml scripts for testing the logic and help to spot any regression errors.
We also use continuous integration to check the build and run nightly test scripts, including some automated testing of the GUI though our "automation" style scripting interface.
I quite often use the C# debugger for debugging the C# portion of the application, the ocaml debugger does yet work under windows so we don't use it. Although we hope one day we may fix this but it isn't top of our priority list. I have occasionally used windbg to investigate managed and unmanaged memory problems, though this turned out to be caused by a third party component implemented in C#.
So overall, nothing out of the ordinary but it seems to work okay, we don't see too many production problems.
Thanks,
Rob
F# has Visual Studio integration, so you can attach the debugger to your program and set breakpoints, watches, etc, just like with any other .NET language.
However, I prefer to avoid debugging as much as possible, by writing short functions that I can unit-test individually.
A couple of years ago when I did this I had to use a combination of printf debugging and QuickCheck. These days I would also use the ghci built-in debugger.
The biggest headache was actually laziness causing space-time leaks. There still doesn't seem to be a good answer to these: just do lots of profiling and keep trying to figure it out.
OCaml and F# both have excellent debuggers. OCaml's is time reversible. F#'s has excellent IDE and multithreading support.
A friend of mine downloaded some malware from Facebook, and I'm curious to see what it does without infecting myself. I know that you can't really decompile an .exe, but can I at least view it in Assembly or attach a debugger?
Edit to say it is not a .NET executable, no CLI header.
With a debugger you can step through the program assembly interactively.
With a disassembler, you can view the program assembly in more detail.
With a decompiler, you can turn a program back into partial source code, assuming you know what it was written in (which you can find out with free tools such as PEiD - if the program is packed, you'll have to unpack it first OR Detect-it-Easy if you can't find PEiD anywhere. DIE has a strong developer community on github currently).
Debuggers:
OllyDbg, free, a fine 32-bit debugger, for which you can find numerous user-made plugins and scripts to make it all the more useful.
WinDbg, free, a quite capable debugger by Microsoft. WinDbg is especially useful for looking at the Windows internals, since it knows more about the data structures than other debuggers.
SoftICE, SICE to friends. Commercial and development stopped in 2006. SoftICE is kind of a hardcore tool that runs beneath the operating system (and halts the whole system when invoked). SoftICE is still used by many professionals, although might be hard to obtain and might not work on some hardware (or software - namely, it will not work on Vista or NVIDIA gfx cards).
Disassemblers:
IDA Pro(commercial) - top of the line disassembler/debugger. Used by most professionals, like malware analysts etc. Costs quite a few bucks though (there exists free version, but it is quite quite limited)
W32Dasm(free) - a bit dated but gets the job done. I believe W32Dasm is abandonware these days, and there are numerous user-created hacks to add some very useful functionality. You'll have to look around to find the best version.
Decompilers:
Visual Basic: VB Decompiler, commercial, produces somewhat identifiable bytecode.
Delphi: DeDe, free, produces good quality source code.
C: HexRays, commercial, a plugin for IDA Pro by the same company. Produces great results but costs a big buck, and won't be sold to just anyone (or so I hear).
.NET(C#): dotPeek, free, decompiles .NET 1.0-4.5 assemblies to C#. Support for .dll, .exe, .zip, .vsix, .nupkg, and .winmd files.
Some related tools that might come handy in whatever it is you're doing are resource editors such as ResourceHacker (free) and a good hex editor such as Hex Workshop (commercial).
Additionally, if you are doing malware analysis (or use SICE), I wholeheartedly suggest running everything inside a virtual machine, namely VMware Workstation. In the case of SICE, it will protect your actual system from BSODs, and in the case of malware, it will protect your actual system from the target program. You can read about malware analysis with VMware here.
Personally, I roll with Olly, WinDbg & W32Dasm, and some smaller utility tools.
Also, remember that disassembling or even debugging other people's software is usually against the EULA in the very least :)
psoul's excellent post answers to your question so I won't replicate his good work, but I feel it'd help to explain why this is at once a perfectly valid but also terribly silly question. After all, this is a place to learn, right?
Modern computer programs are produced through a series of conversions, starting with the input of a human-readable body of text instructions (called "source code") and ending with a computer-readable body of instructions (called alternatively "binary" or "machine code").
The way that a computer runs a set of machine code instructions is ultimately very simple. Each action a processor can take (e.g., read from memory, add two values) is represented by a numeric code. If I told you that the number 1 meant scream and the number 2 meant giggle, and then held up cards with either 1 or 2 on them expecting you to scream or giggle accordingly, I would be using what is essentially the same system a computer uses to operate.
A binary file is just a set of those codes (usually call "op codes") and the information ("arguments") that the op codes act on.
Now, assembly language is a computer language where each command word in the language represents exactly one op-code on the processor. There is a direct 1:1 translation between an assembly language command and a processor op-code. This is why coding assembly for an x386 processor is different than coding assembly for an ARM processor.
Disassembly is simply this: a program reads through the binary (the machine code), replacing the op-codes with their equivalent assembly language commands, and outputs the result as a text file. It's important to understand this; if your computer can read the binary, then you can read the binary too, either manually with an op-code table in your hand (ick) or through a disassembler.
Disassemblers have some new tricks and all, but it's important to understand that a disassembler is ultimately a search and replace mechanism. Which is why any EULA which forbids it is ultimately blowing hot air. You can't at once permit the computer reading the program data and also forbid the computer reading the program data.
(Don't get me wrong, there have been attempts to do so. They work as well as DRM on song files.)
However, there are caveats to the disassembly approach. Variable names are non-existent; such a thing doesn't exist to your CPU. Library calls are confusing as hell and often require disassembling further binaries. And assembly is hard as hell to read in the best of conditions.
Most professional programmers can't sit and read assembly language without getting a headache. For an amateur it's just not going to happen.
Anyway, this is a somewhat glossed-over explanation, but I hope it helps. Everyone can feel free to correct any misstatements on my part; it's been a while. ;)
Good news. IDA Pro is actually free for its older versions now:
http://www.hex-rays.com/idapro/idadownfreeware.htm
x64dbg is a good and open source debugger that is actively maintained.
Any decent debugger can do this. Try OllyDbg. (edit: which has a great disassembler that even decodes the parameters to WinAPI calls!)
If you are just trying to figure out what a malware does, it might be much easier to run it under something like the free tool Process Monitor which will report whenever it tries to access the filesystem, registry, ports, etc...
Also, using a virtual machine like the free VMWare server is very helpful for this kind of work. You can make a "clean" image, and then just go back to that every time you run the malware.
I'd say in 2019 (and even more so in 2022), Ghidra (https://ghidra-sre.org/) is worth checking out. It's open source (and free), and has phenomenal code analysis capabilities, including the ability to decompile all the way back to fairly readable C code.
Sure, have a look at IDA Pro. They offer an eval version so you can try it out.
You may get some information viewing it in assembly, but I think the easiest thing to do is fire up a virtual machine and see what it does. Make sure you have no open shares or anything like that that it can jump through though ;)
Boomerang may also be worth checking out.
I can't believe nobody said nothing about Immunity Debugger, yet.
Immunity Debugger is a powerful tool to write exploits, analyze malware, and reverse engineer binary files. It was initially based on Ollydbg 1.0 source code, but with names resoution bug fixed. It has a well supported Python API for easy extensibility, so you can write your python scripts to help you out on the analysis.
Also, there's a good one Peter from Corelan team wrote called mona.py, excelent tool btw.
If you want to run the program to see what it does without infecting your computer, use with a virtual machine like VMWare or Microsoft VPC, or a program that can sandbox the program like SandboxIE
You can use dotPeek, very good for decompile exe file. It is free.
https://www.jetbrains.com/decompiler/
What you want is a type of software called a "Disassembler".
Quick google yields this: Link
If you have no time, submit the malware to cwsandbox:
http://www.cwsandbox.org/
http://jon.oberheide.org/blog/2008/01/15/detecting-and-evading-cwsandbox/
HTH
The explorer suite can do what you want.