Hi all

Is it possible to write a loader for .net application ? If yes please let me know how, I have only experiences with win32 asm. I'm able to patch a .net app with reflector and plug in reflexil, but I want a loader. THX
hagen

Yes it is possible.
You learn how.

could you be please more specific, or give me at least hint.
I've got no idea how to write such a thing for .net

This is the code of loader I'm using for normal win32 apps


My problem is that I don't know what address I should use. IDA is not showing addres where I am. I'm totaly new in .not reversing

Thank you in advance

You should be able to get the addresses the same way you did before on a regular PE file.

The graphical view doesn't display the addresses by default.
Either get out of the graph view by pressing SpaceBar or add the addresses in the options menu.

TiGa

ill suggest you read the Execelent .net tutorials floating on the Forum ..to learn about .net .. if all you wanna do is Load a .net file...CreateProcess it

as for your Win32 loader...sure you read and write 2 address's ..but no idea what your trying todo..to Load a .net binary ...use CreateProcess..

Maybe we don't understand each other.
I want to write a loader that starts a dot net app and then in memory changes code. As far as I know in .net exe there aren't standard x86 instructions. There are some CIL instructions (or MSIL ?:thinking, which are at run time translated to local native instructions. I'm able to change this cil instruction to what I need and save file to the disk. But for some reasons I don't want to have modified dll saved on disk. That's why I want to have a loader that changes CIL instruction in memory after the program is loaded.

The code I posted before works for standard PE files. I don't know if it can be used for a changing .net cil instruction. Maybe no. I'll try it.
But the first problem I met is that I'm not able to locate cil instruction (to get addres of it) like in standard win32 pe file.

This is how it looks in IDA


Reflector also doesn't show addresses but something like this " L_0000:" which looks to be the offset of instruction in the current method.

I don't know what to do with it. Maybe this kind of loader, that changes cli, is not even possible.
Please help me
Hagen

browse this board a little bit..if you can patch a File manualy on Disk ..you can patch a file manualy in memory..

I did I also used google, but found nothing helpful. Please send me link or let me know how to do it

hagen: If you promise you will change your signature, I'll give you a hint:

In IDA place the cursor on the instruction(s) you want to patch.
if you switch to hex-view tab, the cursor will be in the corresponding byte in the raw hex equivalent. Look at the lower left corner of the tab and you will see the raw and virtual addresses of the byte in question. Worse case scenario or thinking that relocation may be an issue, use a pattern of 20 to 30 bytes around your target and search for the corresponding address within the program loaded in memory. There are ready-made loaders that can do that, but you may code your own, if it pleases you.

Here, as a proof of concept:
As a quick and dirty, I used the Dup2 patch and loader generator, available at the CRETL. So making a loader for a .NET application is quite feasible. I suggest you disassemble the loader and study the DUP 2 documents. Also, test other loader generators.

Hi naides,
Thank you very much for helping me. I also tried to use dup loader but not for crackme. I used it for my target app and it didn't work, so I assumed dup loader doesn't work. I think the problem is that I need to change code in dll not in exe file.

I tried it again and it works fine for exe. Then I have created crackme with dll and tried with no success. Sorry, my mistake I should post crackme with dll.
Please try to help me one more time.
Please try to change code in dll, for example ldc.i4.0(0x16) to ldc.i4.1(0x17)
Thank you very much


Hagen

1) really no difference between .dll and .exe
2) read up on .net datadirectory which is part of the PE
3) once you understand the above ..you should know how to patch file in memory

OK. This problem is a little more challenging. Because the .dll to patch only gets loaded "on the run" when you click the button,
and afterwards the MSIL gets compiled in memory. So even I found the bytes in memory and changed them (Using Olly) , patching the bytes in the MSIL is useless: At this moment of the game they were already read and compiled on the fly. . .
I faced this problem in the past and I found a workaround solution to it.

Hagen if you:
1) Promise to place no more Bible citations,

2) Give a more in depth explanation of what you are trying to do, We may be able to help you.

This is what I smell is happening: You know the .NET .dll you need to patch but when you patch it, it has strong signature attached to it, so the program refuses to load the patched version. Right????

No no, there isn't problem with signature. It works fine patched. But I want a loader. If you could please give me small tutorial how to find these translated msil instruction in mmory with olly i think it will help me.

Thank you

There are two methods for this hard work.

====================================================
Reaching to native code of a managed method using olly
====================================================

Target is "Simple.exe" and we are working on "Button1_Click" method.


1 - Get the Method RVA from CFF
2 - Convert method's RVA to VA using CFF address converter
3 - RVA = 0x00002850 so VA = 00402850
4 - but for olly we need the VA of the 1st IL, not of the method header
5 - So we need the final value is VA + 0xC = 0x0040285C
6 - Run olly and start the "Simple.exe"
7 - get the memory window "M"
8 - scroll down to "mscorjit"
9 - click on ".text" section n press enter
10- now ctrl + a (analyze)
11- now ctrl + n (names)
12- u see Export getJit ?
13- Double click it
14- 1st DWORD after the RETN is the pointer to compileMethod, ie first line After "RETN"
7907EA98 . F4E70679 DD mscorjit.7906E7F4
15- Press Ctrl+G and enter "7906E7F4"

7906E7F4 /. 55 PUSH EBP ; Enter CompileMethod
7906E7F5 |. 8BEC MOV EBP,ESP
7906E7F7 |. 83EC 10 SUB ESP,10
7906E7FA |. FF75 14 PUSH DWORD PTR SS:[EBP+14]
7906E7FD |. 8B45 10 MOV EAX,DWORD PTR SS:[EBP+10]
7906E800 |. 8B08 MOV ECX,DWORD PTR DS:[EAX]

16- coz we don't need that BP there now
17- instead we need a conditional BP on the 6th instruction

7906E800 |. 8B08 MOV ECX,DWORD PTR DS:[EAX]

18- setting it with shift F2
19- the condition is: [EAX+8]==VA of the 1st IL ==> [EAX+8]==0040285C
20- This will make olly break when "CompileMethod" compiles the method we are targeting
21- [EAX+8]==0040285C is the VA of the first IL in the method we want
22- should break now
23- now some steps with F8 until we reach the line before "LEAVE"

7906E83B |. 8911 MOV DWORD PTR DS:[ECX],EDX

24- Select this line and Press F4 when
25- jitted method is in EDX now !

=================================================

Or you can simply use the ILLY plugin developed by UFO-PU55Y from SnD
hxxp://www.tuts4you.com/forum/?showtopic=15806&pid=78373&st=0&#entry78373

Thank you Kurapica. This is the kind of detail I didn't have, because I have not dealt with .NET too often.

For Hagen, if you want to code a loader this is what I would do:
Find out a pattern of 10 to 20 bytes around the byte(s) you want to patch.
Code a loader that load the App main exe and hook the CompileMethod code.
Every time the method is called, Compare the bytes pointed by [EAX+8] during this instruction:

7906E800 |. 8B08 MOV ECX,DWORD PTR DS:[EAX]

If it contains your target MSIL code, patch it, else continue.

Now if and when your .dll gets loaded and your target code is GOING TO be JIT compiled, you will patch it on the fly.

NOW:

I wonder if coding a general generator for this concept of loader/code injector tool could be a general strategy to defeat Strong Signature as a method of .NET protection (Yes disavowed, I know you told me that Strong Signature was so not conceived as an anti-patching method but it is indeed used as such).

Would it slow things too much? (Doubt it, the JIT compiler only gets called once per method).

Could this be a mini Project??

A CompileMethod hooker would be fine, since like you said its only used once per method. No slowdown anticipated. I personally think the best way to handle this would what naides outlined in the post above. A general generator would be simple to code too... just I think it's only usefulness would be as poc.