C:\Documents and Settings\SSlEvIN\My Documents\InstantDemo\Projects\INLINE_PATCHING_AM62.swf
Build successfully completed
Created at: Fri Nov 23 23:29:35 2007
Flash player required: v6.0 or above
Size: 6626 KB
Total frames in main movie: 24520
Playback frame rate: 20
Approximate playback time: 1226 seconds

Annotated text transcript:

This is the target for our tutorial. Choosed in the first place for its size (6MB) so easy to download and practice. You see the title and usual ActiveMark info about trial time left.
NOW, LETS GET TO SOME WORK !
1.MAKING A "STABLE" DUMP
Open our dumped file in Olly...
NOTE:
These NOP commands are left by Condzero's dumper tool. We need to assemble command 
MOV DWORD PTR DS:[xxxxxxxx], -1
xxxxxxxx should be replaced with DWORD  address where AM stores value for kernel32.GetTickCount API comparation in order to prevent code tampering. If we make  it always -1(FFFFFFFF hex), GetTickCount API (antidebug guardian) won't become suspicious. :-)))
Trace (F8)
Follow this memory address in dump ...
... and set a HWBP on write DWORD here.(ESP+4)
Run (F9) untill ...
...here.
Delete this breakpoint
Now, set HWBP on execution here and run
Follow this value in disassembler
Analyse code (Ctrl + A) or use Olly plugin Analyse this
Now, search for this command:
ADD ESP,4 or it's binary string equivalent
81 C4 04 00 00
Press Enter
83 C4 04 , nope, this is not it, press find next (Ctrl+L) untill ...
... here. See, 81 C4 04 00 00
JA (Jump if above)
JB (Jump if below)
But actually we are interested in this line. Copy it to clipboard or just write down value in brackets 007CF1AC (this is the DWORD we are looking for)
Paste to notepad (not shown)
Restart
Now select all NOP commands and press Space (Assemble)
Click assemble or press Enter
Copy assembled line to executable file and save under another name
Thats it, we've got our "stabilized" dump. Time to exit this Olly session.
2. FINDING TRIGGER API FUNCTIONS
Open our "stable" dump in Olly...
This part is the same as previous. We will find last line of LAYER 2 code (jump to LAYER 3), set a HWBP  there, run the application and continue search for elements necessary for inline patching.
Click hotspot to continue 
Copy this line to clipboard ...
... and paste here (not shown)
Follow this value in dissasembler
Search for all intermodular calls
Type the name of first trigger API we are looking for:
GetSystemTimeAsFileTime
We are interested only for calls from the program itself, not from dll's. When you find it copy to clipboard and paste to notepad. In the same manner you can find other two trigger API functions:
CreateThread and FindFirstFileA
(both are kernel32.functions)
Fourth trigger API 
WININET.HttpOpenRequestA
is used in advanced and superior method of inline patching ActiveMark6.2 can also be find this way. Finding API's other than
GetSystemTimeAsFileTime wont be shown here in order to shorten this movie.
Click hotspot to continue ...
Type "GetSystemTimeAsFileTime" on your keyboard (without quotes)
Copy this to clipboard ...
... and paste here (not shown)
Repeat this procedure for other three API functions (not shown)
Let's go back to our breakpoint (doubleclick LMB here)
3. EXPIRATION CHECK
Open (E)xecutable modules
View Names (Ctrl+N) in kernel32
Again, type GetSystemTimeAsFileTime
Follow Export, not Library in dissasembler (Press Enter)
Set HWBP on execution
Run (F9)
Execute till return
Step into (F7)
No this is not the one we are looking for, run app again
Repeat previous steps ...
... and, yes this is the one
Trace (F8) till this RETN, but previously remove HWBP on GetSystemTimeAsFileTime.
You won't need it any more
Now, set HWBP on execution on this RETN.
NOTE:
I like to call this "Just in case HWBP". :-)))
We need it only as a safe return point if we run into "Debugged program could not process the exception" error when searching for expiration TEST AL, AL check. 
This target has no such features, so I recommend you to refer to Condzero's "Dumping&Analysing ActiveMark6.2" paper tut for more info on this matter.
Click hotspot to continue  
Search for --> All commands -->TEST AL, AL
Set conditional log breakpoint on all commands found for condition AL==1
Log breakpoints set (labeled pink)
Now run application
If there is no "Debugged program could not process the exception"  error, like here's the case, you will break right onto our 
TEST AL, AL expiration check.
NOTE:
If you use HWBP on GetSystemTimeAsFileTime
this breakpoint is hit three times(four times if you dont), but I ll also show you a visual aid on when to stop pressing Run(F9) button. :-))) Just follow ahead.
Click hotspot to continue
Here is your visual aid on when to stop pressing Run (F9) button. :-)))
ERROR_ENNVAR_NOT_FOUND
(I suppose this means ENVironmentVARiable not found), but whatever it is, just stop here, remove HWBP on RETN we set before, then remove conditional log breakpoint and set HWBP on execution for this TEST AL, AL and also copy this line and paste to notepad.
Click hotspot to continue
Remove this HWBP
... paste to notepad (not shown)
Restart application ...
4. BROWSER'S TEST AL,AL CONDITION
After restarting, execute code till our visual aid :-)))
Now, search for all commands:
CALL DWORD PTR DS:[EAX+38]
Remember previous tut on AM6.1 ?
Set SWBP on all commands found
Run (F9)
And once again, visual aid can help you when to stop pressing Run (F9). As long as you see string "/content/info" in EBX register, press Run button. Just follow ...
... string still present, so run again ...
Peep !!! No more string in EBX, now trace (F8)
Here you can see browser's launch preparation ... "http://amlocalhost. etc. etc.
Continue tracing ...
Finally, here we are, browser's TEST AL, AL condition reached. Now repeat usual procedure: Set HWBP on execution, copy this line to notepad and restart application.
NOTE:
I find it very usefull to restart application after each inlining feature found in order to avoid UNKNOWN INTERNAL ERROR SCREEN described in Condzero's paper tut. It's a bit more work :-))) but it doesn't require bypassing it. If you restart app after every main feature found it simply never appears.
Click hotspot to continue ...  
paste here (not shown)
Restart ...
5. CHECKPOINT 
After restarting application, run it till our browser's HWBP hit
Find this line in stack and follow it in dissasembler. It's always the same ...
Set temporary HWBP on execution here, run application, and remove this HWBP immediately after it is hit.
Trace (F8)
Now search for command SUB ECX, 44
NOTE:
This command is characteristic for large case switch structure we just entered. When you find it analyse code (Ctrl+A) and you will  easily find Case "V" switch we are interested in (also described in Condzero's paper tut).
Then set HWBP on execution
for this Case "V"
Click hotspot to continue
See ? SUB ECX,44 --> Switch (cases 44..56)
Scroll down ...
Case "V" of switch !!!
Set HWBP on execution here and run untill browser screen appears ...
Application is running ...
Press Start Free Trial button
Case "V" HWBP reached again ...
Now run app just once more ...
Step into (F7)
Trace (F8)
This line is our Checkpoint. Remove HWBP on Case "V" and set it here.
Now copy contents of pane window to notepad and, you guess, restart application
6. GOODBOY/BADBOY CONDITION
After restarting, run application untill our Checkpoint HWBP reached
Do a search for binary string
1B C0 40 5E C2 04 00
These are last few opcodes of the routine mentioned in Condzero's tut which is not obfuscated, so, easy to find. I will select whole routine (green) for your reference later, but we are interested only in its RETN 4 command. See ahead why.
Whole routine selected ...
Set conditional SWBP here for condition: EAX==0&&EBX==1
Run (F9)
Step into (F7) on second hit of our conditional SWBP, then trace (F8)
This is TEST AL, AL for Goodboy/Badboy condition. Copy it to your notepad. This is the end of search for features necessary for inlining.  Restart application, remove all HWBP's except first one and you are ready to make inline patching of AM6.2
7. CREATING INLINE PATCH
Follow this HWBP
This is address of our codecave. It is located in Layer 1 .bss section. Find it using memory map (M- button) 
Assemble JMP 009EA000 here
Copy these two lines to executable file
Don't save anything just yet ...
Select this line and press Enter
Follow this line in dump then select "zeroes" from 009E9FFF further. This is because first command in inline template string (see later) is NOP (90) used only as a marker.
This is inline template string but from another application so its full of "junk". Still, you can copy then binary paste it in selected dump area.
See ? Jump to code cave we assembled earlier leads to first inline patch command PUSHAD at address 009EA000. Now, we should replace every "wrong" line of code with the correct one using data from "Analyze" notepad document. Follow ahead.
Next line should store value of EAX to this address 009E9FF0, so, replace 00A9FFF0
Value after the comma, 00AA001E, should be replaced too, in order to point to new address 009EA01E (PUSHAD)
Assemble this 00828014 ...
... here.
:-)))
Again, assemble 009E9FF0
Here goes address of our expiration
TEST AL, AL check
Here goes kernel32.CreateThread DWORD
I will stop here. I hope you've  got the basic idea about the whole thing. Next I will show how the finished inline patch look like.
Copy selected lines to executable file and save under different name. 
NOTE:
You can pause movie here to see finished patch
Exit this session , exit Olly, we are ready for testing patched application
8. TESTING PATCHED APPLICATION
Original file renamed to "virgin"
Patched file renamed to original
Now, famous question from ImpREC:
WILL IT WORK ?
:-)))
Sure, ... he, he ...

SURPRISED ANYONE ???
Where s the endnag screen, huh ???
IMPORTANT
Files included with this videotut are three notepad documents:

1. Code analyse of target for basic patching method (works for 98% targets)
2. Code analyse of target for advanced
patching method (targets with launcher)
3. Code analyse of target for superior patching method (works for all targets)

Click Hotspot to continue
BYE, BYE !!!
