Rick Drizin

You can do anything, but you can't do everything

Blog

About

Contact

on cracking

I really enjoy cracking software (reverse engineering, to be politically correct).

To be honest, I enjoy breaking software even more than constructing software. Since I was 15yr old I have been a bit involved into assembly language, and reversing.

When I was in college, I once made a nice work about software cracking. From the final presentation, what I remember most is one specific slide, which was very surprising for most people in the audience who didn’t know anything about software cracking. It had a pseudo-assembly example:

CALL the_best_ever_created_cryptographic_protection
JNZ serial_invalid <---- this is where we gonna crack

This is the beauty of software cracking - people take hundreds of lines to protect their software, and you can usually break into it modifying 2 or 3 bytes.

Let’s cut the crap. Today I’m going to talk about .NET Cracking.

Everybody knows cracking .NET is much easier than cracking x86, but sometimes there are obfuscators which do a good job in making it hard for you to crack something.

When you CAN’T use tools like FileDisassembler and FileGenerator (both plugins of Reflector), you must use ILDASM, to decompile in IL code (MSIL). Usually it will work as simple as this:

Decompile:

C:\> "C:\Program Files\Microsoft Visual Studio 8\SDK\v2.0\Bin\ildasm.exe" SomeoneElsesProgram.dll /OUT=SomeoneElsesProgram.IL

… decompiled.

Recompile:

C:\> "C:\windows\Microsoft.NET\Framework\v2.0.50727\ilasm.exe" /DLL SomeoneElsesProgram.IL /RESOURCE=SomeoneElsesProgram.res /DEBUG /OUTPUT=ModifiedSomeoneElsesProgram.DLL

… compiles ok? Usually that works.
Ok, try to find what instructions you should change, and recompile.
… worked? no, then try again, etc..
(OBS: In some future post I will post some tips on IL cracking.. )

However, I said “Usually that works”. Sometimes the recompilation does NOT work with the generated IL file. Tools like the XenoCode Obfuscator apply these invalid-character techniques to protect software from you.

A few weeks ago I had this problem: when decompiling a DotNetNuke module it seemed ok, but it generated a IL file with some weird characters. When recompiling I got many errors like:
- SomeoneElsesProgram.IL(xx) : error -- Duplicate field declaration: ‘?’
- SomeoneElsesProgram.IL(xx) : warning -- Duplicate param name ‘?’ in method ‘?’

So, I wasted a few days trying everything I could:
- Tried to identify and rename manually those invalid characters
- Tried to find a better decompiler
- Tried to use a tool which claims to allow renaming of fields/methods/parameters directly in the assembly without decompiling
- Tried to crack that tool, since it was not freeware (demo)
- Could not crack it, since it was itself obfuscated with those same invalid chars
- Tried to modify FileGenerator plugin (it has free sourcecode)
- Tried to modify Reflector itself.

When I was almost giving up, I had the not so brilliant idea - read the fucking manual:

C:\> "C:\windows\Microsoft.NET\Framework\v2.0.50727\ilasm.exe" /?

Then I discovered something that could save you those wasted days I had: /UNICODE and /QUOTEALLNAMES parameters

I Tryied it again - Decompiling:

C:\> "C:\Program Files\Microsoft Visual Studio 8\SDK\v2.0\Bin\ildasm.exe" /QUOTEALLNAMES /UNICODE SomeoneElsesProgram.dll /OUT=SomeoneElsesProgram.IL

… decompiled.

Recompiling:

C:\> "C:\windows\Microsoft.NET\Framework\v2.0.50727\ilasm.exe" /DLL SomeoneElsesProgram.IL /RESOURCE=SomeoneElsesProgram.res /DEBUG /OUTPUT=ModifiedSomeoneElsesProgram.DLL

Resolving local member refs: 0 -> 0 defs, 0 refs, 0 unresolved
Writing PE file
Operation completed successfully

Whohoo !! Recompiled !

Happy cracking.

on versioncontrol

Every once in a while I get in contact with customers who are still using Microsoft Visual SourceSafe 6.0.
In my (not so humble) opinion, SourceSafe completely sucks: too few features, too many bugs, too many crashes and data corruptions, and concepts much different from modern version control software.
And believe-me: I’m not an anti-Microsoft guy, in fact I think Microsoft has fantastic products, but surely SourceSafe is not among them.
(You can google to see other opinions on this.)

I have made some extensive research on version control software, for using both at my company and in some other customers, and concluded that Subversion(also known as SVN) is the best version control software available today. (I won’t enumerate the advantages cause you can find many comparisons on google.)

And the best: It’s free, and you can integrate with your windows explorer, VS.NET 2003⁄2005, and almost all other IDEs.

You can check it out at http://subversion.tigris.org/.
There is also a free ebook about Subversion in that url, but I’m writing this post to give you basic steps on how to install Subversion on Windows. In special, I have found that there are many tutorials out there teaching how to install Subversion on Windows, but most of them are outdated or incomplete (specially about creating the windows service using the obsolete svnservice, and about configuring permisions).

Easy steps:

1) Install Binaries

  • Download lastest Subversion Win32 Binaries from http://subversion.tigris.org/servlets/ProjectDocumentList?folderID=91

  • You can either:

    • Download the zip file (eg: svn-win32-1.4.6.zip ) and unzip it into C:\Program Files\Subversion
    • Or download the windows installer file (eg: svn-1.4.5-setup.exe) and install it to C:\Program Files\Subversion

  • Since my regional settings are Portuguese-Brazil and I hate translations, I always remove the folder C:\Program Files\Subversion\share\locale\pt_BR, so all messages are still displayed in english. (There must exist some other way to do that, I didn’t find out).

2) Configure Environment Variables:

  • Open My Computer (right button over the icon) - Properties - Advanced - Environment Variables
  • Add a new System Variable: “SVN_EDITOR”, pointing to “C:\Windows\Notepad.exe”
  • Modify the PATH System Variable: Add the following folder C:\Program Files\Subversion\bin;

3) Create the repository

  • Create a folder for the repository (ex: C:\SVNREPOSITORY)
  • Open a command prompt and run the following commands:
  • C:\> svnadmin create C:\SVNREPOSITORY
  • (optional): you can check the created files in C:\SVNREPOSITORY
  • Important: don’t get confused on REPOSITORY FOLDER and LOCAL WORKING FOLDER.
    Your local working folder is where your local copies are stored, you can modify files, commit to the repository, get updates from the repository.
    The repository folder is a database which you shouldn’t touch. The Subversion Server uses this database for serving files to Subversion Clients.

4) Install Windows Service.

  • Open a command prompt and run the following commands :
 C:\> **sc.exe create svn.srv001 binpath= "c:\Program Files\Subversion\bin\svnserve.exe --service -r \"C:\SVNRepository\" " displayname= "Subversion Server 001" depend= tcpip

Please note you should replace C:\SVNRepository with your repository folder (from last step).
You should see “[SC] CreateService SUCCESS” if all goes well.
Be sure you don’t remove the backslashes () before the quotes (“) as they are needed by sc.exe to properly parse the quotes needed in the path. The spaces after the switches (binpath= , displayname= , depend= ) are required as well.

  • Let’s configure the service to autostart (on windows startup):
    C:\\> sc.exe config svn.srv001 start= auto  

[SC] ChangeServiceConfig SUCCESS
  • And let’s start it right now:


    C:\\> **sc.exe start svn.srv001**  

    SERVICE_NAME: svn.srv001
    TYPE : 10 WIN32_OWN_PROCESS
    STATE : 2 START_PENDING 
    (NOT_STOPPABLE,NOT_PAUSABLE,IGNORES_SHUTDOWN)
    WIN32_EXIT_CODE : 0 (0x0)
    SERVICE_EXIT_CODE : 0 (0x0)
    CHECKPOINT : 0x0  
    WAIT_HINT : 0x7d0 
    PID : 6908<  
    FLAGS :
  • Excellent! Our service is now automatic.
    Remember you can configure most things from a Windows service from the “Start, All Programs, Administrative Tools, Services”, or just run “services.msc” from Start/Run or from a command-line.
    If by any reason you need to delete the service you just created you can do this:
    C:\> sc.exe stop svn.srv001  
    C:\> sc.exe delete svn.srv001
  • (optional): Let’s just check if svn can connect to our service:
    C:\\> **svn ls svn://localhost  

**If no error occurs, your server is running ok. No files should be listed since there is no file in the repository.  
You haven't been asked for a user or a password because by default the server allows anonymous read access (anon-access = read).

  • (optional): Try to create a folder:
    C:\> svn mkdir svn://localhost/Products

    It will open your default editor (notepad) asking for you to type a reason for the command you asked (mkdir). Just type anything, save and close the file. You will get a message like this:
    svn: Authorization failed,
    which happens because there are no registered logins for this repository.

5) Configure permissions for the repository

  • Open with notepad the repository configuration C:\SVNREPOSITORY\conf\svnserve.conf
    and paste just the following lines (remove everything else):
      [general]  
      anon-access = none  
      auth-access = write  
      password-db = passwd.conf  
      authz-db = authz.conf  
      #realm = My First Repository

Please note that I renamed “passwd” to “passwd.conf” and “authz” to “authz.conf” both in the config file here, and in the filesystem too, so I can just associate the conf extension with notepad and make my life easier.

Note also that when a realm is not specified, it will be assumed to be the repository guid (created when you created repository). Realms should be unique among different repositories, unless you want to share the same permissions among them. * Rename authz to authz.conf * Rename passwd to passwd.conf * Open passwd.conf with notepad and put some users/passwords by pasting the following lines (remove everything else):

       [users]  
       admin = qwerty147  
       ricardo = pwd123  
       marcelo = pwd456  
       joao = pwd789
  • Now open authz.conf with notepad and paste just the following lines (remove everything else):
      # guests will have read permission in all repository  
      # writers must include all non-admin users who must have write  
      # permission on some folder (read permission on root is needed for that)  
      [groups]  
      admins = admin, ricardo  
      writers = marcelo  
      guests = joao  
      project1 = marcelo  
  
      [/]  
      @admins = rw  
      @writers = r  
      @guests = r  
      * =  
  
      # please note that permissons (ex: admins group) don't propagate from root to subprojects  
      [/Project1]  
      @project1 = rw  
      @admins = rw  
      * =

  • Now you can try again mkdir:

    C:\>svn mkdir svn://localhost/Products  
Authentication realm: e9852c7c-f11f-1946-b4a8-49fa8b53a267  
Password for 'Ricardo': ******

    Please note that it will by default assume your username is the same as your windows login. If it is not, just put any password, and it will ask you for your correct username.

  • If everything went ok you will get a message like “Committed revision 1“

    Congratulations! You have made your first change to the repository.

    Now let’s create another folder:

    C:\> **svn mkdir svn://localhost/Projects**

    The password won’t be asked this time, because it’s cached for your user (Documents and settings\username\Application Data\Subversion\auth)

6) Install TortoiseSVN

  • TortoiseSVN is the best GUI interface to SVN
  • Don’t fool yourself - IDE plugins are not as good as TortoiseSVN - by using a plugin you don’t really understand what is going on on your repository
  • Download TortoiseSVN at http://tortoisesvn.net/downloads .
    (At the time of this post it is TortoiseSVN-1.4.3.8645-win32-svn-1.4.3.msi)
  • Run it (install).

7) Learn how Subversion works

  • Open Windows Explorer. Create a local working folder C:\SVN.WORK . This will be our folder for all projects.
  • Inside that folder, right click into any blank area, and select SVN checkout:
    • Url of repository: svn://localhost
    • Checkout directory: C:\SVN.WORK
  • Press OK, and both folders Products and Projects will be copied to our C:\SVN.WORK
  • If your explorer is configured to show hidden files and folders, you will see that inside each folder (top level C:\SVN.WORK and subfolders Products and Projects) there is a .SVN folder. It contains information of where these folder is binded to (in Subversion server repository).
    Note that in SourceSafe the server folder has a mapping to the user-folder (where the files were checked-out, or to the configured working folder), and in Subversion it is the local folder which has a mapping to the server folder.
  • Please note that when a folder has a .SVN subfolder, it is displayed with a different icon image, indicating that it is under version control. These icons tell you the status (up-to-date/old/etc) of each file/folder.
  • Go to C:\SVN.WORK\Products and create a file README.TXT containing
    “This folder will host my company’s products.”
    Now right-click in any blank area again (of C:\SVN.WORK\Products) and select SVN COMMIT.
    Check our created file, and click OK. Now your file is under version control.
  • Go up one level to C:\SVN.WORK and delete all folders/files, except hidden folder .SVN
    Right click and select SVN update. It will download again all subfolders Products, Projects, and file README.TXT.
  • Go again to any blank area of windows explorer, right click and select Tortoise SVN - Repo Browser. It’s a repository browser (a visual client to SVN).
    You can select svn://localhost at URL, and navigate tree folders expanding /Products, until you see README.TXT
    Right click it and see many options you have, from viewing file, copying it somewhere else, or just review file history.

8) If you use Visual Studio .NET, download AnkhSVN at http://ankhsvn.tigris.org/

(At the time of this post, last version is AnkhSetup-1.0.1.2736-Final.msi)
Run it (install).

9) And we’re done!

You now have a networked Subversion server and client set up on your machine. Note that the default port for svnserve is 3690.

In your client-machines, which will access your Subversion server as a client, you need only to install TortoiseSVN (and maybe AnkhSVN), and you should be able to connect to your repository using svn://COMPUTERNAME/

Enjoy.

Nice links:
http://subversion.tigris.org/
http://tortoisesvn.net/
http://www.jmpj.net/jason/index.cfm?mode=entry&entry=2DD75CA7-CF1D-76B8-A64D9AC181C41D07
http://subversion.open.collab.net/articles/svnserve-service.htm
http://tortoisesvn.net/docs/release/TortoiseSVN_en/tsvn-serversetup-svnserve.html
http://www.excastle.com/blog/archive/2005/05/31/1048.aspx

PS: If your company needs professional help on migrating to Subversion, get in contact.

on cobol

As I promissed in a previous post, I will now give you an example of some C code in the mainframe, and mainly how to call from Cobol to C and deal with Cobol copybooks inside C.

First of all, a description of my environment:

  • AD/Cycle C/370 V1R2 (note it’s old - released in 1994 - there are new versions)
  • MVS (3.9 if I remember correctly)
  • VS COBOL II (3.2 I guess)

Generally speaking, every MVS or z/OS should have a C compiler. If it doesn’t, there are some free GCC ports to the mainframe ( SPFTOOLS, GCCESA). Since C has a long padronization history, there shouldn’t be many differences about code from my versions to yours.

Let’s begin with a simple example:

#include 
#include 
#pragma linkage(my_entrypoint, COBOL)
 
/* The linkage directive explains that my_entrypoint will be callable by a COBOL module */
 
/* prototypes */
void func1(char* ent);
void func2(char* ent);
 
/**********************************************
 Main entry-point
**********************************************/
void my_entrypoint(char* ent) {
 int func;
 func = *((int*)(ent+0));
 
 switch(func) {
 case 1:
 func1(ent);
 break;
 case 2:
 func2(ent);
 break;
 default:
 break;
 }
 return;
}
 
void func1(char *ent) {
 *((double*)(ent+12)) = log(*((double*)(ent+4)));
}
 
void func2(char *ent) {
 *((double*)(ent+12)) = log10(*((double*)(ent+4)));
}
 
 
/* End. */

Explanation: my_entrypoint is the only entry-point public to COBOL. It receives a cobol copybook (which in general words is just a byte buffer), and reads an int (see the pointer typecasting) from the byte buffer in the first position (offset 0). That int indicates what type of function (method) the C module should perform. Then, acording to this indicator, we call the apropriate method passing the same byte buffer we received.

Note that the copybook from cobol comes as a by-reference parameter (pointer to char array).

Then, each of our methods work reading and writing variables in the bytebuffer (char array). Note that both of my methods are reading a double from offset 4 (which is right after our int indicator), and writing a double to offset 8 (which is right after the double we have just read).

This method, using offsets, ensures us that we are dealing with the correct variable in the cobol copybook. Other methods rely on the byte-alignment that the compiler does, and suggest you to use directives to force the byte-alignment, then tell you to map each cobol copybook field to a c parameter inside a struct (then you would receive a pointer to that struct). I don’t like that method, and didn’t have a good experience with it either.

In that example, our cobol call should use a copybook like this:

01 BOOK-LN.
 03 FILLER PIC S9(9) COMP VALUE 1.
 03 LN-INPUT COMP-2 .
 03 LN-OUTPUT COMP-2 .

And the dynamic-call (with the module name declared in the working section) should be:

MOVE input TO LN-INPUT
CALL modulename USING BOOK-LN

And the result would be in LN-OUTPUT field.

I’ll write some more tips in the next post.

Hope you enjoy.