Hello there,

I was trying to unpack a program but i had no idea with what i am dealing...

peid did not detect anything.

can you tell what packer was used?

1. the PE file has overlay data
2. imported function names are hidden and only to be fetched through a sort of name_to_id(), example: MessageBox has an ID of 0x12211221 then to getproc_x MessageBox, a call is made as: getproc_x(0x12211221)
3. no real getproc or loadlibrary are used, instead the PE image is scanned and functions are fetched from there
4. the use of lots of SEH to: a. modify EIP b. clear debug registers
5. sha1 or a modified version of it used
6. probably Rijndael algo is used with 128 bit keys?
7. the decryption of the overlay data is done in parts, ...the decrypted data may be executable code as well
8. ntice , sice , ntfire are being checked
9. ollydbg is detected via findwindow
10. it as a copy_procedure() internally, some APIs are not called directly, instead they are partially copied to a buffer, then partly executed in that buffer and partly in their original location
11. if you attach a userland debugger, the process will terminate directly afterwards
12. no parent / child process are visibile
13. the program runs on win me not just nt systems
14. there is a message: "debugger detected - please disable it and restart the application."
15. the imports are redirected to a code of the form: "mov ax, id1 ; mov dh, id2; jmp loc1"
16. gettickcount and getcursorpos are used to create a sort of a seed / delay in execution detection
17. this shell seem to allow password checking , license key file checking , expiration checks
18. does not run in the presence of a modified/hidden softice

any knows this packer?

One more piece of info you should provide:

How many sections does the packed file have, and what are their names? Is the PE header mangled in any way, or does it appear normal?

Item 14 makes me think of ASProtect..

-nt20

19. section names are wiped. the file has 4 sections, having the 4th one with the packer's entrypoint. The first section attributes, such as VSIZE seems to be equal to all original section's vsizes sum. The 1st section has no physical seek
20. extending 11: there is a worker thread with lowest priority, that checks for IsDebuggerPresent() and keeps on calling DebugBreak() ....
21. Have only two imports: ExitProcess() and MessageBoxA()
22. The OEP's first 10 bytes or so are wiped...couldn't find them...but could live without them....


suppose it was ASProtect, how can I decently unpack it w/ a tool first, then through a suggested approach/mup method?

What is NTFIRE? is that some sort of a device or NTICE hiding tool?

So any ideas on what could that be?

Never heard of that one, but I think it's some of Elicz' wizardry. Search for
"DemoVDD By elicz" for the example code

"DemoVDD by EliCZ shows how (easy is) to call driver from DOS subsystem"

NTFIRE is the device name used:

DosDeviceName LABEL DWORD
STRING <\\.\NTfire/0>



This thread mentions the same thing being checked by Obsidium, so that may be what you're dealing with

\\.\SICE.\\.\NTICE.\\.\SIWVID.\\.\SIWVIDSTART.\\.\NTFIRE.S

http://reng.ru/board/viewtopic.php?p=6313&sid=1a14cad428d6259c703ff885aec14e37

Kayaker

Hello Kayaker,

Yes, it is Obsidium....never worked with it before....

Couldn't understand any russian though, google translate did not help, neither did Altavista's ...

Will research a bit and see if there are papers written about reversing it....perhaps I can publish something.

With obsidium I think that you can use the standard trace feature of Olly to get to the OEP. Stolen bytes aren't that hard if I remember correctly, but I think it had some interesting Import redirection, but nothing that couldn't be solved with Ollyscript. I'm sorry, thats all I remember. I unpacked an unpackme protected by it a couple of months ago...

i m working with similar target and with same sympthons.
only ida succeded to disassemble.
others(w32disasm, monitoring programs) detected by target.
even w32dasm coldnt give anything about target whem you disassemble
did you try ida?

IDA succeeds ?

Strange, I frequently use IDA in combination with OllyDBG, and most of the times IDA is directly detected by the protectors, although I have to admit that in 1 case it was the other way around; OllyDBG and SoftIce (with all kind of hiders enabled) were detected by the protector while IDA wasn't, strangely enough. Unfortunately I don't recall the packer ...

In case you meant dead-listings: never mind my msg

How would one rate Obsidium as a packer ? Reading through the original findings it sounds like it's certainly not a bad packer, but when one could trace it with OllyDBG (using the right settings I guess ) to OEP, it can't be that good, right ?

I would rate it as a little bit less than ASProtect. However, its an extremely buggy protector,
and I wouldnt use for commercial purposes/

Hello

1. I don't know how SoftIce was detected even when MeltICE trick was employed (and obsi. was using this trick, as mentioned before).

I guess it was using the RDTSC trick.

Anyone has suggestions on how to hide ntice properly?

2. Other userland debuggers were being detected through:
- isdebuggerpresent
- isremotedebuggerpresent?
- fs:[30h] and other fs:[xx] fields
- embedded int3 and SEHs

3. IDA is like olly no difference, just a userland debugger...so it cannot hide its presence more or less than olly.

4. I'ld rate Obsidium as a good packer, with some innovative tricks (well at least for me, since I don't follow decent packer tricks)...nor seen AsProtect for instance.

How is Obsidium buggy?

5. Ofcourse Obsidium could have been better, but nonetheless it is a pain in the ass to try to trace from beginning to end, manually!!

ASProtect 2.x is a real pain in the b#$^ IMHO; especially when well integrated into the app (fortunately most programmers are too lazy for that . I haven't tried Obsidium yet, so I can't help you with that; but I've found ASProtect (and Arma v4 with Nanomites) the hardest so far. So if you haven't tried ASProtect, you should really give it a try, it's full of packer tricks ...