Hi guys,
Greetings on the board.
It's been a long time since I was here. Haven't been doing reversing for along time either.:-) I have been caught up in the DVD and DivX scene for quite some tim enow. But after seing that it seems like ASPR have been renewed, I got interested. I'm reading and trying out things. A small question: Have anybody managed to seek out the "stolen bytes" in System Cleaner (the proggie mentioned in a thread from the other day)? I have tried to search (using softice) after the common bytes that usually can be find among these bytes, but have no success. And some of the ideas I read about in an earlier thread didn't work either.
Interesting thing, though, the newest aspr. After going over the dissassembled body of the aspr.stub, I saw that there are several sice checks now (as evaluator mentioned). I seem to have found a way around it. I put a bpint 01, and when sice breaks, I just jump the int 01. Then the program starts normally,and can be debugged as usual. The IAT problem can be solved as before. (I'm on XP SP1).
I tried using Ollydbg according to Labbe's tutorial, but this didn't work on my machine. Olly doesn't break at Isdebuggerpresent as he describes.
I must say it is nice to learn something new again. I see some of you guys are really catching on in your reversing endeveauors. Seems like some of you are becoming good coders too.

Well, enough ranting for now....
But what about those stolen bytes? Any good ideas?

regards,
hobgoblin

they are


in 4.91e but im going more probs with iat atm.. greetz



lol

Thanks for a speedy reply. But how did you find it? I know that in most programs there will be 11 or more bytes missing, and that they mostly looks the same. I'm more curious about you find it, what kind of search methods you use (if you use any).

regards,
hobgoblin

These instructions are not really in clear text in the code. Aspr does emulate the instructions with other instructions that do the same. You will have to break before Aspr starts executing the emulation and you'll have to watch the stack and registers carefully. Also I recommend to note down the program execution flow. As systemcleaner is a Delphi app (If I remember well) you will know the stolen bytes and you only have to check the value of EAX to know what the MOV EAX, xxx line must read.

First you should look at older versions of the same program, it mostly used the same way.

hi assp-maniacos!

as I can remember, we played with SVKP-protector & I done
pseudo-code exersize.
So seem Ass also dedicate himself to learn this technique..

so if you first time see that simulated code, use that
pseudo-code exersize for better understanding.

Also I mentioned alternative way for it:
just attach this code to dump & set EIP...

Hi hobgoblin

Long time no see

The way I find them is simply by looking at the previous versions and then search in high memory for the byte pattern - excluding any push address - Usually you can find it but I must admit I am on vacation and have not looked at aspr for a month or so

/hobferret

Hi hobferret,
Yes, I do use that method myself. But this time I was wondering if there was possible to find a more generic way to do this. Another method i use is to check the registers when I have arrived at the OEP. Sometimes one or two of the registers gives up an address to the higher memory. When you check that, and scroll a little bit upwards, you will eventually see the stolen bytes.

Anyway, I usually manage to find it.:-)

To those interested in exception handling, take a look at this proggie:
Synchromagic from xxx.gelosoft.com

Now do this: find the adress of the int 01 instruction. After that, activate SuperBpm for NT (I'm on XP). Enter the program via a bpx getversion or something. After breaking and disabling this bpx, try put a bpm right before the int 01 address.
Let me know if you succeed in continuing debugging this program. I don't...
When tracing and checking I found 3 places where exception handling is taking place, and where the program exits. But I can't seem to find more. When I modify the 3 places, the progam still exits quietly....

Regards,
hobgoblin

Hi again hobgoblin

Which version are you talking about - pro or home

Will have a look when I know which one!

/hobferret

Pro 3.5 build 557

Hi shoob
Please find the correct oep and stolen bytes as:
oep= 56609c
push ebp
mov ebp,esp
add esp,-10
mov eax,0056598c

I have it running perfect on this info.
error in the last version 4.91d is corrected in 4.91e where
it took out the time limit on unpacking.

britedream.

i have yesterday some talking to a friend, he had also unpacked the same proggy (4.91e). Then i've got his IAT (cause my dont even works) and fixed my dump, the program dont even work for me thats very strange cause i using the same program /same dump and my program belongs to another dword at 005660AC CALL DWORD PTR DS:[56F1A4] so it crashes (his works and belongs to another dword). Anyway maybe a 2k prob?.

OEP:_ 467757


if you already searching for bytes in synchromagic/my dump works perfectly (stored in unpacking process! short before returns to Restore the code (pushad, rep [edi] etc..)

Hi
synhmagic info:
real oep= 4544fc
stolen bytes:
push ebp
mov ebp,esp
push -1
push 48b1e0
push 45827c
mov eax, Dword ptr Fs:[0]
push eax
mov Dword Ptr fs:[0],esp
add esp,-58
push ebx
push esi
push edi
mov Dword ptr ss:[ebp-18],esp

I have the program running on this info.

Britedream

Hi britedream,
About Synchromagic:
Did you manage to unpack (halt the program at OEP, then dump it) by using Softice on WinXP?
When I try to do this, I first put a bpint 01 in Sice, and when Sice breaks, I jump the int 01 instruction, remove the bpint. But when I try to continue, the program just quits without any messages.
Doesn't this happens to you?

hobgoblin

Never mind. I found a way around my problems.

long time in this world done solution for INT01 detection under NTsystem..

Hi hobgoblin!.
I am sorry I was unpacking the home edition but the pro
is the same except for the following:
oep 467757
the two address pushes
push 4a38a8
push 46c56c

I have the pro running perfect, If you wish I can send
you my IT , so u compare it with yours.

britedream

as i said one page before already

Hi shoob
I was wrong, you are right , I was thinking of something else.

so I edited my post.

britedream

Britedream, please check a PM I send you.

regards,
hobgoblin

Yo hobgoblin

Looks like most of it has been done - so there is no need for me to take a look when I return

/hobferret

No.:-)
I found out what to do. In the process I found out how to find the stolen bytes in a rather eaasy way too. The program is unpacked and up and running.

Thanks for offering help, though...

hobgoblin

Well, why don't you share this "rather easy way" with the rest of us then...


dELTA

Okey. This is what I did.
After finding the OEP, I haltet the program there while running Sice. By checking what the code looked like at the addresses stored in ecx/edx, I found it to be a lot of "loopnz" instructions. (I have used this method in the past also. Sometimes though, the registers don't give up this information. Then you have to search for bytes that are a part of the code I describe in the next sentence).By scrolling upwards a little bit I found the code that manages the writing of the "stolen bytes" and also manages the code that overwrites the section where the "stolen bytes" are stored. (After the "stolen bytes" are used, they are overwritten). One of the instructions you will see are a jmp instruction (the first one you get to when you scroll upwards). The trick now is to halt the program by a bp in Sice the next time you run the program. When you first run the program, bpx on Getsystemtime. When Sice break in the aspr-code, step down to the end of the routine and write down the value you see is pushed from eax to an address. Then go to the OEP and make a note of the address for the jmp instruction. The next time you run the program, bpx on Getsystemtime, and then write in eax the same value you found the first time. By doing this you make sure the address for the jmp instruction is the same. (If you don't do this, the code will be placed somewhere else). When Sice breaks at the jmp instruction, start singlestepping from there, while you carefully notice the code you see listed and executed in Sice while stepping. Soon you will see the stolen bytes be listed between jumps.
Just try this a couple of times, and you'll see how you can find out what the stolen bytes are.

As I have written this, let me point out that this is not an original idea from me. I have merely given input I got from evaluator an extra thought, then tried it out in practice a few times. I'm just passing on information.

hobgoblin

Hi hobgoblin

You have just triggered my last remaining brain cell into operation! I now remember exactly what you have done but I had forgotten all about locking the code location by using an API.

There was mention of this on this forum maybe a year or more past - it's amazing how easy it is to forget the simple things

Thanks for reminding me

/hobferret