firstly, thanks for the great activator. i have no idea how it really works tbh, but it has done fine. i was a little worried by this reply you wrote back on post #607 about the trojan meredrop. i understand that mse will pick up the keygen, but i'm also getting the meredrop trojan warning. stupidly i got the activator from another site - but that was before i knew of this one is the above still the case, or is mse now picking up the program as a trojan? thanks again **edit - and sorry, i know how annoying these questions are! but i have been through lots of this thread looking for the answer!
It doesn't really matter which antivirus program you use. If you got the file from MDL, ALL virus warnings are false positives. Can't speak for other sites though.
what i meant was cody seemed unaware of MSE picking up the program as a meredrop trojan back then - i was wondering if that had changed. after all he did say they were getting more aggressive with the software. it would be useful to confirm this just so that i can go and warn those that may download the software from the same source i think i'm going to remove both "threats" and redownload the software from this site. shame because its worked fine anyway, great program though! ***edit: i'm not sure why tomah is being thanked for that post! i know he was trying to be helpful, but he misunderstood my question I know that if you download the software from here it provides a false positive. what i am asking is if the false positive in MSE includes the meredrop trojan. codyqx4's post i quoted suggests that it doesn't and only flags it as a keygen. its irrelevant now anyway. i've removed both just to be sure and am downloading from here. i will let people know if MSE does show the software as a trojan as well as a keygen. it is useful information for those who haven't downloaded from this site.
@Team Toolkit Can you do random naming of keygen and appropriate task name so AV doesn't have consistent hash to scan and flag for it Seems you guys almost nailed the activation error with the keygen so now just deal with AV Daz loader does random naming of loader Later
That wouldn't really help much as renaming stuff wouldn't help. Daz encrypts his loader and AV can't really nuke the loader without making the PC unbootable. The best thing we can do for AV is execute the KMSEmulator in RAM (but AV may start flagging AutoKMS), but this is very difficult and we haven't made any progress on this.
2.1.3 will have the fixes I have discussed. NULL PID is not 100% on its own but there are 2 more tricks I have. Last I posted, I'm trying to edit PID in RAM so I don't have to stop, edit and restart KMSEmulator. I can read 100% fine but my write is partially working. It doesn't write correctly but it is close. Hopefully someone can view the code and help on it. So all my PID editing code is now open so other people can see how I change PID in C#. Last I remember "Afterburner" is in C# and has KMS, and I helped by posting my AutoKMS Windows code.
So everyone's KMS activators will have this new keygen and all improve What's next to work with the keygen? Or KMS activation in general
Can't you randomize autoKMS and emulator name? Or would you have uninstall issue So in having supported KMS activation I've noticed AV stuff and persistent error so you guys nailed 50% of the KMS problems
Direct Memory Editing is now working perfectly, and I confirmed that you can actually change PID in RAM on the fly and it be effective (I was worried it would be used in such a way that it was used elsewhere). Means I'll be adding two new fix modes to EZ-Activator when I get the chance.
Instead of simply adding the fixes, I'll replace the rearm and reinstall licenses fixes. The reinstall license fix has nothing to do with the issue at hand, but is rather for license to be screwed up in a way that can only happen by a failed conversion (which I have yet to see). If this is a real problem, the repair stage fixes it as things are reconverted. As far as rearming, rearming works for blanking CMID. Most of the time I see people in a state where they have no rearms. Also, given that I want to do CMID fixing with the "Repair", this is a more elegant solution because if I have to manipulate CMID's, I do so all while either maintaining or giving the user 5 fresh rearms (not burning them).
These days have been extremely productive Thanks CODYQX4 and letsgoawayhell, you have done an excellent work
Both new fixes are now fused into EZ-Activator and working as of my testing. I can fix EZ-Activation error via two different methods. There is just one thing I am worried about. A new potential problem (with the same solution) may have been created by me. In _patrik_ case, we have a new scenario. I assumed that persistent error never ever occurs after initial activation. This however only applies when using the same PID throughout (and we've all been using ZWT PID). The KMSEmulator that will be used in V2.1.3 is letsgoawayhell V2, except I have unpacked it. It has a NULL PID. If my PID change routine fails and I go into CMID routine, I am using a NULL PID for the whole thing like any other case in the toolkit. The scenario I fear is that the user is successfully activated via a changed PID, but somehow rejects a NULL PID. Now as far as toolkit activation goes, EZ-Activator would just go into PID phase and reactivate once the good PID is used. But AutoKMS doesn't have PID changing ability. So what I'll have to do is add a PID section to AutoKMS INI, that one time, it will try PID changing, and if it hits a good PID, it will always use that PID and therefore the issue of NULL not working will not cause AutoKMS to fail. This should prevent a rare sceario like this from ever occuring. Note that if you got a changed PID working and NULL failing, the Activate button will not ever work. This is because I do not apply any fixes/mods (PID) to this. It is meant to be used as is, and I always recommend EZ-Activator anyway.
My suggestion is that when you find a working PID for a specific PID/CMID combination, you can hardcode it in the Modded keygen and get a new keygen with that PID in it. Then use this file as keygen in your scheduled task. In the case of a manual activation command, if that computer already has a harcoded keygen, then read PID from that keygen. And when you hit a working PID and the user is not willing to add the scheduled task to his/her OS, you can use a file in say %appdata% to save the PID/CMID combination that will be read in future runs of your activator.
I would like to know does the license backup feature work if i was to backup a legit key and then reformat my system and reinstall office 2010 and try to restore the license, would this work?
I can do that by physically writing the PID to the keygen, but I can only edit on it disk, and not the embedded resource itself. As I said the issue itself would be rare so I'd rig AutoKMS/EZ-Activator to handle it, and they could save/write the PID.