Jump to content
Tuts 4 You

TitanScript


cypher

Recommended Posts

SmilingWolf

The findoprev command i cannot make works on original Olly plugin even i looked close at the description in the documentation. Is anyone who used this command in a script successfuly?

 

From the docs:

 

FINDOPPREV addr, what

-----------------

Searches code backwards starting at addr for an instruction that begins with the specified bytes.  

It sets the reserved $RESULT variable to the start of the found instruction. If $RESULT == 0 nothing was found.

The search string can also use the wildcard "??" (see below).

Example:

    FINDOPPREV, #68??????00# // find next PUSH 00xxxxxx backwards

 

But there is an error: the correct command is "findoprev eip, #55#" (with just one "p").

 

EDIT: Attached a working example.

ArmaHWIDReplace.txt

Edited by SmilingWolf (see edit history)
  • Like 1
Link to post
  • Replies 53
  • Created
  • Last Reply

Top Posters In This Topic

  • cypher

    19

  • mrexodia

    9

  • LCF-AT

    6

  • SmilingWolf

    6

Top Posters In This Topic

Popular Posts

For testing I created an automatic unpacker for MPRESS x64. Attached an unpackme + script + complete working environment. Screenshot: Greetings, Mr. eXoDia MPRESSx64Unpacker.rar

Hey folks,   here comes something not very new but polished up (DLL existed since 2009 but now its usable with the TitanEngine Community Edition)   What is TitanScript: TS is a plugin for t

redownload the GUI, I fixed a memory error but there was already 1 download, probably by you   concerning the script, I will have a look at it.   What do you mean by "not used the original Ol

Posted Images

mrexodia

Could you guys please test this one a random executable? Please post the log here.

My log:

--> mov eax,1--> log eaxeax: 00000001--> exec--> ende--> log eaxeax: 00000000--> pause--> mov eax,3--> log eaxeax: 00000003--> StopDebug--> ret--> mov eax,1--> log eaxeax: 00000001--> execDebugging stopped
Greetings,

Mr. eXoDia

x86.rar

  • Like 1
Link to post

Running script.txt against titanunittest.exe on Win7 x64 :


 


--> mov eax,1
--> log eax
eax: 00000001
--> exec
--> ende
--> log eax
eax: 00000000
--> pause
--> mov eax,3
--> log eax
eax: 00000003
--> StopDebug
--> ret
--> mov eax,1
--> log eax
eax: 00000001
--> exec
Debugging stopped

Edited by Loki (see edit history)
  • Like 1
Link to post

Against Enigma 4.0 packed executable on Win7 x64:



--> mov eax,1
--> log eax
eax: 00000001
--> exec
--> ende
--> log eax
eax: 00000000
--> pause
--> mov eax,3
--> log eax
eax: 00000003
--> StopDebug
--> ret
--> mov eax,1
--> log eax
eax: 00000001
--> exec
Debugging stopped
  • Like 1
Link to post
mrexodia

@Loki, @Softgate: thanks for the testing! exec/ende now seems to work (although LCF-AT still says it doesnt), but there is another bug now.. darn.

greetings

Link to post

Here is a script for unpacking fsg2.0



#log findop eip, #FF630C#
go $RESULT
sto
dnf
StopDebug

(Note: you need TitanEngine.dll from attached rar as older versions wont work and we havent added latest dll to download section yet)


TitanScript-fsg-test.rar

Link to post
LCF-AT

Hi,


 


ok so now I DL this...


https://forum.tuts4you.com/topic/34945-titanscript/page-2#entry161016


 


I tried this....



#log
var GMHA
var BASE
gpa "GetModuleHandleA", "kernel32.dll"
mov GMHA, $RESULT
exec
push 0
call {GMHA}
ende
mov BASE, eax
log BASE
ret

...log is



--> var GMHA
--> var BASE
--> gpa "GetModuleHandleA", "kernel32.dll"
--> mov GMHA, $RESULT
--> exec
--> ende
--> mov BASE, eax
--> log BASE
BASE: 01000000
--> ret

But also here the exe just starts.Also the same with other exsample scripts where I just log some values from register etc so why the exe just runs after this?



#log
mov eax,1
log eax
exec
xor eax,eax
ende
log eax
mov eax,3
log eax --> mov eax,1
--> log eax
eax: 00000001
--> exec
--> ende
--> log eax
eax: 00000000
--> mov eax,3
--> log eax
eax: 00000003 exe runs

Is still something wrong or do I something wrong etc?


 


greetz


Link to post
SmilingWolf

 

The "exec" bugfixed one should be the one posted by Mr. eXoDia here: https://forum.tuts4you.com/topic/34945-titanscript/page-2#entry161074

 

As a side note: on Win7 SP1 32bit if the script doesn't end with StopDebug (but there's a ret as last command) it will indefinitely loop. Is this intended?

 

EDIT:

this combo:

StopDebug

ret

makes the script run twice (at least that's what the log says);

ret

StopDebug

makes the script loop (StopDebug is never reached it seems);

StopDebug

makes the script run once and stop, as it should be;

ret

makes the script loop;

no ret and no StopDebug makes the executable start.

Edited by SmilingWolf (see edit history)
Link to post

"ret" command is behaving weird. until we fix that you should use StopDebug at the end of script to prevent exe from running.


 


@LCF-AT your exec tests seem to be correct now.


 


Next up: Could you test some more complex scripts ?


 


PS: oh and the latest-greatest TitanScript.dll should now be taken from here https://bitbucket.org/cypherpunk/titanscript-update/downloads its newer than the previous attached dlls , including exec and pause fix


Edited by cypher (see edit history)
Link to post

Fixed up some bugs with exec command that caused following BPs not to be hit. and some other things. Attached rar includes TS v004

 

attached is a working script for unpacking/dumping/auto-fixing Armadillo 8.60 + DebugBlocker. (no nanomites, no iat elim, no code-splicing. )

Tested on Win7 32bit & XP 32bit

 

This is more complex test and you should see how easy it is to fix up your own scripts to work with TS without the need to run them in Olly.

Uses EXEC/ENDE, BP, BPRM, CALL, EVAL...., and special commands PastePEHeader to paste original PE Header and DNF to dump + autofix. These two commands are the only things that were added. Without, this script is 100% the same as it runs in Olly

 

 

VA of security.dll: 00B01000
Code section VA: 01001000
Start of import redirection loop: 00B69657
push100: 00B69C6F
Junkthunks: 00B69CDD
ImportLoopEnd: 00B6A059
OEP VA: 0100739D
Z:\arma8.60-test.unpacked.exe
Dumping done!
IAT Start: 0x01001000
IAT Size: 0x344
Imports fixed!
Debugging stopped
 

TitanScript-arma_8.60_unpacker.rar

Edited by cypher (see edit history)
Link to post

Uploaded v005 on bitbucket.


 


RET command is now fixed.


 


(As of this release, all control-flow commands are working as they should and as they do in Olly: pause, ret, StopDebug, exec-ende )


Edited by cypher (see edit history)
Link to post
SmilingWolf

There are just two things which still prevent me from porting my Arma script to TitanScript:


 


- loadlib is unsupported (though this is no biggie, I can use LoadLibrary from a exec/ende block)


- either TitanEngine or TitanScript swallows all of my hardware breakpoints, on which I heavily rely


 


Thy OS is Win7 32bit. Whatever I can do to help you track down the problem with the hardware breakpoints I will do it :)


 


EDIT: you know what? I'll start by uploading the script :P


It is supposed to work under Olly with unpackmes from v4.30 to v9.64 with the standard plugins (Phantom -> change Olly caption + protect DRx, StrongOD -> HidePEB, !*PatchFloat, *KernelMode, !*Kill BadPE Bug, Anti Anti_Attach, and, most important (this is why I use run instead of erun), Skip Some Exeptions)


 


As soon as the hwbps works I'll work day and night to port this :D


Armascript.7z

Edited by SmilingWolf (see edit history)
Link to post

Here is Armadillo x64 unpack script. Something more complex with x64. Tested with real world target:   EZ CD Audio Converter Ultimate xxxx://www.poikosoft.com/download.html



VAR MutexName1
VAR MutexName2
VAR MovR8d
VAR JunkThunks VAR OpenMutexA
VAR CreateMutexA
VAR VirtualProtect
VAR LoadLibraryA GPA "OpenMutexA", "kernel32.dll"
MOV OpenMutexA, $RESULT
GPA "CreateMutexA", "kernel32.dll"
MOV CreateMutexA, $RESULT
GPA "VirtualProtect", "kernel32.dll"
MOV VirtualProtect, $RESULT
GPA "LoadLibraryA", "kernel32.dll"
MOV LoadLibraryA, $RESULT
GPA "CreateThread", "kernel32.dll"
MOV CreateThread, $RESULT BP OpenMutexA
ERUN
MOV MutexName1, r8
GSTR MutexName1
log $RESULT, "MUTEX 1: "
ERUN
BC OpenMutexA
MOV MutexName2, r8
GSTR MutexName2
log $RESULT, "MUTEX 2: " BP VirtualProtect
ERUN
BC VirtualProtect
LOG RCX, "Code start " //code address
LOG RDX, "Code size " //code size
BP LoadLibraryA
ERUN
BC LoadLibraryA
RTR
STI
RTR
STI FINDOP rip, #41B800010000# //mov r8d, 100
MOV MovR8d, $RESULT
LOG $RESULT, "mov r8d, 100: " FINDOP MovR8d, #488901# //mov qword ptr ds:[rcx], rax
MOV JunkThunks, $RESULT
LOG $RESULT, "Junkthunks: " //patch
MOV [MovR8d], #41B800000000# // mov r8d, 0
MOV [JunkThunks], #909090# // NOP NOP NOP RTR
mov rax, 1
LOG RAX
LOG "RAX must be set to 1!"
BP CreateThread
ERUN
BC CreateThread
RTR
STI
RTR
STI find RIP, #FFD0# //CALL RAX
BP $RESULT
inc $RESULT
find $RESULT, #FFD0#
bp $RESULT
ERUN
STI
LOG RIP, "OEP: "
MSG "Dump and fix IAT with Scylla" StopDebug
RET
Link to post

@SmilingWolf the problem with HWBPs lies within Armadillos ability to detect them if you dont have "protect DRx" enabled.


 


We are going to add DRx protection to TitanHide which works flawlessly as a drop-in plugin for anything using TitanEngine, just like TitanScript.


Link to post
SmilingWolf

@SmilingWolf the problem with HWBPs lies within Armadillos ability to detect them if you dont have "protect DRx" enabled.

 

We are going to add DRx protection to TitanHide which works flawlessly as a drop-in plugin for anything using TitanEngine, just like TitanScript.

 

Perfect!

In the meantime I've been reading through Ghandi's posts and found out that Arma clears the debug registers (just like you say) before executing the .adata section (source: https://forum.tuts4you.com/topic/29784-breakpoint-doesnt-work/#entry140397). I think that in the meantime I might work around this in some way... Guess I should have tested this on less problematic targets before claiming to have found a bug anyway, I'm sorry.

 

Right now I'm testing a PECompact script, I'll let you know if/how it works :) (rtu seems so have some problems [target simply runs it seems] but I'm going to test this on something simpler now :P)

Edited by SmilingWolf (see edit history)
Link to post

@SmilingWolf


Using hardware breakpoints with olly v1 is very unreliable. Because hardware breakpoints are thread specific. Olly v1 doesnt set the hardware breakpoints on every thread, so the breakpoints are useless for protectors who work with threads. Olly v2 changed this behaviour, because olly v2 sets hardware breakpoints on every thread. The best thing is still to avoid using hardware breakpoints.


Link to post
SmilingWolf

It will take a while to convert all of my hardware breakpoints into soft ones (though thanks to the fact I'm trying to port my script to TS it is now a hell of a lot faster (removed some dumbness) and relies only on Skip Some Exeptions (all the targets) and HidePEB (9.xx targets)).


 


In the meantime here is a fully working HWID replace script + test samples :)


This isn't permanent like LCF-AT's one though because it was meant as a test script to integrate later into the main one.


Arma HWID Replace.7z

Edited by SmilingWolf (see edit history)
Link to post

We updated TitanHide to support "Protect DRx" so HW BPs now work with TS and Armadillo targets ! and targets that use NtSetContextThread to defeat HW BPs


 


- Get https://bitbucket.org/mrexodia/titanhide/downloads/TitanHide_0011.rar


- Install TitanHide.sys and start it successfully


- Copy TitanHide.dll to plugins/x86/   just where TitanScript.dll is. That should enable all options TitanHide has. See c:\TitanHide.log


- Run your script with HW BPs


Edited by cypher (see edit history)
  • Like 1
Link to post

@cypher, ntsetcontexthread doest protect armas hwbps.

greeting

yeah you are right :( I was to eager when that hook worked and didnt test it properly on targets.

 

Combination of hooking KiUserExceptionDispatcher (user-mode) and NtContinue (kernel) should solve this finally I guess.

Link to post
mrexodia

I dont wanna hook anything for user-mode with TitanHide... There must be a way of hooking in the kernel.

Greetings

Link to post
  • 3 weeks later...

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now

×
×
  • Create New...