Log in

View Full Version : New protector - Tejon Crypter from RDGMax


NCR
March 16th, 2009, 14:09
Hi!, this is a new protector from RDGMax:

http://rdgsoft.8k.com/Tejon.html

Best Regards,
NCR

evlncrn8
March 17th, 2009, 06:35
buggy as hell,

1. it trashed my version information in my exe
2. it trashed my icon (yep the main icon, among others) in my exe
3. it doesnt even run with everything turned off (probably because of .6 below) (tested in xp64 sp2)
4. its visual basic (i know thats not a bug, but its one language a protection should NOT be coded in)
5. it doesn't calculate the image size in the exe correctly
6. it doesn't make the entrypoint section IMAGE_SCN_MEM_EXECUTE, so dep kicks its ass (it makes it IMAGE_SCN_MEM_READ + IMAGE_SCN_MEM_WRITE + IMAGE_SCN_CNT_INITIALIZED_DATA)
7. it doesn't update the PE checksum correctly
8. it left crap on my hdd (all the icons extracted from my test executable.. named z(*number*).ico

and probably many many many other points

NCR
March 17th, 2009, 07:53
ok!, thanks for the feedback, i will tell RDGMax about all this things!!!

evlncrn8
March 17th, 2009, 08:25
some more..

digital signature was still appended to the exe (when protecting an exe it will invalidate the digital signature anyway, so there is no point in keeping it)

its also dependant on msvbvm60.dll... which might not be present on all systems

it also rebases the executable.. bad idea especially if there is no reloc information, because any hard coded values in the executable wont work..
(eg: my exe base is 0x400000, when protected it suddenly becomes 0x01100000, so if any of my code had direct va accessing, jump tables or anything similar, its all broken)...

it also trashes the exports from my executable too...

protected calc.exe (x64) with ALL the options turned off, i run the protected exe, it sits there doing nothing 0% cpu, 88kb mem usage....
it magically turned it into an x32 process.. sigh

protected notepad.exe (x32) with ALL the options turned off, it silently exits...

trued protecting 'thisisshit.txt' (yep, a txt file), i get a messagebox with 'invalid pe header' (wow, it does do some checking), and then a dialog asking me to pick an exe to protect, i click cancel, and i get the messagebox again... and it loops here for ever.... invalid pe header->openfile dialog->invalid pe header->open file dialog (click cancel every time)....






think im going to give up on this

NCR
March 17th, 2009, 08:35
are you executing the protector in a VM environment or in your host machine?.

evlncrn8
March 17th, 2009, 08:45
host machine, which shouldn't matter anyway, the bugs i described are bugs, which are not os dependant, its a simple case of assuming things...

assuming changing the image base of the exe is ok << it is not... especially if you have no reloc information to work from
assuming the entire resource section can be protected... << it can not

protector runs fine, probably because it was compiled in visual basic and the base addresses match those of the protection stub

NCR
March 17th, 2009, 08:47
ok, actually, i sent an e-mail to rdgmax. i'm waiting for his response.

evlncrn8
March 17th, 2009, 09:15
some other bugs...

original executable PE information

Code:


Count of sections 11 │ Machine Intel386
Symbol table 00000000[00000000] │ Tue Mar 17 14:45:18 2009
Size of optional header 00E0 │ Magic optional header 010B
Linker version 7.10 │ OS version 4.00
Image version 0.00 │ Subsystem version 4.00
Entry point 00007B24 │ Size of code 0004E000
Size of init data 0010A000 │ Size of uninit data 00003000
Size of image 0015C000 │ Size of header 00001000
Base of code 00001000 │ Base of data 0004F000
Image base 00400000 │ Subsystem GUI
Section alignment 00001000 │ File alignment 00001000
Stack 00200000/00010000 │ Heap 00100000/00001000
Checksum 000EEA47 │ Number of dirs 16



Protected Executable PE information

Code:


Count of sections 2 │ Machine Intel386
Symbol table 00000000[00000000] │ Mon Mar 16 18:50:26 2009
Size of optional header 00E0 │ Magic optional header 010B
Linker version 6.01 │ OS version 4.00
Image version 1.00 │ Subsystem version 4.00
Entry point 0000138C │ Size of code 00000000
Size of init data 0002C000 │ Size of uninit data 00000000
Size of image 0002C204 │ Size of header 00001000
Base of code 00001000 │ Base of data 00001000
Image base 01100000 │ Subsystem GUI
Section alignment 00001000 │ File alignment 00001000
Stack 00100000/00001000 │ Heap 00100000/00001000
Checksum 0003C7A5 │ Number of dirs 16



Now, where shall we start....

how about the Size Of Image.. (windows uses this portion to allocate memory for the image...)

Unprotected : 0x15C000
Protected : 0x2C204 (not aligned.. it should be 0x2D000)

so, some maths... 0x15C000 - 0x2C204 = 0x12FDFC

yep, 0x12FDFC is MISSING!

Protected exe checksum : 0x3C7A5
it should be 0x11BE42

Unprotected ImageBase : 0x00400000
Protected ImageBase : 0x01100000

Unprotected Stack Settings : 00200000/00010000
Protected Stack Settings : 00100000/00001000

decreasing the stack settings can actually cause problems in the exe code (after the stub does its stuff)... increasing is fine....

Unprotected Base Of Data 0x4F000
Protected Base Of Data : 0x1000

actually from the comparisons there, you can see how many things are wrong.. oh and not to mention the 'time machine' effect
that when i protected the exe the time/date stamp went back by a day ;p

protected executable section information

Code:

Number Name VirtSize RVA PhysSize Offset Flag══
1 .data 000293D8 00001000 0011008E 00001000 C0000040
2 .rsrc 00001204 0002B000 000E508E 0002B000 40000040


unprotected executable directory information

Code:

Export 00054280 00000073
Import 00052540 000000C8
Resource 00110000 0004B0C0


(there are others, but these are the most important... lets forget about the Import one, because its not critical)

protected executable directory information


Code:

Export 00000000 00000000 << its gone!
Import 0002A1A4 00000028
Resource 0002B000 00001204


now, i can't test further, because the exe (when protected) doesn't even run (i wonder why)... but i would hazard a guess that there are even more problems if it even gets to run

NCR
March 17th, 2009, 09:27
you did a very good analysis!, once again!, thanks for the feedback!

evlncrn8
March 17th, 2009, 09:38
no problems, if it helps to make it better then im happy to do it
as for the analysis, well analysing pe files for stuff like this is part of my job (and hobby too)

NCR
March 17th, 2009, 19:46
Hello!, look at this little article about Tejon:

http://www.joebox.org/news.php#30

Look at the "04.02.09 An interesting crypter"

_wh_
March 18th, 2009, 02:44
@evlncrn8
you are doing QA for a little kid who likes to sell his "crypter" to malware authors .......

evlncrn8
March 18th, 2009, 05:14
actually, sadly, i had that feeling, though the good news is that using the 'crypter' on malware will probably result in the malware not working..

NCR
March 18th, 2009, 07:02
in my case, no, i'm insterested just in unpack things, i don't care what the packer is used for.

evaluator
March 18th, 2009, 07:11
~ : ) hey!
my suggestion: best rebased address is @13150000,

FrankRizzo
March 19th, 2009, 12:48
IMHO, let the VB crypter writing idiots flounder in their own pit of shitty coding, don't help them to produce something that might be used by malware (as someone said above). We can discuss it all we like, but don't tell the idiots what their problems are, or how to fix them.