My brother Alan (the same one doing Christmas gifts for orphans in Guatemala) now has his own blog at MSN Spaces: http://spaces.msn.com/members/alang/ -- cool! He also has his own photo site at www.photoartgallery.net, and I must admit, he's doing a great job. He's got some great pictures of Guatemala too, so go ahead and check it out.

Today I was in a chat with some members of the C# team. Usually, I can go on an on about how the product can be improved. But today, apart from some questions, I really couldn't think of anything great to ask. I use VS2005 all day for all my projects, and it is so much better than VS 7.

Things just rock, and as far as I know, all my major complaints have been fixed or will be fixed. This might not be true, and perhaps I throw a fit when Beta 2 drops :). But seeing that MS has done huge changes and 180s (i.e., C# E-n-C, data diagrams), I feel pretty confident that I'll be exceendingly pleased.

I came across this program, called “Hector Protector”, created by the NetSafe Programme of New Zealand. It's to “help keep kids safe online”. What does this program actually do? It puts an image of a dolphin on-screen. Kids who run into materials that frighten them should click the dolphin. At that point, a congratulations message and picture of a dolphin fill the screen, protecting the poor child. The idea is that kids can do this and then run and find their parents or teacher to help them with the bad things on the computer.

Are kids these days really so helpless that they need a bloody dedicated program just to hide a window? I've been using computers since before I can remember. I never needed a system to hide stuff from me. I was on BBSs since I was 8 or 9 or something. Hell, when I was 13, my friend and I ran a BBS, complete with an “elite” section of programs, images, etc. He even worked as a sysop for other places, checking out all uploads and adding descriptions. He didn't need a stupid program to keep him safe. Why is it that kids now have turned into (or people think they are) such wussies when it comes to computers and networks?

Also, what's wrong with “If you see something wrong, minimize the window and go get help.”? Are kids going into such a bloody panic they need a damn dolphin there to click on? They're so offended and frightened they can't hit the minimize button? Also seems like a missed opportunity to teach keyboard shortcuts (say, Win+D). Or, what's wrong with just standing up and going to get help?

I'm not against helping kids deal with things. But technology isn't the answer. That's what parents and teachers are there for. Providing crutches like this? Please.

And... what happens when kids stuble across bad animations of Hector doing things he shouldn't? Won't this confuse and scar kids even more? Or what happens if kids happen to stumble upon some dolphin + redhead footage? Just think how many kids' lives are been wrecked by trusting hector, only to find he scares them later!

MSN just released a beta of MSN Messenger 7. I got it ASAP, installed and rebooted. I was really hopeful that there'd be some nice new features. Instead, I found that the MSN folks decided to take all the lameness of Yahoo messenger, and up it a notch.

First, the actually cool stuff, to get it out of the way:
  More ink support. Now there are tabs when you send a message, switching between “Handwrite” and “Type”. I don't use ink, so not that cool. Can't find out how to disable it. So it just adds more clutter (a recurring theme), but when I get a tablet, I'm sure I'll love it.

  Message history. Here's an awesome feature. In fact, probably the coolest thing about the new client. When you start a new conversation, it shows you the last few lines of conversation. That'll save a lot of “oh damn, I closed the window” problems.

  Nudges. Actually, I don't know what this is. I THINK it's a way to make the window beep or move or something to draw people's attention. Has the possibility to be helpful, and unlike many other features, can be easily disabled.

OK, and that does it for the useful new features. Now, lets turn to all the load of crap they crammed into the new client:

  Winks. There's winks here and there. There's even a “My Winks” option, which sounds like some kind of gay porn thing. And what is this? Stupid animations that take over the window and annoy the heck out of everyone except 13-year-old girls. Fortunately, reception of them can be disabled. BUT, you still get a whole ~50 pixels devoted to this feature in every IM window. 

  More clutter. Almost every feature is now cluttered with junk. The emoticon window, for instance, now has a “What's Hot” section, featuring random sets of ugly icons. “Packs”. Now, in EVERY IM window, you have another ~50px devoted to downloading new packs of backgrounds, display pictures and icons. This should be in the options or main window, not each conversation window. A “Click here to customize MSN Messenger” link that takes you to an MSN page, and again, something that belongs inside the main window, not each conversation. Sigh. “Get over it, you don't need to use those things!“ people might say. That's not the point. Up until now, MSN Messenger was a clean, slick, useful tool. Now the UI is busy with all sorts of junk. It's visually annoying.

  “Billing Information”. At first I got scared, thinking everything was going to be charged. But it doesn't seem that way. Instead, you have Blue Mountain (the people who sued MS over Outlook Express's Junk Mail feature and got it removed from the product), selling you... you guessed it: More useless icons and pictures for MSN Messenger. Wow! As if the free stuff wasn't craptastic enough, now you get the pleasure of paying for lame icons.

Finally, all the usefull stuff they still haven't done:

 Sign in with status. You still can't sign in as away or so on.

 Status for group or contact. AFAIK, there's no way to appear as Offline or Away to a certain group, while Online to others. 

 Search history. Self explanatory.

So, I guess in MSN (which is at least as strange as marketing divisions), features that appealed to 13-year-olds, infants, and lemmings, were rated as more important than improveing usability or usefulness of the product. The only excuse I see is “MSN Messenger is for l4m3rz and for serious people you should get Istanbul and LCS and whatever integration product MS sees fit.” I suppose you get what you pay for. I hope Microsoft aquires MSN and fixes their products.

Anyways, I'm going to uninstall this thing now. I just hope they don't try a protocol switch and forced upgrade anytime soon.

Security sells quite now, and lots of companies like to cash in by making up fake security threats, and then selling a “solution“. One such company is the “Internet Security Foundation“ which is just a clever marketing name for “Some Lame Company Trying to Sell Free Tools“.

When you goto the site (InternetSecurityFoundation.org), they make a big deal and a fake security alert from Sept. 2004 that you can see the text in a textbox, even if Windows renders it as asterisks. Anyone who programs understands this. These people pretend it's some kind of new threat and that terrorists are using it over the Internet to rob bank acounts. What a load of crap!

Why do they do this? They want to sell you “SeePassword“ (SeePassword.com), a $20 utility to do the same thing as the free Glow Password Recovery Util (download: Glow.exe (14.5 KB)) -- or similar programs, which have been around for YEARS.

The REAL issue lies in each individual program passing around passwords in plaintext. If a password is sitting in a user's memory space, in plain text, then why is it a surprise that it can be seen? Oh wait, it's not a surprise. This company is just using security for marketing.

Oh, and interesting info on their domain name registration. Perhaps I shall give them a call.

Registrant:
   KMGI Corp.
   119 72 St., 339
   New York, New York 10023
   United States

   Registered through: GoDaddy.com (http://www.godaddy.com)
   Domain Name: INTERNETSECURITYFOUNDATION.ORG
      Created on: 29-Oct-04
      Expires on: 29-Oct-05
      Last Updated on: 29-Oct-04

   Administrative Contact:
      Corp., KMGI  ak@kmgi.com
      119 72 St., 339
      New York, New York 10023
      United States
      17032427114      Fax -- 12122024982
   Technical Contact:
      Corp., KMGI  ak@kmgi.com
      119 72 St., 339
      New York, New York 10023
      United States
      17032427114      Fax -- 12122024982

   Domain servers in listed order:
      NS2.KMGI.BIZ
      NS3.KMGI.BIZ

Edit: Fix .com to .org (Although both appeared to be registered by the same thing).

Well, today Convergence (Cybernet) in Guatemala installed my cable line. They use a REALLY OLD Zenith modem. At first, they could not configure it, since it requires, get this, a Win3.0 program (ZUDUSR.EXE) to configure. Plus, they have to connect via serial using this old Win16 program. So, they had to go out somewhere else, configure the box, and bring it here.

Well, they assigned me this IP: 192.10.18.76, telling me it was a public IP with no filters at all. It struck me odd they'd have a class B assigned to them, especially 192.10.0.0/16. So, I called support.

He tells me, “Oh, you have a private IP.” I said that 192.10.18.76 was not private and actually fully routable. He disagrees and says that 192.* is private. I'm sure people who own other IPs in that netblock would be surprised to hear this.

So, it turns out Convergence is using else's (Symbolics, Inc.) netblock for now reason, other than that they are clueless. He says it's perfectly correct to route like this. I think ARIN and IANA might beg to differ. So I'm going to send him to ARIN's whois, so he can see for himself that he's 100% incorrect. My past experience with Convergence / Cybernet was pretty much the same: utterly clueless people for the most part.

Oh, and they filter ICMP, for reasons unknown. My guess is to prevent customers from easily seeing how bad their lag / packet loss is. Sigh... why is so hard to find people here who know what they're doing? As if basic TCP/IP routing was so incredibly difficult...

The coolest thing about this new Whidbey exception model is that the IDE actually throws exceptions *about your code* at design-time instead of runtime.

Isn't this fun? I ordered ADSL from Telgua (Turbonett -- their marketing people are morons, yes) at a price of $229 a month for 512k. Ridiculous. Even more crazy is that now, 2 months later, they haven't installed the service. Also, since Telgua moves your phone line over to the Turbonett people, now my phone line doesn't work either. Every call to them, including talking to manager ends with some silly statement about how the technical people don't have phones, so you can't call them. I asked the guy if I should just cancel my phone and switch companies and he said “yea, you're right.” I'm supposedly getting some cable Internet today, so we'll see how that works out.

Intro
It's been a while since I wrote anything that interesting, so I figured for Thanksgiving, I'd go ahead and do so. Merry Thanksgiving. The first article in this “series“ is here.

Cracking .NET programs can be just like cracking any other program. In this article, I'm going to use the same approach as I did last time. I threw together a quick little program called CrackMe2. CrackMe2 has a really cool feature called “Reverse Text”, however, it's only available to registered users. What's a poor boy to do?

Target
First, we try registering. Since we don't have a valid code (we don't even know what one looks like), we get an “Invalid serial.“ MessageBox. OK, so now we know that the program does something when we click a button, and if the serial is wrong, we get a MessageBox.


Darn, 123 didn't work.

Well, the first step in cracking is defining our target and it's location. Our target is the code that's deciding to say “Invalid serial.” instead of “You're registered!”. Where's the “bad code“ that needs to be fixed? Well, with a .NET assembly, our first information is gained by taking a look with IL DASM.


View of the obfuscated CrackMe2 assembly

Oh no! It's obfuscated (thanks to Ivan Medvedev's Mangler). Let's assume this is a big application and that we'll never find what we're looking for just by going through the IL. Just by glancing at the hierarchy, we don't know that much more than when we started: There's a form with code.

Seeing past the names
Now certainly, we can do static analysis and try to find out where the bad code is. One way would be by getting the strings (Ctrl+M in IL DASM, scroll to the bottom), and then grep the IL for ldstr , and work from there. In fact, that's a pretty quick and easy way to locate certain parts. However, lets pretend the strings are encrypted/dynamically generated, and that's not viable. So, let's start debugging.

[Michael@MAO C:\]$ cordbg CrackMe2.exe
Microsoft (R) Common Language Runtime Test Debugger Shell Version 1.1.4322.573
Copyright (C) Microsoft Corporation 1998-2002. All rights reserved.

(cordbg) run CrackMe2.exe
Process 4488/0x1188 created.
Warning: couldn't load symbols for c:\windows\microsoft.net\framework\v1.1.4322\mscorlib.dll
[thread 0x1510] Thread created.
Warning: couldn't load symbols for C:\CrackMe2.exe
Warning: couldn't load symbols for c:\windows\assembly\gac\system.windows.forms\1.0.5000.0__b77a5c561934e089\system.windows.forms.dll
Warning: couldn't load symbols for c:\windows\assembly\gac\system\1.0.5000.0__b77a5c561934e089\system.dll

[0004] mov         ecx,98543Ch
(cordbg)

cordbg is a command line debugger that ships with the .NET Framework SDK, and it's just loaded the CrackMe2.exe and related assemblies. Just like before, we're going to go ahead and set a breakpoint and find out where we are in the program, and work from there. So, let's breakpoint the MessageBox.Show function. We use IL-similar syntax to specify the function name: NameSpace.ClassName::Method.

(cordbg) b System.Windows.Forms.MessageBox::Show
Breakpoint #1 has bound to c:\windows\assembly\gac\system.windows.forms\1.0.5000.0__b77a5c561934e089\system.windows.forms.dll.
#1      c:\windows\assembly\gac\system.windows.forms\1.0.5000.0__b77a5c561934e089\system.windows.forms.dll!System.Windows.Forms.MessageBox::Show:0      Show+0x0(native) [active]
(cordbg)

Then, we tell cordbg to go until it breaks by typing go. The form comes up, and we enter a serial number: 123.

(cordbg) go
Warning: couldn't load symbols for c:\windows\assembly\gac\system.drawing\1.0.5000.0__b03f5f7f11d50a3a\system.drawing.dll
break at #1     c:\windows\assembly\gac\system.windows.forms\1.0.5000.0__b77a5c561934e089\system.windows.forms.dll!System.Windows.Forms.MessageBox::Show:0      Show+0x0(native) [active]
Source not available when in the prolog of a function(offset 0x0)

[0000] push        edi
(cordbg)

Bingo, we're stopped at a MessageBox. We want to know who called this function, since most likely, that will lead us to the critical code section we need to fix. So, we ask cordbg where are we?

(cordbg) where
Thread 0x1510 Current State:Normal
0)* system.windows.forms!System.Windows.Forms.MessageBox::Show +0000 [no source information available]
                owner=(0x00ac36b0)
                text=(0x00ad5854) "Invalid serial."
1)  CrackMe2!CrackMe2.Form1::AAAAAAAAAAAAAAAAAAAA +0070 [no source information available]
                AAAAAA=(0x00ac8400)
                A=(0x00aca86c)
2)  system.windows.forms!System.Windows.Forms.Control::OnClick +005e [no source information available]
                e=(0x00aca86c)

9)  system.windows.forms!ControlNativeWindow::OnMessage +0013 [no source information available]
                m=(0x0012ef04)
--- Managed transition ---

We see what's expected. Somewhere in Win32 code, a message was sent, and we see the OnMessage called and bubbling up all the way to the Control::OnClick, and then user code. We can look at all the arguments along the way, and that's useful for more complex scenarios (say, when a registration function calls another passing the serial number or validation code).

At any rate, we've got something to go on: The name of the function that calls the MessageBox: CrackMe2.Form1::AAAAAAAAAAAAAAAAAAAA (20 A's). We're done with cordbg (quit). Our next stop is to read the bad code.

Looking at the bad code
Using IL DASM (see above), I navigate to the CrackMe2.Form1::AAAAAAAAAAAAAAAAAAAA method. Inside is relatively straighforward code. First, there's a try/catch that has an Int32::Parse call in it. The result is stored in local 0. So we now know the code is numeric. Immediately after the catch handler, we have this snippet:
  IL_0022:  ldloc.0
  IL_0023:  ldc.i4.1
  IL_0024:  and
  IL_0025:  ldc.i4.1
  IL_0026:  bne.un.s   IL_0035
  IL_0028:  ldarg.0
  IL_0029:  ldstr      "Invalid serial."
  IL_002e:  call       valuetype [System.Windows.Forms]System.Windows.Forms.DialogResult [System.Windows.Forms]System.Windows.Forms.MessageBox::Show(class [System.Windows.Forms]System.Windows.Forms.IWin32Window, string)

Load the local (the number entered), then load the number 1, and AND them. Then, load one, and if they are not equal, jump to IL_0035. If they are equal, execute the following instructions, which quite obviously say “Invalid serial.”. AND'ing a number with 1 and comparing to 1 is a check to see if the number is odd. So, at this point, we can write a keygenerator that produces... even numbers. A keygenerator is always preferred to a patch, however, generally speaking, finding the algorithm might be a bit harder. Then, there's always the possibility that the check actually does something hard to fake (i.e., uses RSA or talks to a hardware dongle/web service). So, let's go on and patch this code.

At IL_0035 (the target of the branch if the number is even), we have some code that does activation work and then proceeds to say “Thank you...”. Simple sample. Now, let's make the fix.

Simple Patching
With IL DASM and IL ASM, we have a really easy way to make patches. Simply run ildasm /out=CrackMe2.il CrackMe2.exe, and IL DASM will dump all the IL required for that assembly to a nicely formatted file. All we have to do is goto the bad method and fix up the IL. I think the most unintrusive fix would be to add “br IL_0035” to the top of the method. That would branch immediately to the good code, and the product would activate on any serial number entered.

However, some obfuscators try to stop IL DASM round tripping, and that might stop some posers in their tracks. The IL obfuscator I'm going to give away for free will do this, for example. (Actually, my free obfuscator would make this tutorial a bit harder because of how it handles names -- we'd have to actually get a token instead.)

Assuming we can't use IL DASM/ASM, what can we do? Use a hex editor.

Binary Patching
When we can't reassemble an entire program, we can patch certain opcodes instead. Tools like OllyDbg have a built-in assembler so we can easily make patches to the x86 code. For IL, I'm not aware of any such tool. Another issue with binary patching IL is that we have to ensure the resulting IL is fully correct and is able to be JIT'd to native code. If our patch ends up screwing with the IL in a way that makes it incorrect, we'll get a runtime exception from the execution engine. Let's try to create a binary patch that jumps from the beginning of the method right to the good code, at IL offset 0x0035.

First, in IL DASM, turn on “Show bytes”, under the View menu. This allows us to see the actual bytes that make up the opcodes. Now, lets look at the beginning of the critical function:

  // Method begins at RVA 0x2434
  // Code size       78 (0x4e)
  .maxstack  2
  .locals init (int32 V_0)
  .try
  {
    IL_0000:  /* 02   |                  */ ldarg.0
    IL_0001:  /* 7B   | (04)000002       */ ldfld      class [System.Windows.Forms]System.Windows.Forms.TextBox CrackMe2.Form1::AAAAAAAAAAAA
    IL_0006:  /* 6F   | (0A)000026       */ callvirt   instance string [System.Windows.Forms]System.Windows.Forms.Control::get_Text()
    IL_000b:  /* 28   | (0A)000027       */ call       int32 [mscorlib]System.Int32::Parse(string)
    IL_0010:  /* 0A   |                  */ stloc.0
    IL_0011:  /* DE   | 0F               */ leave.s    IL_0022
  }  // end .try

This code is protected in a try block. We could go and remove the try block, but that's modifying more code. Generally speaking, we should aim to patch as little code as possible to ensure we don't accidentally screw something up. So, we're going to deal with the try block and fix it from within. The ECMA specifications for .NET will come in handy here. Specifically, Partition III, CIL. This can be found in the .NET Framework SDK folder, under “Tool Developers Guide\docs”. It's also available from MSDN, here.

The first instinct is to say, hey, let's change IL_0000 to a br to IL_0035, and NOP out the remainder of the try block. However, that'd create illegal code, since you can't branch out from a try block, you must use the leave opcode instead. So, let's rewrite the method to simply leave to IL_0035. Here's the description of the leave opcode:

The leave instruction unconditionally transfers control to target. Target is represented as a signed offset (4 bytes for leave, 1 byte for leave.s) from the beginning of the instruction following the current instruction.

The formats (in hex) are DD <4 bytes> for leave and DE <1 byte> (as shown above), for leave.s. We'll use leave.s, just to be efficient :). Since the total size for leave.s is 2 bytes, we calculate the offset to 0x35 from 0x02 (since our leave instruction is at 0x00). Subtraction tells us we must have an offset of 0x33. Hence, our leave instruction in hex looks like: DE 33. Since that'd leave the IL in an incorrect state, we must nop out the rest of the try block. The hex for nop is 00.

Open the assembly in your favorite hex editor, and let's find the method. IL DASM gives us the RVA, but for now we'll just search for a specific byte sequence. The IL DASM Show bytes allows us to easily find our place. Do note that the way tokens are displayed ((04)000002, for example), is reverse from how they are stored. Depending on the size of the app, you might need to search on quite a large number of bytes, since IL sequences are most likely repeated. For this case, we're going to search on the last bit: “0A DE 0F”. No other matches found, so this is the one.

As when programming, in cracking we have many ways to solve a problem. Many of them can be considered “right”. We could make a simple one-byte patch by allowing any number as a valid serial. This has the merit of ensuring the local int is assigned, and well, being only a one-byte edit. The leave.s opcode is at offset 0x11, so add 2 to that amount and we get 0x13. 0x35 - 0x13 = 0x22. So by changing “0F” to “22”, we'd have our crack. However, let's stick to the original plan and jump right to the good bits from the beginning.

In the hex editor, we back up a bit until we find the 02 7B 02 00 00 04 part (ldarg.0, then load the textbox field). At the 02, we drop our leave.s IL_0035 payload, which is DE 33. Then, we nop out (00) everything until the end of the 0A DE 0F part. The resulting hex for the try block is thus: DE 33 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00. Save the file as CrackMe2.cracked.exe.

Satisfaction
Run the program. Type in anything for the serial. “Thank you for registering.” The second textbox activates. We've won access to the coveted “Reverse Text” function. Write up an .NFO, ensuring to remind people to purchase software to support the authors. Then kick back and play a game of KSpaceDuel.

Download the program itself (Right click and save as, since it's a .NET assembly and IEExec will try to run it otherwise): CrackMe2.exe (24 KB). Or, download the source: CrackMe2.cs.txt (4.81 KB).

Was this post interesting, helpful, stupid, or lame? Leave a comment and help me improve.

Mr. F. Morales left an interesting [read: lame] comment on my post about MPAA/security stupidity down here in Guatemala (at the Miraflores / Cinepolis mall). The mall *banned* all cameras and recording equipment, and actually goes around enforcing this. (Although, this isn't any different than Disney does these days in the states.) Basically, he swears at me and tells me to put up with stupidity or get out of the country. I replied to him already, so we'll leave that alone.

What he did remind me of was a time I met another overzealous "Defender of the Republic". I was once driving home, only to find that some people had decided to park all over the road, completely blocking it off. They were all inside some little party; they weren't even thinking of moving their cars. We waited a few minutes.

Then I got out and found whoever was around there and asked them why they were such morons by parking their vehicles there, and if I should move them or if they were going to take care of it. I got a long flaming response about how I shouldn't insult people just cause they're from another country and things aren't as good as they are in the USA.

I started choking from laughter. I nicely explained to the person that being an idiot is a trans-gender, trans-racial, and international designation. I don't care if this guy is from Guatemala, Canada, Zimbabwe or Manchuria. If you park your car in the road blocking me from getting home without any reason besides laziness, I'll yell at you. Some people are so insecure or sensitive about their <whatever> (be it their OS, database engine (MySQL anyone? :)), religion, or country). Sometimes, just *sometimes*, it helps to think a bit before you get annoyed about a particular bit of criticism.

I chose to expose cli.h, since it's very simple :). My code generator is now debugged enough to generate all the things required for the ManagedAsterisk and ast_mono runtime to compile and allow access to a specific .h. Even the simple cli.h, which is only 92 lines long, requires about 500 lines of output (C and C#) to be fully wiredup (of course, this counts spacing and open/close braces).  

Anyways, a bit of tweaking the generated code (and applying the fixes to the generator), it now compiles just fine without any warnings or errors. Yey.

As mentioned before, one of the challenges of ast_mono is creating a “.NET-like” library, when the underlying code is all C. Since there's no real grouping in the C API other than which functions are in a certain header file, I don't have much to go on. Here's a sample of the current thinking for the managed API:

ManagedAsterisk.Core.Cli
  Contains the cli.h constants implemented as public static readonly fields. The value is loaded in the .cctor via an internalcall that returns the constant. This was done so that if a C constant is changed later on, recompiling the ast_mono runtime will provide the new value to managed code, without any changes.
  Also contains “static” functions, such as ast_cli_command, however, renamed to Command (ManagedAsterisk.Core.Cli.Command).

ManagedAsterisk.Core.Cli.Native
  This contains all the internalcall declarations to call the runtime wrapper methods. For now, access is public to all the functions, such as ast_cli_command, ast_cli_register and so on. Field accessors (see next) and constant accessors are not accessible and must be accessed thru the respective classes. I'm not completely sure on making this public, and might mark it internal instead (unless there's a good reason that it needs to be public).

ManagedAsterisk.Core.CliEntry
  This class is the managed version of struct ast_cli_entry. All the data is kept in unmanaged memory, and only a pointer is kept in managed memory, using internalcalls to access fields. It's constructed via new (heap allocated), or it's constructed by passing a pointer. It has a manual free (IDisposable) method, but it's *not* finalizable. This is because it's quite possible that the managed reference will go out of scope while on the unmanaged side it might be still in use. Automatic finalization (And hence a free) of it could easily cause Asterisk to segfault. Do note that improper usage could lead to a memory leak, although in most cases.

  The fields, (char* usage, struct ast_cli_entry *next;, int inuse) are all available as standard class properties. They are renamed to reflect that (public string Usage{ get; set; }, etc.). Methods that take a struct ast_cli_entry* will take a CliEntry class instead.

ManagedAsterisk.Core.CliEntry.Native
  Private implementation details to get/set the data (something like ast_mono_wrapper_ast_cli_entry_set_usage). Internalcalls set/get values, as well as enforce data limits (such as array bounds -- no need to worry about buffer overflows). No plans to make publically exposed.

---
For files like channel.h, where there is a lot of both static and “instance” methods, things will be put into one class, Core.Channel. There won't be a separate Core.ChannelMethods or Core.ChannelClass. The cli.h just happened to lend itself to this format.

Currently, the ast_mono code generator is in the final stage of taking the SWiG-generated XML and producing the various declarations and wireup code required to make everything work. This generated code will be heavily hand-edited before becoming part of the ast_mono/ManagedAsterisk platform.