New protector - Tejon Crypter from RDGMax [Archive]

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.