this is actually a repost after this forum crashdown.
PS Actually ARTeam site is down due to hosting servers electrical breakdown, apparently they have not kicked out our asses.. so the download of this site is not available at this very moment.

Shub:

I've [again] edited your "original" post to include our "female" members in your greeting.

Regards,

hehe, correct, I one again forgot it.

hmm cant remember what i typed before, so all i can say is that the 'complete ownage' moniker is wrong, and theres little (or no) real content about the vm or other things within securom... and its lacking in quite a lot of information too, 'overview' and 'what to look for if your crack doesnt work' is more apt...

better jmi?

if dump doesn't work, sice will popup and you see ret address on stack(well lille ebp playing), go one up, before crash was generated, look what trick you missed and fix it. Well, that's how I'm doing with all prots.

you still think that no one of us tried to remove obsfucation done in virtual buffers for better understanding? mov ecx, xxxx morphed as push val/xor [esp],val/pop ecx and didn't analyze that all to figure that for working dump it isn't needed. I really don't know about 7.34, still waiting for it to come to stores as I pay for all the games.

Thanks as always for your contributions Shub, deroko and crew, you guys are great. Good luck with getting your hosting back on track too!

well you didnt show it in your 'ownage' tut, so no i dont think you actually all did a 100% job, otherwise all the info would be in the tut... its lacking in some major elements.. and having to fix up a dump by doing what u suggest is more or less manual cracking... if you fully reversed the protection (like i did on many many more protections) then you would have been able to automatically do a dump/repair and not rely on shit scripts to fix things up, byte pattern searches, and would have a considerably better method / approach than the ones you all seem to be using... but the focus seemed to be more on quality of the pictures and layout than the actual information contained within the 'tutorial'.. the obfuscation has been in since 7.0, actually its been in since v5, and doug on this forum posted tools and source code showing how to remove most of it....

Ok, easy now... I don't at all like some tendencies here on the board lately, to greet good contributions or other kind of nice gestures from other members with insults, put-downs and bragging about what member A or member B could have done much better, or complaining about how the tutorial or contribution is lacking, without even mentioning the great things it does contain.

Sure, constructive criticism is always a good thing, but in that case it should really be formulated nicely, and due respect should be paid to the member for the contribution in the first place.

A low-quality contribution with good intentions is always better than no contribution at all, not to mention better than putting down people who offer nothing but good intentions and investments of hard work.

Finally, sure, maybe it can sometimes be a little annoying when people brag or exaggerate something which is in your own eyes not that special at all, but remember that you yourself (and this means all members doing or feeling such a thing) might be one hell of a competent reverser, based on many years of studying, not to mention much help at the mercy of much more skilled people, perhaps even senior members of this very board, who at some point in time very well might have considered you an annoying noob, but didn't crush you anyway.

We really love all the competent members of this board, but with skill should come humility, and a behavior of publicly and directly trashing people just because they are in some aspect not as skilled as yourself can have too negative consequences for this board (or any community) to be tolerated. We will have much less lenience with such behavior from now on.

Very, very finally, don't get me wrong, lazy people will continue to be (allowed to be) stomped to pieces just like ever, but people who just want to contribute with good intentions shall be safeguarded, no matter their current level of skill.

And again, this speech is directed to a bunch of people, and for every such comment that is posted, this number grows exponentially, since more people want to be cool and "trash the noob", which is exactly the kind of thing we want to avoid.

This contribution from ARTeam is of high quality, and I know for a fact that shub, deroko and company are quite hardcore, and if someone has any good constructive ideas about how to make it better (which you indeed seem to have evlncrn8, and I know you are an extremely skilled reverser too), they are very welcome to submit them here in a nice tone and civil manner.

I don't feel insulted nor anything similar. his comments are considered and that deep srom stuff will be put into next tut.

I really tought that due to the nature of protection itself tut shouldn't go that deep. Just enough for people to see how it can be done, and where are main parts on which people should concentrate more if they want to go deeper on their own, but, ok, evlncrn8 next time we will write about that too, and thanks for your feedback.

I agree totally Delta, and I would add something about another answers in the thread: if you know a better and easier way of doing something, please feel free of exposing here your method, we would like to learn about it...

Cheers

Nacho_dj

i dont intend to be insulting etc in my replies, constructive criticism is what im intending to do, 'attacks' are not personal, let me clarify that.. i do respect the teams work, i just think it could be done better, and be more informative.. i am humble too, usually, im just trying to reflect that the content could have been more if more work was spent on it.. thats all

Indeed, presentation and coherence in particular were rather lacking. I suppose it's better than nothing at all.

Of necessity, something with "Complete" in the title should be "deep" (but not as much as something else with "Advanced". Otherwise, "Essentials of" or "Elementary Principles of" would be more appropriate.
For future reference, and this is directed towards everyone who plans on writing or is currently in the process of writing such articles, omit superfluous images and use more easily manipulated and read text whenever possible to show segments of code. This seems to be better towards the middle of this tutorial.

One more thing, where's pages 61 - 80? The section "6. Virtual Machine" seems to be unfinished.

I know I will raise flames. But cannot shut.
I must admit, on the one hand all the contributions weren't at same level (not on the technical side): not anyone have the same capacity to explain things or style in explaining, by the language point of view also. This is not a problem afterall, people like some tutorials written in chinese translated by google, so language and style shouldn't be a problem at least when technical things is the subject. Pictures help bridging these gaps.

On the other hand I don't like people who criticizes without contributing, it's too much easy to issue critics without real contributions. What people did to proof that they are so wonderful reversers, or so wonderful teachers? Why, if so much people were already able to deeper analyze SecuRom, I have not seen any good tutorial around?
What someone likes other dislikes so also I don't like also receipts like "don't use graphics", "use more code" and so on. We did so much wonderful tutorials (and I don't think someone can't say the same) that some respect is due to authors and team.

The VM thing is still coming: you, fine and talented reader, should have noticed that there's some suspension point at the end and a little smile. What this means, in your opinion?

Well I had to say this, respected colleagues, I cannot shut this time, but I will not come on this again. If you want to write something better, as I always said, I am more than available for publishing on our pages, if you like of course. We like knowledge sharing, as you should already know.

BR,
Shub

because securom wasnt 0day crap like most of the other tuts on the site, most of the scene reversers put a lot of time into researching it and reversing it, and decided to keep the information non public, for the same reasons as there are no more public safedisc unwrappers (except perhaps the pos one on your tuts section, which barely works)... thats why you have not see any good tutorial around... as for people proving they are so wonderful researchers/teachers.. their history speaks for themselves..



it means in my opinion, that the tut was unfinished, and you pushed it out to try and raise as much pr for your team as possible... by releasing incomplete information which now makes it look rushed, and unprofessional

"I'm sick and tired of writing this shit and I'm not going to write twenty-friggin-more pages." *steps away from keyboard and goes to bed*

(Admit it, we all have thought this way before...)

Now see what happens when one asks a rhetorical question they are not really sure they want answered???

Regards,

Lets recap removing useless words:

A-> I(we) made a tutorial about Securom ownage.
B-> No, you not owned it. I don't see many things I know should be there.
A-> It is a tutorial, and many in-depth things are not needed.
B-> It uses rusty techniques, like manual unpacking, so it is not an ownage.
A-> It works, why going deeper in a tutorial if results can be achieved?
B-> It is not ownage. Advanced parts are missing.
A-> It's the only one available. Help us make it better in some part. we are expanding it!
B-> It's a serious protection. No, all parts of such knowledge are valuable==not shareable.
(etc)

...wow.
-----
there is a difference between sharing knowledge and premade solutions.
Knowledge requires addi(c)tionally thinking.

Funny thread :-)

was an interesting read, im quite supprised about the use of OllyDBG,
i must be getting old,,, soon words like IDA and SoftICE will be unknown
to the modern cracker ;-)

on a side note, Chapter 6, "virtual machine" the screenshot is not actually
the main VM which is used pre/post OEP, the screenshot is of the constant
generator feature which i suppose is a mini vm in it self,,,scrap that chapter,
i want to read about the real VM :-)

hugs and kisses,
yates.

so,
if it's the title that hurts you I will change it. The tutorial follows a practical approach used to patch games by some of the authors. The VM thing is left untold yet, because, as you know, requires time. New things on SR are left behind and will appear soon or later.
Since appearance of this protection how much tutes have been released? I have not found any, point me to some real contribution if I'm wrong.
You told "keeping things secret", well I (and generally we) don't see the point: we are for a complete sharing. Might be unpopular position but, it is our position and will not change.
In my opinion instead of criticizing others' work, for which talented reversers spent their time, with quite useless argumentations, you should instead think how to add what'in your opinion is not correctly covered. I have a specific idea on knowledge publication that I share with team's members and is reflected in our work. We were kidz a lot of time ago and our egos is not usually driving our releases.

Advanced parts are missing, well, that is our best at the moment. We are working on it, but if you know something better, in my opinion you should document it. What the sense of keeping things secret, some more cracked game? C'mon r you still a 0day kidz or a reverser? .. or r u a srom developer?

Hope to see some more useful contributions mates,

Anyway nice discussion,
hugs and kisses also from me.
Shub

Yeah I want to see a full deep analysis of the full VM public too
Then I want to see the aftermath a few months later.

I'm too old to boffer with this shit now, it was a good read still if somewhat lacking

I agree with you Shub-nigurrath, keep up the good work.

don't worry sice will live


khm, khm

Might I suggest, "Collection of ARTeam's thoughts on Securom 7.30.0014"

Human, for example, is not in ARTeam.

You are right.

Here is the explanation: since ARTeam is a sharing knowledge board in RE, anyone who wants to release a tut of high quality and interest related to reverse engineering could do it in ARTeam forum, so we do accept contributions.

And obviously, it has to be released as an ARTeam tut.

Kind regards

Nacho_dj

is that bit directed to me, or yates?

and nope, i didnt find the 'ownage' part hurtful, i found it humorous... how can it be ownage when (in your own admission) there are parts missing....

Oki doki,

part 1: how to reach oep for masses
part 2: how to make working dump, method 1
part 3: how to make working dump, method 2
part 4: what should reader focus on when going deeper on it's own...

I always thought that purpose of SecuROM was to stop game from being played without original CD/DVD... but seems that from your comments it has some other purpose... roger that... will cover that vm next time... if it can be called vm due to next instruction being dependent of current one...

Shub-nigurrath:I think good work.

I shall agree with evlncrn8.
By the way,there is an article concerning the research of SafeDisc's SDAPI2.But it is in russian.

That other purpose would be to (try to) stop crackers from cracking it...

erm, considering the vm is used within the game, fixing the vm is usually NECESSARY to get a dump working, otherwise its just a lame emulation attempt

@LLXX: isn't it purpose of all protections? but this one in paticilar tries to stop program (game) from running without original cd/dvd.

@evlncrn8: so what if "vm" is inside of the game? I'm not going to steal game engine... I just want to play my game on my 2 computers without need to cary my cd/dvd all the time with me...

well then it means you havent researched or cracked it properly doesnt it... and i only noticed too the topic has your name misspelt... ;p

don't worry we will cover that vm in next tut about securom, if that's the only thing that bothers you... not hard, just boring, going trough all 256 handlers... but ok...

This tutorial specifies what it "owns" when reading the actual pdf. Each page has a header which contains the version # of .exe and does not make universal generalized claims; if reading in terms of the full picture and not just two words in a title... No magical claims are made.

"Full Ownage" context in this case appeared to once you read it to mean removing dependency of protection from executable. Although, full ownage of a protection would imply everything covered, anyone who reads the tut realizes they meant to get a runable dumped exe for the versions they have attempted, especially so when you see they left a unwritten chapter and did not attempt to hide other aspects of the protect.

The goal of a cracked exe is to have it run without the DRM(be it any form) restrictions that were originally imposed on them:

a) If I unpack a an execryptor app, and keep the vm stubbed so it acts 1:1 as it would packed, does it matter if some of the opcodes are emulated if the application in question still functions appropriately without restrictions? Of course not, I am not stealing intellectual property so vm is untouched(although that’s np too).

b) If I have a program that required a sspro ultra dongle and I was able to remove the dongle dependency from the application by patching, but I did not emulate the actual query algorithm in the asic, does anyone give a s***? NO. Would have it been cooler? Absolutely, does anyone really care? With exception to a few Russians, backup service, the actual developers, and a few dongle fanatics I think not.

So I see a tutorial here that describes a method to fully own a protection in terms of removing it from its DRM constraints; and hey, maybe there is some hidden checks missed that will be in rev2. But in terms of fully owning the context of ~256 vm handlers, little obfuscations, takes a little free time to write all that into pretty pdf form. But even with this it shall die very soon. Silly rabbits ( : Tricks r ...

Anyways, Great tutorial, maybe a little jumpy on the title but anyone who wants to learn about “the protect” and reads it for the purpose to learn can understand it is simply meant to fully own in terms of removing dependency. I’m guessing the words "fully owned" harvested from many non working cracks out there and lack of tutorials or incomplete tutorials, thus this was the tutorial to complete that, fully. Anyone reading this tut with in depth knowledge of it will realize too this was the end meaning. This leaves only personal emotions as the remainder...

Good contribution to the scene, there should be no negative shadows surrounding this. Since when are we lamers and cannot evolve as crackers for adapting protections, O! unless we do it for profit of course.

DONGS

It occurs to me that you and a disappointingly large portion of the RCE community today are neglecting to consider the fact that RCE is not just about forcing something to work by an arbitary means, but about understanding a software system fully; whether for research purposes or to make appropriate ameliorations, one of the primary goals is that knowledge of the system is to be gained from this experience. In this context, the article posted in the OP is "incomplete", in that much of the information is indeed missing. To take another example, I have read numerous articles on the process of unpacking, and in many cases the packer's carcass is left in the "unpacked" result; a dumped file tens of megabytes is considered to be "unpacked" when the original pre-packing executable is several hundred kilobytes, though zero-filled sections increase its loaded size by two orders of magnitude -- one comment I have seen is "the dump size is around 40 MB, but it will pack down to 1MB" -- is this laziness, or a poor understanding of the PE file format? Perhaps it is due to time restrictions on the author of said tutorial, but is time-to-release so important such that it takes a higher priority over performing the process correctly?

Yet more evidence of the "Great Decline"...

totally agree there about the "Great Decline", cracks which unpack to 50Mb+ when the original exe was 9-10Mb definately shows signs of not fully understanding the system and/or removing the carcass as you say... a 'proper' crack would be a clean executable, as close to the virgin executable (before it was protected) as possible.. sadly in these times thats rarely done, before it was, and it was done very well.. so either the current day crackers are getting lazy or they simply dont fully understand the systems / work involved and just go for a 'quick fix' which, while it may work for them, it may not work for others... the days of 'propering' cracks also seem to be dying out... such a shame

"It occurs to me that you and a disappointingly large portion of the RCE community today are neglecting to consider the fact that RCE is not just about forcing something to work by an arbitary means, but about understanding a software system fully;..."

Hm.. afer reading my own post I realize how exhausting it is, so much fluff. Anyways back to the point, you take worst case scenario compare it too generally. Really it depends on the case and the understanding of the protection. If you do comprehend the inner workings of the targets protection system at hand and can produce a comparable dumped/patched/genned file which is equivalently functional to the original, then what else is there to be done? Some applications call for it, while some applications do not. Take a said vm'd app that contains ~4kb worth of vm'd code. The total app weight is 2mb. If the protection has been properly removed but the vm engine (not large) is stubbed to run this 4kb of code, is this not a solution?

As long as one comprehends the mechanics of the protection and its results then it is not always necessary, especially for time and real day life to take on rudimentary uninteresting tasks if the accomplishment has been achieved, in that the application is cracked and you know how it works. Sure, the 4kb can be recovered and revirgined, but what was the point. The vm is not interesting, it is understood and its consequences are known. The problem in such a case is not that the cracker hasnt fully comphrended the protection, but that the VM is not doing its job in creating a stronger bind to the protection system as a whole, so why give a tedious task that has no merit the time.

This tutorial removes the dependency of a cd/dvdrom DRM requirement. There is a entire host of tricks and technology that is completely bypassed through this tutorial. The end result was clear, a working (to their knowledge so far) version of a application that no longer requires cd to run, with a reasonable application size. If someone really wants to recover the vm, well thats np it'll happen soon, but it is just matter of time than it is complexity. There is no doubt there are vm solutions for execryptor, themida, securom etc but surely dont expect to see that public soon. Admittedly I have complete emulation solutions for just about every dongle, but over 90% of the time I still patch, because I know result as a whole protection system and it is more convenient in most cases; hell it doesnt even require a filter driver or usb.inf package. Simply replace .exe.

I cannot defend a 50mb dump though, that is just lack of pe/dump/ knowledge. There are thousands of crackers, not everyone is great; but people do improve. But hey, at least they contributed their thoughts and solutions? Just like reading a bad newspaper article.

To sum it up: Boated file that doesn’t work is not a solution. However, a method to remove the specified access control of a protection is technically a solution as it removes the protections primary goal thus nullifying the protections purpose. "Great Decline", I have noticed a steady drop over the years since busts, and retirements leading to low quality crap. But more and more reversers come everyday and will fill that gap, I hope...

DONGS

Probably my last thought on this thread here.

Simply stated:

This tutorial is written by reverser's whom are known generally to approach by unpacking + patching. Therefore, their version of full ownage is by removing drm through unpacking + patching.

Others who use different approaches think of full ownage as Virgin files - obfuscation removal, and devm.

And that is all that it is. Depending on what category you land in pretty much determines if this tutorial is useful at all. But by no means is anything misleading inside the tutorial, I don't remember any undelivered promises.
It is just cracker ebonics in the title that has everyone confused.

Hi all,
this debate is moving to interesting directions. It seems like the discussion transformed into a "dialogue concerning the two chief world (reversing) systems"..


Of course into any science there are two conflicting worlds, one being more theoretical and the other being more practical. This applies to all the possible branches of science. There's the software engineering and the programming, there's the informatics as science, made of petri networks and so on and there's the informatics engineering.
All these possible branches are good for some things and not for others, the problem is to choice which suits your needs. There's no holy sanctuary of knowledge and no holy ways to proceed. It depends on what you want to do. If you do a paper for some journal you won't use Olly and a tutorial like this, but if you want to be practical you have to use this: unpacking+patching. A completely reversing tutorial would take much more time and we did some actually.

This is reverse code engineering, the Engineering aspect of the word RCE has an important characteristic that can be reassumed like obtaining results, through the most efficient way.

At the end of all these comments I understood that original sin was the title, probably too much emphatic (not everyone is perfect, but the title is around 7 words only), but the approach was indeed absolutely practical: This is the equation: you want a result -playing those things without some important limitations- you got a way to go. The Olly screenshots reflect this approach: doesn't sense much using Olly a lot if you are not going to cover the subject with an hands-on approach.
This approach is not changed, compared to other "respected" papers, since the Fravia times.

The purpose of any application is to avoid abuses, appy DRM policies; if these policies can be skipped protector's goal is lost, whatever way you got the result.
This difference made the success of crackers vs programmers in most cases: practical approach thinking only to the result. But these is a known thing, scholastic...but somehow seems not...when respected reversers starts speak of "old schools" .. it sounds savant..

Generally speaking if you are a protection developer much probably you would push down this approach because a "lame" set of steps breaks your long work, but the damage is already done, your program freely circulates..despite there's no real VM analysis..

I will eventually assign to this tutorial this new title: "Special Issue For SecuRom 7.30.0014 (in)Complete Owning"

meaning that it's not complete, but surely owns the protection's most evident goal.

its not complete research though, so thus can never be owning...

doing a dump with olly and then using a catch and grab method of fixing it up, is unprofessional to say the least, and by 'showing' people this is how its done in a tutorial simply creates a shittier breed of crackers than there are around today... Doing the job professionally, cleanly gets the job done, doing a half arsed dump and fixup without totally understanding the system (or sub systems) belonging to the target is simply cutting corners and sloppy, there really is no other way to look at it.... I spent numerous hours on stuff i did, all resulting in executables without any traces of the protection at all, and some ended up being damn close to the virgin exe... and i learned lots in the process.. how to do the protections with only the exe and dll's needed and so on...

Cutting corners and doing things by halves simply cuts the time sure, but it also cuts your knowledge level, so understanding the protection when a new version comes out means you have a steeper learning curve.... and might miss things... prime example being there where yates pointed out the code you claimed was the vm wasnt the real vm.....

All boils down to professionalism at the end i guess... and the end persons choice to either be professional or just cut corners to get the job done.... and as a tutor then you do have a responsibility... release crap tuts = crap crackers.. spend time and do a decent tut and then you might actually see people being more professional and clean in their cracks... and not making a crack thats 3x (or more) the size of the protected executable...

Teach a man to fish, but you do not teach a man to be a expert fish wrangler. That is to their own will/dedication. Tutorials do not make good reversers, dedicated reversers make good reversers. So if a cracker relies only on tutorials, you are what you eat.

This tutorial is by no means is "crap" as it deactivates a given "difficult" protection, it's the said goal, and it owns it within the scope of dumping and getting the job done short of removing vm. A crap tutorial would be attempting to do something and not explaining & or doing it well. It does not produce unknowledgeable dumps or non-practical methods. Those interested to follow it more in depth can and will do it.

It is not the authors responsibility to inspire & motivate the masses; this tutorial gives what it wanted to give. They leave you a unwritten portion to fill in your own blanks. Calling this crap would mean in turn calling everything on unpack.cn and any dump tutorials with vm crap(very few cover vm). After reading TOC of the pdf I knew what to expect from it.

I assure you many people do resolve the vms but that is their private work and releasing it would in turn have authors recode all (which isnt so bad either if you like reversing new protects). I mean isnt this why the posters of this thread have not released information public? So why would you ask the same of Arteam. They give a solution method for a given protect that is acceptable amongst mostly anyone in terms of getting a protection removed.

Just depends on your goals and interest.

I think the tutorial some might be looking for is "Securom 7.x Removing the VM Part II" google cache here.

thats all,
DONGS

Heh obviously you didn't even try what I said, and I will always say this, out of those 40mb, 30 are zeros. So go on, try it, and then come back and tell me something new about pe which I don't know, if this has anything to do with PE file format.

Or you can simply run your test, add section padded with 0 of size of 40mb and compress it, let's use simple upx, and let me know about your observation about "pe file format".

Main reasons why VM wasn't covered:
256 handlers in virtual buffers where each one has to be analysed to determine current/next modifier and how those are updated!! + 64 when argument+0xC == 0x50, + we have that recursive code which looks like vm. Now what do you want? A BOOK about this? when same results are achived in a few lines of a text...

Originally Posted by LLXX
"one comment I have seen is "the dump size is around 40 MB, but it will pack down to 1MB" -- is this laziness, or a poor understanding of the PE file format?"
reply:
"I cannot defend a 50mb dump though, that is just lack of pe/dump/ knowledge. There are thousands of crackers, not everyone is great; but people do improve. But hey, at least they contributed their thoughts and solutions? Just like reading a bad newspaper article."

Actually, I thought you meant something else in your reference. I retract the above in regards to this binary.

My words mean exactly as you perceive them to be.

If the VM was quite obviously compiled into the rest of the program through source code, then I would let it be. However, if it was part of a "wrapper" add-on scheme that would not be present in an executable that did not undergo protection, then obviously it should be removed.
Absolutely. Advertising this tutorial as a panacea for SecuROM only makes it more likely to be taken up by the young reversers who have the most impressionable minds.
Think about from where would beginning reversers likely source their information. One who writes such tutorials, an educator, holds a great amount of power in teaching the future generations; use this power wisely.

@deroko: You've just unpacked and cracked a file only to have it be 75% waste, and your solution is to repack it?

okay, how about making the section UNINITIALISED data... thats available in the peformat no? ;p considering its all zeroes or truncating the raw size of the section... considering its last section it doesnt need file alignment

waste? I don't see any waste, research a little bit about windows memory manager. if disk size bothers you... pack it...

Actually, going for a clean near virgin exe is very hard. Consider we clean up those seemingly waste data after the .rsrc section, however, there still might be some insane functions that want to get a data pointer like

mov eax, 0x2fa4df42
mov ebx, 0x2fc5fae9
...
some dummy instructions
...
xor eax, ebx
mov eax, [eax] <----- real work here getting data from some .arts/.catem/.securom section

And bang, we stuck getting the wrong data because we just clean it up as we thought there was no direct pointer to that area from the main section. How are we suppose to know and check for these indirect data accessing?

So instead of cleaning up the seemingly waste, just leave everything as it is, clean up the CRC check, undone the trigger, fix the IAT, dump the damn thing, and we should be all set. Just my thought.

OMG

Let me decide:

1. Virgin EXE

2. Simple Results.

I think the argument is moot for two reasons:

1. Even though we tend to think we will get "crappier" reversers, we already have quite a base of knowledge they can draw from, from fravia's old site onward. A reverser is crappy if they want to be crappy, and not learn. The quality of tutorials is not the deciding factor as to the "skill" of a reverser. Virgin EXE's sure are purty aren't they? But they ARE a lot of work. And while that work is surely a good learning experience, usually results are what most people are looking for.

2. Simple Results actually tend to widen the mind, in the sense that several times a cracker or reverse engineer finds a shortcut that the protection author did not think of. They saw something outside of the box, and this in itself is a valuable lesson to all reversers out there; to think with innovation and ingenuity. To argue the point about the EXE not being Virgin is like saying a brilliant piece of art sucks because it's not in your favorite gallery. Brilliant results are brilliant results, period. If it takes someone 2 steps to do it, but someone else likes to take an additional 20 steps, that is their right, but I see no reason to put down on the guy who took 2 steps, when the end result is the same, but the packaging is the only difference.

Reversing is about learning, yes, but it is also about expanding your thinking, about reaching that reversing "zen". There aren't any rules. Rules are for protection authors. Remember that.

-nt20

I agree totally you nicolatesla20.

In fact, I don't need to know all about a protection if I know where I could patch to defeat it, the easier the better.

Alright, a virgin .exe would be the perfect task, but when you can use a patched dump that removes the limitations, you are done.

In that case, it would become a developers' problem, if they haven't been able of avoid that way of patching in their protection.

Cheers

Nacho_dj

The wrapper scheme maybe an add-on, however, the original code has been transformed to work only with the add-on vm. Given the original code is destroyed and requires heavy manual analysis to recover, sometimes it is not worth recovering if the vm routine is just redundant and boring. Unless I have a very specific purpose for recovering vm'd code, what is the point if i know the meaning of the translated code anyways. Just because there are traces of the protection in the code does not mean the goal is not accomplished. The goal is finding a way to remove all of the digital rights that pertain to the protection.

This is not a challenge to find the virgin.exe, that is a reversing challenge in itself. The challenge posed in this tutorial is to remove the digital rights restriction, not bless the holy-ness of the .exe being virgin. If I solve the key for Execryptor necessary to solve and write a keygen for it, have I not cracked it? BUT WAIT! it's still packed?! Right, but the digital rights portion which is the goal of the overall protection has been defeated. The goal of crackers is not to make perfect files to original, the goal of crackers is to remove DRM RESTRICTION. Hell with your reasoning, any keygen ever made for a unpacker(themida, armadillo) made isnt considered a good crack because i did not restore the original file. If you want to remove the wrapper, then by all means knock yourself out because that is part of reversing challenge and not so much necessary if the end goal was reached.

I hardly believe it is "obvious" to remove a vm dependency. Both source and post exe can be theoretically recreated to decrypted if you understand the engine, but I see you would find imaginable that it is harder to remove a source level version of a vm now based on your statement, because you dont know what is original compiled data as it was never compiled? Same goes for mutated code on the post exe level. What is the difference if the vm is compiled in the source code or as a add-on, hell call it a dll. It is the same thing, it acts as a mutation engine regardless its integrated form and destroys the original form of the opcodes. A protection integrated into an application be it source level or post exe integration is the same protection, they both are trying to mutate code. Once a code as been truly mutated(by a good engine), you will never know its true original, you can simply make equivalent x86 representations.

Just the act of adding a protection to an application is by definition, not part of the original program; therefore it is considered protection and requires removal. What if themida release a vm programming interface sdk? So if vm is done as source level, does it the vm qualify to not be removed still? Any protection added to an original be it src or addon, is still protection and not part of the original application object.

When students go to school, they learn how to add 1+1. Then they learn how to add 3+2. But you do not ask them to solve differential equations. Same goes with this tutorial, you do not ask your "beginning reversers" to learn vm recovery, you teach them crc tricks, iat rebuilding, and dumping. When they evolve, they will not need a tutorial to teach them vm, as they will have the power to do it themselves. When you mention this tutorial as incomplete you are saying it in the context as though it does not cover every aspect of the protection and teach it to everyone on a silver platter. But in actuality the statement made in the Table of Contents is clear on what it will teach, and which in fact makes no false claims. This tutorial is actually very very good. It does not cover vm, but it never claimed to cover it. This tutorial makes others look bad in comparison and anyone who says this is not a good tutorial does not know what the hell they are saying, or has a personal emotions involved/vendetta. The definition of complete ownage in the title was in terms of digital rights management. Had the title been instead "Complete Protection Ownage", then I would agree with you.

deroko is right about the memory management.

Never heard of PE zero-fill?

@wincloud: see above.

Now was that transformation an automated process or was it the programmer who did it (and possibly wrote the VM as well)? In the former case, it shouldn't be too difficult, as machines are deterministic; in the latter, I'll leave the VM in as it appears to preserve the originality of the code.
Keygens are a completely different matter altogether, since writing one usually requires quite thorough understanding of the verfication process. In this case, unpacking is only a first step, and it would be preferred to leave the original executable unaltered (unless the protection has some other sinister traits, or the program itself has areas in need of examination).

Going back to SecuROM; since keygenning would be useless, it is then the preferred route to unpack (properly).

Regardless if the transformations were automated or manual, if it is a good engine it will be similar in overall time/complexity. Besides either way it should not matter, you're either going to make a decision to remove vm or not, regardless how it is implemented or how hard it seems.

"...I'll leave the VM in as it appears to preserve the originality of the code..."

VM!= Original code. So if the Vm is implemented well its original code now? That should not be a deciding factor in removing it or not as this goes against the fundamental preaching of virgin exes. The approach from the beginning should be the decision regardless automated or manual, both are going to be in the same relative range of complexity if they are designed by the same team or person, not to mention the authors may do custom implementations for larger customers for what should be a automated protection. This actually begs the question, how do you know if it was manual or automated mutations, or both? ( :

Unpacking, Keygenning, Unpacking + Demorphing. They are 3 completely different methods to achieving one result, removing drm restriction. And since when does unpacking securom not require a thorough understanding of the protection? Unpacking is sometimes more complex a process than keygenning a routine, while sometimes Demorphing a vm is an easier task than keygenning the target. Keygenning a target usually require little to no knowledge of 99% of the protection other than the algorithm itself. They all are different approaches and respective approaches.

Keygenning is an art.
DeMorphing code is an art.
Unpacking is ALSO an art.

"...unpacking is only a first step..."

Actually it is a first and final step in this case. If it is your interest to study the vm, by all means do so and have fun. You get to analyze some handlers only to end up with the result you acheived a week earlier at "step1". But fact here is analyzing the vm is just for the purpose of reverse engineering and learning, and not in the actual goal of removing drm. Taking away credit from the approach in this tutorial is an unfounded insult to any unpacker in the scene.

Once again (this maybe repetitive), this tutorial is great, it is not incomplete in terms of removing drm, and although it does not cover vm, it never claimed to inside the pdf. Although, I do believe removing vm is a cleaner, classier, and more prestigious approach, many times it is not the necessary or practical approach; especially when the vm is not that interesting in terms of reversing after it becomes repetitive, long, and does not contain any secrets. And by the way, last I checked this dumped version of .exe did not need a cd/dvd to run and works fine. How is this not "properly" done? VM removal is an accessory to the job at this point, and not a necessity. IF I had made a perfect .iso which was burnable and bypassed all securom protection, is it not "properly' done either? If it could be keygenned, is this not "proper" either? But vm protection is still attached ? ( : The drm is deactivated, that is the goal. It just needs to be realized that removing vm is a reversing exercise in this case, while removing drm is a necessary in all cases of all protections.

DONGS

well actually i did some testing, the world in conflict game - recently done by flt

i ran the protected exe, did a benchmark and ran the fairlight crack (which unpacks to a whopping 50mb), and did the benchmark,
then i compared the results.... what did i find..

the fairlight crack ran 10 FPS SLOWER than the protected exe... which really does reinforce my argument that sloppy cracks, while they may achieve the desired result are worse than the protection... had they have actually reversed code properly and not just tried a quick dump/rebuild/patch/upx approach the results would probably have been better...

and im pretty sure these findings are similar with other cracks....

The statement smacks of misinformation and is too general in nature to be considered serious. But then
this thread has turned into a pissing contest of sorts.

So it's okay to keep the VM garbage in your dump, we just need to get back those 10 FPS somehow, right?

I'm curious how many of those precious FPS's could be
recovered if the virgin.exe wasn't protected at all.

nope, its not misinformation, try for yourself, the cracks out there for quite a few securom games actually perform worse than the protected exe
and sure the fps are important in a game, its fucking stupid to claim otherwise, a bad crack resulting in a frame drop of 10 fps (or more) makes the
game pretty damned unplayable and jerky in places... you dont seem to realise that in the securom code, there are mini portions that force data/key
rebuilding and so on... proper complete research would have shown this..... the crack i did myself doesnt suffer from this... then again, i know what
im doing.....

I don't think it's fair to use World In Conflict as a basis for your assumptions. Even with my rig:
(e6600, 2 GB ram, 8800GTX) framerates are wild, dipping to as low as 16 fps in one moment, only to skyrocket to 37 fps in the next, and then back to 23. This happens with both the crack and the original dvd inserted....

yeh take the average, min->max, with the flt crack my min->max went down by 10fps..
true the game is a memory hog, but protected exe definately runs smoother than the cracked one

Cool, so lets assume that there truly is a memory loss.

Now, I don't know that much about Windows memory management, but why is there a performance loss? Isn't the amount of memory used by the Fairlight crack exactly the same as the amount used by Securom? And shouldn't the "mini portions" of Securom code you alluded to in your previous post (the ones that force data/key rebuilding) function exactly the same as in the original process?

yeh except in the original process the procs dont see code as tampered with so the keys dont get rebuilt
and the performance loss might come from the way flt handle the vm stuff or whatever - i didnt look exactly
at what they did (once i saw exe mushroomed to 50mb and they upx'ed it.....), may do later, but i couldnt be
bothered to try and find out what stuff they didnt fix... thats their job

Howdy,

This has been an excellent discussion. You will now find this topic alive here :
http://www.woodmann.com/forum/showthread.php?t=10481