I have the source code of an assembly language program, which has comments on every line, and I want to see those comments in the comment column of OllyDbg's disassembly as it debugs. Without writing a full blown plugin, is there any way to do this?
Comments do not make it into the final exe. I don't even think comments make it into the pdb file for a debug build.
If you have the source code that includes the comments in the directory of the exe, open the exe in olly, click the view menu then click source, this will open the source file with your comments and all.
99% of the time, what you write in your source file, is what olly shows, unless you are using a lot of macros.
After some more experience I found that there are basically 3 approaches:
Modify the .udd files that OllyDbg uses to store comments directly.
Use a label plug (unfortunately the one I found does not work on 2.01)
Create a debug file in a format OllyDbg understands (DWARF I think)
Since 3 is pretty complex, my best option is probably 1.
Related
I am writing an app using applescriptobjc in xcode, and while making the archive I see the source code is still inside the package, is there a way to hide it or transform it completely to binary code?
Thanks
I may be a year late to the discussion but I asked the same question around the same time as you did last year and hope that the answer I got will satisfy your own question. Here is an extract answer from
my own question:
When you save the AppleScript file you have the option of checking "Run Only" - in that case the script is compiled into a new form that can be run exactly as the original script, but it is not meant for further editing/development.
It doesn't mean that the run-only file is complete protected or non-readable, but parts of your code, comments, etc. are not included or not easily readable.
If you want to do more you'll need a code obfuscator if you still want to use AppleScript - however I'm not sure if one exists on the market, or you need to develop your own.
As you can see, a simple way to do this is:
Open your final AppDelegate.applescript file in Script Editor on the mac.
Select: File > Export...
2.1. Don't change the file name but override the archive file
2.2. BEFORE SAVING: Choose Run-only checkbox from the save options but leave the File Format as Script
Now your file cannot be opened in plain text as it is set to Run-only. Please remember that it is not a 100% read-proof solution, but works great for small projects (provided you are not rushing the final export and don't forget to perform the above mentioned steps before handing it over to the customer).
I hope you can make the most of this answer and still deem it useful. Let me know how you get on or whether you have any more questions. Perhaps you have since found a far better solution (or just an alternative), if so, I am still looking for the next best thing in source code protection.
In Xcode 9.2. (and maybe earlier versions) you can find under Build Settings the item OSACompile and can choose to compile to an executable only directly from Xcode.
I'm debugging a problem at present in Windbg from a dump. I've got the correct pdbs and I can view the locals etc quite happily. However, the source code I have (which I've pulled from the VCS branch from which this release supposedly came from) appears to be off by several lines in some parts of the stack I'm looking at. I've seen instances where it's off by 1 before, but not 3/4 lines.
What causes this? Is there any definitive way I can check that I've got the right source files?
Are you looking at debug or non optimised version of release code?
Code optimisation may cause the line shift you are seeing so you should recompile with /Od C++ optimization set to 'disabled' and see if this corrects what you see.
WinDbg uses the same method as Visual Studio to check if the source file you are viewing/setting breakpoints with matches the pdbs so it should warn you (I think it does this I cannot verify).
Besides you can verify the pdbs if not the source files using:
!itoldyouso myDLL
additionally you can open the source file in another window, during stepping and it should put a magenta line at the line it thinks the current call is at, this should be correct and behave the same as visual studio.
Case: One source file has a comment in it that is directly linked to a comment in another source file (it says see line 315 in xxx.cs for more information). The problem with this approach is that the comment on line 315 may not be at that line number in the future. Is there a way to link comments together in an IDE? (currently using Visual Studio 2010, but use other IDEs from time to time)
You can try this addin (I haven't used this):
http://hyperaddin.codeplex.com/
Besides this addin, the only thing I can think of is using a file link to directly go to the linked file; something like:
// ...
// See file://path_to_file
//...
The link will be converted to an actual link that you can click using Ctrl+Left Click but it won't take you to a given line number - it just opens the file.
The path can be a relative file path or a full file path - full paths work best if all team members use the same folder structure in the project. For example:
// file://w:/projects/GUI/frmMain.cs
Referring to a particular source file and line number is never a good idea, because someone might move things around in the other file without being aware that something is pointing at it. It's better to point at the particular type/method, for example See DoThings() in the MyThing class..
In Java, using Javadoc, you can use #link to do this, for instance See {#link MyThing#doThings()}. Eclipse will automatically update these when using its refactoring tools (e.g. renaming the class or the method). If the change is done manually, Eclipse will still warn that the target of the #link is invalid. (There is also #see which is more appropriate in some situations.)
I'm not sure about C# and Visual Studio, but it's likely that its XML-based doc format offers similar functionality.
The only way to handle this is to put the comment in the same file. Duplicating a comment is not the same as duplicating code, although ideally the code wouldn't need too much explanation in comments.
There are many, many reasons why the comment being in another file will cause pain. As you have stated, the line number may change but also it could be deleted (as they won't know another comment references it), updated in a way that changes its meaning and it is annoying to have to open another file in any case.
my friend has made a really helpful class library which I use all the time. I usually use Reflector to see what his code does.
What I really wanted to do was to step through his code while I'm debugging. So he gave me his .pdb file.
Foo.dll (release configuration, compile)
Foo.pdb
Now, I'm not sure how I can get it to auto break into his code when it throws an exception (his code, at various points, thorws exceptions .. like A first chance exception of type 'System.Web.HttpException' occurred in Foo.dll ...
Can I do this? Do i need to setup something with the Symbol Server settings in Visual Studio ? Do i need to get the dll compiled into Debug Configuration and be passed the .dll and .pdb files? Or (and i'm really afraid of this one) .. do i need to have both the .dll, .pdb AND his source code ...
I also had a look at this previous SO question, but it sorta didn't help (but proof I've tried to search before asking a question).
Can someone help me please?
Yes you can, if your friend indexes those PDB's, so that the debugger knows where to find the appropriate source in a source-control system, and if your friend uploads those pdb's to a symbol-server, you can perfectly step through the code while debugging.
I have done this for some projects at work, and this works like a charm.
More info about setting up a symbol server:
Source server helps you kill bugs
Setting up a symbol server
Using symstore
The answer is in in the linked question, though perhaps it's not blindingly obvious, so I'll say it: yes, you need to have the source code in order to step through the source code. The PDB file only tells the debugger what line of what source file corresponds to a particular machine instruction.
You don't need to set up a "symbol server" or anything like that. Just get him to send you the source. When you load the PDB file Visual Studio will prompt for the location of the source files if they're not at the same path.
I guess you posted link to another question just to prove that you have searched because that question does have an answer to your question.
This may sound like a newbie question - and it is. I'm relatively new to vs, we started using it a few months ago, and I still haven't "mentally" made the change from the command line. So, if you could help me with 2 things:
I create a new project (not a solution). He puts the files in some directory. After putting my code inside it, I click on the little green triangle (Debug, it says), and he compiles it, builds it and runs it. It works ok. Now, sometimes, I have to change only a tiny bit of code and I don't feel like getting the whole VS up just for that. How can I do that Debug thing from the command line, with the assumption I didn't change anything else.
Where do I tell him not to create a "Debug" subdirectory, not to create a HTML Build log, an object file ... and so on, generally, where can I find the settings which will help me to get as little files ... apart from my original source, and the .exe resultant one ?
I have to change only a tiny bit of code and I don't feel like getting the whole VS up just for that. How can I do that Debug thing from the command line, with the assumption I didn't change anything else.
I think what you want here is not debugging but a rebuild of your project.
Where do I tell him not to create a "Debug" subdirectory, not to create a HTML Build log, an object file ... and so on, generally, where can I find the settings which will help me to get as little files ... apart from my original source, and the .exe resultant one ?
The answer to both these questions is to use the command line! You can make VS emit a make file from the loaded project. Use NMAKE to build this make file after you have made your desired modifications. The ".obj" files are created as an intermediate step between compilation and linking phase this is how the C++ compilation model works. Why do insist on not generating them?
You can't really start debugging without starting up Visual Studio, since Visual Studio is the debugger. You can tell VS to rebuild a solution from the command line without firing up the UI if you want to just build it: See MSDN for details.
You can control the creation of the DEBUG and RELEASE directories via the 'intermediate files' option in the project settings. Though you need to create the obj file somewhere in order for the compile to work.