How To Crack A Program W32dasm Tutorial
Денис Окунев
This is my first tutorial and the first lesson so please don't be rude. Due to the fact that English is not my native language there may be errors. Feel free to contact me so that I can correct them.
Some people may ask why I have written this tutorial since everyone who is into cracking knows how to deal with IDA and newbies normally use W32DASM, changing later when they are advanced. I am trying a different approach. It's 2003 now. W32DASM has lots of mistakes and is less powerful than IDA. I decided to make this tutorial for newbies as a First Approach to IDA so that their first tool is a powerful and helpful one for learning how to crack programs. IDA offers Auto Comments so the Assembler language isn't as cryptic for newbies.
Of course, it is useful to have an Assembler Book as a reference but some things may become clearer by just viewing the comments that may be advanced. I won't expect any Assembler knowledge in this tutorial and Assembler will be addressed in my second tutorial. I want this tutorial to cover the most used functions in IDA. It will not be complete and won't replace the help file from IDA. Make sure to read the help file if you run into problems.
I will try to explain a lot of things with screenshots but don't expect a graphical step-by-step walkthrough for every case. I set goal of one week to complete this tutorial because in one week I promised my first lesson.
II. The crack
After some request by different fellows I decided to write a tutorial about the use ofW32Dasm as a debugger. To say it first. The W32Dasm debugger is far less powerful thanSICE.Anyway I prefer using it. You ask why? I prefer looking at WIN95-style windows and Ican load the W32Dasm debugger when I want and I terminate it when I want. To get rid ofSICE you have to reboot the computer. Yes, that's all. Generally both debuggers work inthe same way (as every debugger), but W32Dasm only works with the absolute general things,like changing registers and setting breakpoints on code lines. In SICE you have hundredsof possibilities.
Get relaxed, this will be a long essay. Perhaps it's better to print it out. Get a nicedrink (I prefer water, the one and only drink) and some music in the background (BlindGuardian, what else :). Everything OK? Then let's go.
Sometimes I will say that this or that option is irrelevant and will not explain itfurther. Don't wonder about it. I am sure you can handle SICE not bad, and don't know whatthe instructions "IRP" and "OBJDIR" are (or at least you never usedthem).
Before we start let's have a look at the different options we see in the menu. "Load Process" let's you debug an EXE file you have currentlydisassembled. There's the first main difference between W32Dasm and SICE. In SICE you candebug everything what is currently running (even the Windows Kernel), W32Dasm allows youto debug only the disassembled exe (or dll) file.
"Attach to an active process" disassembles anactive process you have chosen and then starts debugging. The other menuitems arecurrently irrelevant. Only "Debugger Options" mightbe of some interest. In fact I never changed an option. Most of the options are selfexplaining, if you want more information consult the helpfile.
Alright. Disassemble a program and then choose "Debug/LoadProcess". First a small window pops up asking if you want to start the progwith parameters. I used this option only once in my life and it failed, so I don't know ifthis works correctly or the problem was something different. Just push [ENTER] (or disable"Enable Command Line on Load" in the options) andgo on. Now the following windows should appear:
Historically, the static libraries are the first type of libraries to appear. In Windows you can find them by the extensions .lib and .dll. The main difference between the static and the dynamic libraries is that the static library is directly embedded in the executable, thus increasing its size. The dynamic library, on the other hand, is a separate file which uploads a different image of itself in memory every time it is called from a program. The dll is one, but the image is different and this way any inter-process concurrent issues are avoided. This also enables more manageable updates, but implies a slight performance degradation, which is not considered a big issue.
In general, the dynamic libraries are the preferred approach for building applications. Even in the latest versions of Visual Studio there is no option to create a static library; by default all libraries are considered dynamic. Yet it is still possible to create statically linked libraries through the console environment.
That's from me regarding the topic of decompilation, I hope you learned something new today and, hopefully, this knowledge will help you to better protect your software. Know your enemy before going into battle. Because it's the battle for your own time.
Depends on the compilation unit. If it's Java/.Net it will most probably be bytecode/MSIL so it'll be quite easy to decompile, unless obfuscated. You can use tools like Reflector for .Net. If it is C/C++, OllyDbg and IDA are one of the best, nonetheless you don't have a lot of choices here.
The methods I've described in this tutorial are a little bit low-level for your task. I guess you're talking about PicturesToExe deluxe ?
In that case, you've probably tried to use the same program to extract the photos. You got two options:
1. Download this tool and try it on the executable with the pictures
=core&module=attach§ion=attach&attach_id=3655
2. Simply open the slideshow in fullscreen and make a screenshot of the screen. Then use paint to paste it. You might have some quality lost but it depends on the picture itself.
Effectively decompiling an executable and extracting readable code is not an easy task and requires substantial amount of time and expertise related to the operating system, platform and language used during the development.
The .Net exe (or .Net assembly) does not contain assembly code. It contains something called MSIL (Microsoft Intermediate Language), the equivalent of the Bytecode in Java. So when you look at a .Net assembly you see a .Net compliant language (like C# and Visual Basic) translated into MSIL. When this assembly gets executed, the JIT (Just in time) compiler creates the actual assembler code and the binary instructions for the processor to execute. But this happens runtime.
However, you can still see assembly code if the .Net assembly is compiled using something called Native Image Generator (NGen). Then you skip the intermediate language step. But most of the .net assemblies are actually MSIL (the new name for which is Common Intermediate Language (CIL), but I prefer the old one).
In .Net, you have a managed environment. A virtual machine in between. So yes, OllyDbg works at runtime. But the assembler code for your .Net executable is digestible only at runtime, as opposite to a C++ exe, for instance.
I thought that because I was receiving this exception that it would not stop properly at the beginning of the module entry point but apparently that was a mistaken idea of mine. I needed to place a breakpoint at the interesting point of code, otherwise IDA will just plow through the program without stopping. Does this sound right to you?
My company has an exe program that runs from the DOS prompt. The source code is long ago lost. Nobody knows what development language was. All this indicates pre-1993 or older. What could I use to extract the logic and formulas? How can I discern the platform? It is a small engineering program.
The company I am working with has an engineering program that needs to be modernized. It runs from the DOS prompt and is pre 1992. I need to decompile to figure out some formulas. The code is lost and there is nobody around from the build days. Is there a decompiler anyone can recommend? A methodology? Thank you.
@RMK
You are in a tough situation here. Believe me, depending on the length of the application it can take you weeks or even months. Consider the option to invest less time in finding the developer or redevelop the algorithm, or pay s.o. else do it.
You will find that in all source coding is for life users mostly anything new now will be obsolete before you understand it . But this article did pass me good to see thanks for the simple lesson kudos for your knowledge . Not every one gets what you just posted just cause they will never try.
I have a question and maybe you can answer it. We host a game online with a game client and it shows the launcher exe is infected with a virus in windows defender. We are positive there is no issues with the client but we cant extract the files from the .exe to find the flag. Any idea on how to do this. We want this game to grow but we cant do anything if windows defender scares our intended audience away.
IL / .net code is NOT assembly. it may look like assembly, it may act like assembly, but it object orientated in nature (assembly is not). It also exists only as higher level functions of your operating system and only as objects, no flats. And only with C++ and CSHARP. it is by no way means shape or form assembly and is not at all related to the question outside of the fact that it could share a namespace, tottally different. But most people think javascript is jquery and not the other way around so who am I to argue
Well, depends. If the sourcecode and example is enough then go to:
and do a search for 'ddasm11'. It's a table
driven (currently dissambles all[?] instructions of Pentium II), and a bit
messy. If you find it usefull I can make a bit cleaner API for it (the
code is actually "based" on one other disassembler [which was written in
C] and I've just "converted" it into asm - and fixed some bugs).>
> Thanks
> Olivier Gilloire
> Sami Kantoluoto
a.k.a. -tstrike/dawn-
If your code is Windows oriented :)
W32Dasm is sure great for Windows disassembly, but the only time I use
it is when I'm cracking software; otherwise I'll simply use WinIce, IDA,
and Sourcer.But it makes a hash-up of DOS programs, and binary executables, isn't
multi-processor like IDA, doesn't disassemble Java like IDA [I used this
to crack Simpson's key file system], and the disassembled listing can't
be reassembled like Sourcer's can.
--
UNIX - Saving you from the Gates of Hell.