Hi all,
exiting new tutorial from me .. I placed it here because it includes also a complete framework ... see the tut

Guide on How to play with processes memory, write loaders and Oraculums
Download at: http://tutorials.accessroot.com

This tutorial aim is to do a whole flight over loaders, memory patching and how to build them. Told this you might think that there’s nothing new in this, because there are several excellent tutorials (not that many anyway) already around, which already cover this argument, but the real final target of this tutorial is to teach how to write an “Oraculum”, and to write an Oraculum is impossible without first of all understanding all the things about loaders, processes and memory patching of applications.
At the same time reading this requires a little of knowledge of the C programming language. All the examples I provide have been written in C (and tested using Visual C++ 6.0), but I tried to leave things as much easy as possible.

I must admit that this is a really long tutorial, the longest I ever written, but I wanted to take by hand all the possible readers giving them also the path to understand all the concepts: it think that anyone can read it starting from the first to the last page. Of course those of you alread expert in this can skip earlier pages!

Inside it you will find a complete description of the loader theory and a complete description of the framework I wrote to support others writing new oraculums. I also will present two oraculums for two real applications.

Do not forget to write comments to me or on the ARTeam's forum or here, also to help me improving the code .

Have phun!

For those wondering what an Oraculum is ... (it's in the pdf)

Oraculous - \O*rac"u*lous\, a. Oracular; of the nature of an oracle. [R.] ``Equivocations, or oraculous speeches.'' --Bacon. ``The oraculous seer.'' --Pope. -- O*rac\"u*lous*ly, adv. -- O*rac\"u*lous*ness, n.

Informatically speaking, an oraculum is a loader, an external program which executes the target program and does some memory patching in order to obtain some information such as usually the serial code, and then it reports those things to the user.

----
I think your spell checker didn't like the word SEH
"SHE - Structured Exception Handling"
"Using the SHE instead lead us ..."


-----
Thanks for sharing

oops damned word! fixed.. ;-)

Shub-nigurrath: Thanks for all your hard work. I've been to that site before and have read a couple of your other works. I just wanted to thank you here.

*Downloading*

Nice work...

I think the tutorial is a good job but i have one or two questions.

I make a tut of a loader debugger in 5 parts one month ago, and the idea is the same (we not discover the TNT jeje) but i think why your loader don´t debug the program?

Debugging the program you can put Breakpoints, Hardware Breakpoints, Breakpoints on memory access, on write, on execution etc, and the loader debugger, catch easy the exceptions produced by the debuggee and you can work more easy, quickly and more powerful, you can change registers, flags, memory, in the same form any ring3 debugger.

this is the unique point you need for put a breakpoint put a ebfe loop and look with the loader if the victim are looping for know if the EB FE was triggered, with a BP (CC) the loader debugger catch the excepcion perfectly.

And a debugger is only a loop, i think is more easy and powerful, but is only my opinion, maybe you have better reasons for make the loader not debugger and i´m wrong (very high possibility, i´m only a self teached in cracking and have hundred of errors jeje)

Is only for know and learn from other opinions sorry

Ricardo Narvaja

Hi Ricardo,
nice to see you, you are always welcomed!

I knew of your tutorial and I read it indeed before releasing this one: ThuderPwr/Powermos told to me that you were writing it...but I promise that I haven't copied/taken a single line from them

First of all the genesis of my tutorial was to introduce the Oraculum concept: I like to introduce new concepts and this was not still "defined" AFAIK. Then started writing the appetite come (you know) and I decided to write a more complete document.

Secondly, coming to your observations. My approach doesn't uses debugAPIs (or better doesn't use breakpoints because get/set thread context and read/write processmemory are indeed in the debug library) because several programs can detect if the program is being debugged, quite easily and in different ways, while they are not able (most of the times simply doesn't do it) to detect direct memory writing/reading (except for CRCs, but can be "skipped".

The concept I applied is "let the program run freely, normally and trap it trasparently"...the debugging APIs are a little more invasive.

I agree of course that the debug library is more powerfull, it exists for this specific purpose afterall, but IMHO the advantage of my approach is just in what I said above.

On the other hand the EBFE trick and the whole method is less powerful of the debugAPIs because you cannot easily do a lot of things, but most of the times what you only need is stopping at a specific point in the program, do some patches, read some values and continue to the next stop.
90% of the patches will fall into these actions..and the framework I released helps to manage these complications.

The work made for the QuickUnpack.dll, I released some time ago, based on an original code of FEUERRADER, uses essentially the whole set of debug APIs + online memory patching for the isDebugPresent API (like Ollydbg plugins does), but this time I preferred to do something different.

Of course anyone can find different situations where one approach is better than the other, there are no universal laws.

I would suggest anyone to consider both approaches, before create loaders for a specific victim..

I hope this answer to your comments.

Thanks again,
Shub-Nigurrath

i learn so much of your explanation, is perfect and your tute is great programming in VC++ or other langiuajes, and i´m learn by myself and my tut is very simple, writing directly in ollydbg but all contibutions help, do you know?

Again very good job

Ricardo Narvaja

Updated to version 1.1 both tutorial and framework.

Version 1.1 -
- added KillisDebuggerPresent which patches the isDebuggerPresent API with an example too
- accordingly updated the documentation

That is very NOT secure to show, how exactly change Kernel32 code,
so some heavy-stopid-prot then can check for that & f_out newbies PCs.
that is strictly PRIVATE thing, how patch or not patch system code..

I don't think so, this isdebugpresent patch is a normal well known from anybody patch, there are already plenty of tutorials around explaining how to do it manually with Olly. What the code does is exactly what you would do doing it in Olly. So I strongly disagree with you.

This is no more a secret. look the code of this method, it's a simple monkey-level code with no secrets at all inside.

the secrets are others IMHO and for those I haven't placed anything public.

i believe he is talking about you retn4 patch to OutputDebugString()
but not sure about it his ramblings are usually as cryptic as his crackmes
no offence Eval its just a joke

Good tutorial, this will probably help out a lot of those newbie unpacker authors that don't know where to start !

I've used that EBFE trick before in my arma unpackers, although I didn't know it had a "name"



-nt20

i not yet read tut.
i'm about changing Kernel32.dll code; that is bad;
if you mean changing byte in PEB, that is good;

blump, my ARcobat_reader4.05 won't open "Oraculum_..pdf";
& i won't install newer acrotba..;

What goods these guys found in PDF?

RTF is GREIT!!

well 5.0 is the minimum, there are also free opensource readers btw

ok, forget it;

Do you agree about: Changing Kernel code is bad?
(bcz can be yasy detected & kicked?)

"easy detected & kicked" by who: protection developers (like Chad & friends) or ppl at M$ or application developers?

by them, who want..

// you can't say, that you was not warned;
// why accept only working examples, if human can also theoretic??

bye-bye.