So do check if restore succeeded otherwise attempt another restore til succeeds thus rearms Is that correct your saying it's not really the rearming although that's the error it's actually the restore so I will work on that Thank you
Thank you for all your in depth/appropriate comments. I am however under the impression you got this idea/backup/restore/rearm to work as that was what I remembering you saying. I will explain what my tool does in what order so I can approach what to deal with. 1. OR4 makes back up (hopefully good one as restore is dependent on it correct?) ( And hopefully at moment it is not in notification as to work) 2. We check if task installed which proves if install is current or not 3. If install current give msg go to menu then uninstall then install 4. When install OR4.bat it puts restore code and rearm in OR4.bat file then installs task and does status 5. So in coming off a non-notification +1 rearm count minimum a rearm should be possible and an extra one not needed although more may be present! 6. OR4 doesn't use up all rearms as it one, can't determine how many exist and two just restores again then rearms in comparison to just rearming til rearms out then restore 7. It upon re-installation backups/rearms which might fail for whatever reasons if not a rearm is attempted and task, status is done 8. If restore fails from back up done at re-install (another backup at the time) should be done prior as to give place to come from to attempt another restore from re-install back up 9. If the restore is crappy from the backup then can the backup be blamed or just the restore hence try another restore from temp back up since either the backup is bunk hence bunk restore or the back up is fine hence just the restore failed Every time I run task or OR4.bat which restores/rearms from original back up it never fails ever! Just when re-installing OR4 ...lol
Thanks Please don't fry your brain as I still might need you...lol 1. We already check if installed via UNKNOWNZD's help/code 2. My code for restoring should be same as yours minus registration backup (I think) 3. I'm not doing (present) temp backup yet but if restore fails that might safeguard another attempt at restore via backup is solid 4. So we agree this is not rearm issue but indeed pre-rearm issue hence restore's/backup's 5. I think a check for restore failure then temp backup then more restore attempt can be done with one .bat file and this problem we should both have but you say yours works. Can I test for you. 6. Unless you share your code to check rearms that method of dealing with whether or not to restore is not an option to me and really I just attempt 30 day renewal of backup/restore which is different to what you've told me your build does 7. Take a break I'll see you when your not "frying" and your rested Thanks for all your comments/help Edit: Actually it's not even a big deal since if it installs once that's all you need cause the OR4.bat file will run every 30 days. If comp is off just run task or OR4.bat file directly. This will work installed regardless of office installs since a backup will work amongst multiple office installs. so just keep letting task run and all is fine I believe. It's just the reinstall that fracks things up because of back up restore. I think it still has a chance
You should not use any Diagnostics function in the .NET framework since it is intended for debugging ....... but not for native purpose that check whether a program has been closed or not ..... btw since the property is a boolean value ..... I doubt whether it can be updated simultaneously when the process has been closed You better use something like NtQueryInformationProcess .... it should be the most native one and the closest to kernel as I know
Thanks again for the help with the install check. It was one thing we needed to test to see why we're having error only we're still having it but maybe temp backup pre-original backup restore will help if restore fails
Thanks for you suggestion, but using that is much more complicated, besides I don't like the dark side of programming BTW, sorry, it's my last post off topic
This is a thread to encompass all office 2010 exploit possibilities/information so go for it guys...lol I'm just working the rearm end of it I thought exploits were the dark side of programming ...lol
Well you still haven't touched the dark side of programming ...... the dark side including creating rootkit driver (actually I guess that is the reason of why MS has stopped allowing unsigned driver to be loaded in a system since it could be a rootkit driver) and injection thing such as detours and DLL injection ...... but well actually the function NtQueryInformationProcess is still not yet in the kernel space so actually it's output can still be affected by a rootkit driver ..... I guess it is safe to use it since it is still in the user land (user-mode function, aka ring3 function)
exploits were the dark side of programming but still no use if you have successfully built a gate for those data which will be processed by the system Those gates including router / gateway ...... and detours on those kernel function (well but I guess you should not know what detour is, since it is one of the dark side of programming ..... but still it can be epic useful if you use it for some defensive situations)