Sandboxie technical tests and other technical topics discussion thread

Discussion in 'sandboxing & virtualization' started by MrBrian, Oct 17, 2014.

  1. CoolWebSearch

    CoolWebSearch Registered Member

    Joined:
    Sep 30, 2007
    Posts:
    1,247
    Thanks, it's good to know that I'm not the only one here, but could you please, write what do you else use for your security up?
    I'm trying out multi-security set up on my computer.
     
  2. CoolWebSearch

    CoolWebSearch Registered Member

    Joined:
    Sep 30, 2007
    Posts:
    1,247
    Thanks for the answer and thorough explanations.
    Also, Kees confirmed:
    Adding code increased attack surface because the code increases. More code means a higher chance of an exploit to occur. But when an exploit occurs the complexity increases when other code also tries to hook or control the commands being executed. Higher complexity reduces the chance of a exploit succeeding in its intrusion.

    Regarding SBIE and the fact is it is not targeted: Just for the record I wouldn't be surprised that Invincea actually pays for all forms of security researchers, organizations and hackers to bypass its security/protection mechanisms as well as testing SBIE and its protection mechanisms against all forms of exploits and bypasses and against all forms of targeted attacks that SBIE can protect against, they just don't raise dust about it and as well as they don't make it public, like Google Chrome boys do all the time.

    Here some things from your lasts post that torture me: You said:
    My question: Than why do I have impression as everyone else would, that, by reading your posts Google Chrome is faaar harder to bypass than Sandboxie?
    I will take some of your posts here:
    If that's all true, why do you think people won't get impression that Google Chrome is so much harder to exploit and to bypass in the first place?
    These posts make people think that Google Chrome is much harder to exploit and bypass than Sandboxie, see what I mean, not just this post, but all of your other posts:
    Here are almost all of your posts about on how Google Chrome is supposedly faaar more secure than SBIE:

    https://www.wilderssecurity.com/thre...discussion-thread.369328/page-11#post-2425842
    https://www.wilderssecurity.com/thre...discussion-thread.369328/page-11#post-2425843
    https://www.wilderssecurity.com/thre...-discussion-thread.369328/page-9#post-2425022
    https://www.wilderssecurity.com/thre...-discussion-thread.369328/page-9#post-2425208
    https://www.wilderssecurity.com/thre...-discussion-thread.369328/page-5#post-2422675

    You're contradicting yourself based on these posts (and if your posts are truly 100% true).
    Comparing Google Chrome and Sandboxie, when it comes to security and protection, cannot be meaningless if everything you wrote about Google Chrome and Sandboxie is 100% true and 100% proven.

    Windows Security also said:
    Please help me try to understand, when Chrome Security is based on OS-mechanisms and SBIE is based on OS-mechanism (lower level objects can't touch higher level objects) why would SBIE be stronger as Chrome when it concerns breaking out of the this OS-based sandbox?
    The only thing I can imagine is that the additional SBIE restrictions and side-by-side (hook based) protections make it more complex to exploit a bug in a predictable manner. On the other hand most of the buffer overflows based exploits bypass those extra (API/hook user mode level) protections anyway. So this "SBIE cannot really block . . " is a bold claim IMO.

    If comparing Google Chrome and Sandboxie is so much meaningless/useless to all posters, than why you wrote so many advantages of Google Chrome when it comes to their robustness, security and protection, and none of Sandboxie's (because Sandboxie is in huge disadvantage, going by just reading your posts)-poster like me will deduce that Sandboxie does not have any advantages over Google Chrome, when it comes to its robustness, security and protection-what else can I deduce? Nothing.
    If you can explain me this, I'd stop.

    And regarding that you think we will see the real-world/in-the/wild Google Chrome exploit and bypass, sure it will happen, but it will happen since Google Chrome boys pay non-stop 24/7, to hackers and to many security researchers/experts/organizations to bypass Google Chrome, so Google Chrome, like you said, will simply patch it under 24 or 48 hours at most.
    That's all from me.
     
    Last edited: Nov 18, 2014
  3. bo elam

    bo elam Registered Member

    Joined:
    Jun 15, 2010
    Posts:
    5,995
    Location:
    Nicaragua
    Hi CWS, I do agree with Yuki about comparing Chrome to Sandboxie being meaningless. In my opinion, comparing both programs its not fair to Chrome. I mean, Chrome is a browser and no more than that while Sandboxie can be used not only to sandbox your browsers but every program that runs in ones computers, USB drives, downloads folders, CD and DVD drives, etc. There are so many things that can be done with Sandboxie, its not even funny comparing Chrome to Sandboxie.

    I scratch my head when I see you and others comparing both programs. To me, Chrome and Sandboxie are in a different league. The day that we can use Chrome to isolate every program that runs in our computer and still have this same sandboxed programs interact with the system and files like if we are not running anything sandboxed, that day, then yes, Chrome can be compared to Sandboxie. But until that day, in my view, Chrome is just another browser.
    .
    I agree with you when you say that by reading Yukis posts, "one can deduce that Sandboxie does not have any advantages over Google Chrome, when it comes to its robustness, security and protection-what else can I deduce? Nothing". And that kind of bothers me a little because if someone gets lucky to discover Sandboxie and searching about it, lands in this thread, this person can get the wrong impression and end up disregarding using Sandboxie. And this guy would end up going back to using Chrome and continue to get infected like he always has. In my opinion, thats terrible.

    Someone might say, What the hell you are talking about? you mean to say that this user is going to be infected despite using Chrome as their browser. Thats not what I am saying. What I am saying, based on my personal experience, sandboxing our browser with Sandboxie is the first step that most of us SBIE users take with Sandboxie when we first discover the program. After a while, many of us, after realizing that there are an incredible amount of ways for using the program and being convinced that it really works, we begin to sandbox our mail client, other programs, etc.

    But this lucky guy, who discovered Sandboxie might miss becoming a full time Sandboxie user only because he read Yukis posts or other post of the same kind. I like you Yuki, so I let you slide;) but you should think about what I am saying here. Later, to both of you.

    Bo
     
    Last edited: Nov 15, 2014
  4. Rasheed187

    Rasheed187 Registered Member

    Joined:
    Jul 10, 2004
    Posts:
    14,789
    Location:
    The Netherlands
    Well, I never said that wat0114 was right or wrong. But if you look at these pics (see links), you can see that IRP hooking is considered to be "kernel mode hooking", even though it's perhaps not correct to call it this way. So that's what I meant. Do you perhaps know what type of kernel mode hooking techniques is being used by SBIE? In the past, most HIPS used SSDT hooks, but that can't be done anymore on Win 64 bit. And I didn't understand everything that you posted, what do you mean with "Native API"? Perhaps you can refer to the first pic.

    http://postimg.org/image/54b89slvt/
    http://postimg.org/image/p7xs9pwm5/
     
  5. CoolWebSearch

    CoolWebSearch Registered Member

    Joined:
    Sep 30, 2007
    Posts:
    1,247
    Thanks Bo for backing me up, just for the record, although i don't have any evidence at all, I personally think that using Google Chrome under Sandboxie is simply more secure against all malware installations, all exploits and bypasses that could overcome Google Chrome-and this is why I decided to browse Google Chrome under Sandboxie and all of its restrictions.
    After all that buffer overflow exploit from 2011, Vupen exploit was able to bypass Chrome sandbox (yes, sandbox), however it was stopped dead inside Sandboxie by using Sandboxie's restrictions.
    There is also that post that Windows Security wrote:
    Adding code increased attack surface because the code increases. More code means a higher chance of an exploit to occur. But when an exploit occurs the complexity increases when other code also tries to hook or control the commands being executed. Higher complexity reduces the chance of a exploit succeeding in its intrusion.

    And I'm sure that Curt tests Sandboxie by giving it to all forms of security experts (huge number of them), hackers as well, he just does not make it public like Google Chrome boys do, that's all.
    Cheers and thanks.
     
    Last edited: Nov 19, 2014
  6. bo elam

    bo elam Registered Member

    Joined:
    Jun 15, 2010
    Posts:
    5,995
    Location:
    Nicaragua
    Here is Tzuk responding to users at the Sandboxie forumm who have same notion. I´post this before and Acadia did as well a few days ago. But, here it is again. I agree with Tzuk.
    http://forums.sandboxie.com/phpBB3/viewtopic.php?f=5&t=11788

    And like I said before. I am not a Chrome user and don't like Chrome but if I was a Chrome user and thought that there was a conflict between Chrome and Sandboxie, I drop Chrome, not Sandboxie. From my point of view, that is not something to think about.

    Bo
     
  7. Acadia

    Acadia Registered Member

    Joined:
    Sep 8, 2002
    Posts:
    4,228
    Location:
    US
    Ok, so I have what is probably a stupid question, as many years as I have used these excellent programs I haven't had the time to really tear them apart, after all, I have a life :rolleyes: : Does it really matter how "humungous" your attack surface is if some (at least two in my case) of your programs will dissolve everything anyway? Just as one example in my case, I never surf without being inside of SB which is on an entire system (all drives) protected by Shadow Defender. (Yes, I know enough to kill every sandbox before entering a financial site, and then killing again afterward before beginning normal surfing.)

    Again to repeat, if your major security programs dissolve everything anyways, and you (hopefully) understand how to use them, does it really matter how big your attack surface is?

    Educate me,
    Acadia
     
  8. shogun_r

    shogun_r Registered Member

    Joined:
    Aug 17, 2013
    Posts:
    22
    Location:
    Sweden
    Excuse me if it's a stupid questian. But when I'm in "Firefox sandboxed browser" and surfing the history will appear in Firefox that's not Sandboxed. Why?
    Is Sandboxie totally secure and can I surfing around and feeling totally secure?

    How will I do to get the best security if I need to do something different?

    Now I'm delete history in both Sandboxed Firefox and the usual.

    Sorry if the questian is in wrong thread.
     
  9. bo elam

    bo elam Registered Member

    Joined:
    Jun 15, 2010
    Posts:
    5,995
    Location:
    Nicaragua
    Hi Shogun. Firefox saves bookmarks and history in file "places.sqlite". So when you allow Firefox (Sandbox settings) to save bookmarks out of the sandbox, history gets saved as well. To take care of history, you can set Firefox to Never remember history or use custom settings for history. Lately, I have been doing the latter.
    http://kb.mozillazine.org/Places.sqlite

    Regarding your second question. All I ll tell you is that I haven't seen anything that moves, looks or sounds like malware ever since I installed Sandboxie for the first time (6 years ago).:)

    Bo
     
  10. Behold Eck

    Behold Eck Registered Member

    Joined:
    Aug 23, 2013
    Posts:
    562
    Location:
    The Outer Limits
    Never had any reason to doubt the effectiveness of Sandboxie.

    To anybody that does why not test it out yourself and I`m sure you wont have any regrets ?

    Regards Eck:)
     
  11. bo elam

    bo elam Registered Member

    Joined:
    Jun 15, 2010
    Posts:
    5,995
    Location:
    Nicaragua
    Acadia, I ll give you my thoughts about what you are asking. As you might know, all I use for security is Sandboxie and NoScript. I have been using both of this programs for about the same amount of time (6 years), as far as I can tell, they run great along each other. There is no conflict on the surface and I hope there is no unknown conflict.

    The "Hope" factor bothers me some though. Since there is always a chance that unknown conflicts between software's can become apparent only when we get get hit by malware, thats the reason why after becoming a Sandboxie user, I eventually dropped using anything else along SBIE and NoScript, I ended up using Sandboxie on its own and depending on SBIE.

    I think Sandboxie works better when no real time antivirus or any other real timers are going at the same time than SBIE, scanning the sandbox while Sandboxie its doing its work can create problems. I ll give you an example. I can tell there being a big difference between using Sandboxie alone or using it along an antivirus, for example. You know the "Sandbox don't delete" kind of error that we Sandboxie users get every once in a while. Thats a normal error that we all get sometimes. But the interesting thing is that, before, when I used an antivirus, I use to get one of those errors maybe like once every three months. But after dropping using an antivirus, 4 years ago this Christmas, I have had that happen only twice. And I am convinced that both of those times was my fault for doing too many things at the same time. Another example, all of my sandboxes open and delete fast, that would not be the case if I was using real timers scanning the sandbox.

    So, I am convinced that it is better to at least not use too many security products at the same time. In my case, Sandboxie and NoScript are number one. I feel safe as hell with those two programs and would feel less safer if I was to add this for this and that for that. I think the perfect way of using Sandboxie is to use it along an antivirus and it is the recommended way of using it, I am not against antiviruses and you ll never read me calling them useless or anything like that but this are my thoughts.

    Bo
     
  12. Acadia

    Acadia Registered Member

    Joined:
    Sep 8, 2002
    Posts:
    4,228
    Location:
    US
    Thanks for your thoughts,
    Acadia
     
  13. 142395

    142395 Guest

    I've never seen people saying this kind of statement actually stopped, but with a bit of hope, I'll reply you again. But I believe one can never reach the truth unless he think by himself. Don't expect I'll reply further about this.

    Comparing added attack surface and added complexity generally is meaningless and impossible, it's all dependes on each specific details.
    But from what so far I've learned, I can say I haven't seen any added layer stopped dedicated attacker but have seen many cases that added attack surface is necessary to compromise the system. Basically if there's a protection, there's a bypass. If there's an absolute way which can't be bypassed by any way, every security vendor would use that however simply there's no such magical stick. Added layer usually ends up just adding some steps for attacker. Common criminal will give up for this, however it can't be applied to determined attacker.
    I'll be surprised to die because simply it's impossible. Do you know how much money is needed? And what you said is impossible even with Google's big money. It seems what drives many researcher to challenge Chrome is actually passion, not only money. In fact the first guy who bypassed Chrome challenged again in next Pwn2Own though in this 2nd challenge he failed. Vupen's blog also made me think they're guys who are more excited if the target is more robust.
    Those can be achived because Chrome is one of the most popular browser and also known to be bullet-proof.
    I think Invincea might ask one or some researcher/labs to test SBIE and that is what they can at most, considering amount of their asset.
    Some independent researcher may test SBIE, but it can't reach Chrome's degree simply because not so popular (sadly).
    Also if Invincia really did such testing, it may be said as a mistake or wrong marketing that they don't publish the fact anywhere. Everyone who know those things will get more confidence and will put more trust on SBIE.

    So again, I found (I don't know how many times) you don't catch context and this is the main reason I'm always irritated. My claim have been always the same and coonsistent.

    Comparing Chrome and SBIE for ONLY its robustness against code execution exploit is meaningless, because you never come across the situation where that matters!
    You can't come across such an advanced attack even if you really want and tried all effort to become victim of such attack, unless you're billionaire or CIA agent or genius scientist or having any other certain reason to be targeted by such advanced attacker who don't care about spending lots of money and time to infect you.
    But even in such APT, if I'm attacker I'll attack more vulnerable points if there is.

    As long as we keep focusing on practical situation, either Chrome alone or SBIEing Chrome will be fine, there's no difference btwn them for robustness against browser exploit.
    But don't forget nor underestimate that SBIE provides what Chrome sandbox doesn't provide, and these advantages can be good enough reason to SBIEing Chrome.

    I've felt there're several points that you don't seem to understand but I never try to make another effort to explain them one by one, but one of them is you don't know what targeted attack is, not limited APT (APT is part of targeted attack).
    I knew most people here in Wilders also don't know targeted attack, because when Symantec claimed 'AV is dead', many people misinterpreted the statement. Symantec is right, and though Symantec wouldn't admit, actually AV with all advanced features such as BB and IPS and reputation etc. are still almost helpless against advanced targeted attack, so they just said they'll focus more on post-infection detection, it's quite reasonable.
    Targeted attack is completely different from common attack we come across, and targeted attack aims to break into only the victim, nothing else.
    So in theory it doesn't have to be advanced malware (you can' use the term 'targeted malware' as a replacement of 'advanced malware' because they're different) though they're often advanced and if you threw it to Virustotal probably it returns 0 detection.
    They study victim's environment and make specially crafted attack. They also often combine advanced social-engineering which even experts admitted he's be fooled.
    And when it comes to APT, it's not only more advanced than common targeted attack, but it persists. Many APT attacks last several years.
    There's no 100% protection in targeted attacks. This fact drives Kaspersky Labs Japan to say "It's impossible to block them completely but it's still important to raise the hurdle for attack because it may cause they switch to another target".

    BTW, if attack is only conducted in targeted attack, it won't be called as In-the-wild attack though it's real world attack.
    Though I believe someday we'll see real Chrome bypass exploit, I'm sure it is in targeted attack. Even IE or Adobe Reader sandbox bypass only occurred in targeted attack, however after these cases some other criminals 'copied' the exploit and used it ITW (still damage number of victim were quite limited). Of course those copied attacks are no more targeted attack.
    But Google have been incredibly quick to patch. Most vulnerability was patched within 24h. I once learned how Mozilla can patch within 48h and very impressed, but Google is even quicker. So such copied attack is quite unlikely when it comes to Chrome (we all know how Adobe & MS are slow to patch).
    [EDIT: corrected the word 'damage']
    [EDIT3: maybe somewhat confusing, but AR bypass was not copied. Only IE (and actually flash 0day too) attack was copied by common criminals and used ITW, caused some victims until MS patch the vulnerability.]

    I don't get your last paragraph. Why paying hacker cause real world Chrome bypass?
    Maybe your English problems?

    [EDIT2: I forgot to consider possibility when you're IT administrator or executive in a company. In this case you can be targeted not as a personal user but as a key factor to penetrate the company. However if that's true, and also in the situation where you're personally targeted, you have plenty of things to do before comparing Chrome with SBIE.
    Attacker always focus on the most vulnerable point.]
     
    Last edited by a moderator: Nov 19, 2014
  14. 142395

    142395 Guest

    Well, now that not only CWS but you also admitted my statement can/will cause that misinterpretation, I noticed that I was too confident that reader can get correct meaning from what I wrote, and my assumption that reader will read all of my statement seems to be somewhat selfish.
    Surely I have to be more careful for words because what you concern is difinately not my desire.
    I hope such lucky guy at least read this and previous my post, and be confident with SBIE.
     
  15. 142395

    142395 Guest

    IRP hook is kernel-mode hook, but it's not direct OS kernel hook. Kernel-mode is different from kernel itself, all kernel driver works in kernel-mode but they're not OS kernel.
    Currently don't know, but okay I'll look into this and reply later.
    Narive API are APIs which works in lower level than Win32 API (or other Windows API) and those Win32 API will finally be translated into Native API. Most Native API works in kernel-mode, but Win32 API are user-mode.
    But don't ask me about Windows internals.:D
     
  16. Rasheed187

    Rasheed187 Registered Member

    Joined:
    Jul 10, 2004
    Posts:
    14,789
    Location:
    The Netherlands
    OK I see your point, you can not directly hook the kernel anymore, but there are still plenty of ways to communicate with the kernel, which can be used by both rootkits and anti-malware tools. And what do you consider a direct kernel hook? But like I said, perhaps you can refer to the pic. Which one is related to Native API hooking?
     
  17. 142395

    142395 Guest

    Of course there must be always plenty of ways to communicate with the kernel, otherwise we can't enjoy computer. But I don't think there're plenty of ways which can be used by rootkits. Most 64bit rootkits actually attack kernel driver, not OS kernel. Because in Windows kernel-driver have same privilege with kernel, it's quite powerful.
    Most of banned hooking by PG are direct kernel hook I think.
    Native API hook is a name classified on "what" it hooks, so it's different from your pic which is classified on "what technique is used" to hook API.
    I think inline hook, SSDT hook and sysenter/syscall hook will be used for Native API hook but maybe more.

    I ran GMER to see what hook SBIE use, and here's result (only part of the log because Wilders said original log is too large).
    I used clean Win7 OS image because somehow GMER didn't run on my usual setup, and launch IE under SBIE, then ran the scan for 3rd party components with all options on. There seems to be only inline hooks in user-mode but it's the deep hook I mentioned and it seems they actually hooking Native APIs.
     

    Attached Files:

  18. CoolWebSearch

    CoolWebSearch Registered Member

    Joined:
    Sep 30, 2007
    Posts:
    1,247
    OK, but you said this:
    "As long as we keep focusing on practical situation, either Chrome alone or SBIEing Chrome will be fine, there's no difference btwn them for robustness against browser exploit.
    But don't forget nor underestimate that SBIE provides what Chrome sandbox doesn't provide, and these advantages can be good enough reason to SBIEing Chrome."

    So, what about other exploits, you're talking about browser exploits, but what about all other forms of exploits and bypasses and vulnerabilities, is there a difference between Sandboxie and Google Chrome?
    Which exploits/bypasses/vulnerabilities Sandboxie can block/contain actually and protect against, and against which exploits it can't?
    Which exploits/bypasses/vulnerabilities Google Chrome can block/contain actually and protect against, and against which exploits it can't?

    You also said the following:
    "But don't forget nor underestimate that SBIE provides what Chrome sandbox doesn't provide, and these advantages can be good enough reason to SBIEing Chrome."

    Do you mean here on virtualization and restrictions (as far as I remember) or something else as well?
    What are all the advantages and all disadvantages of sandboxing Google Chrome with/inside Sandboxie?
     
  19. Rasheed187

    Rasheed187 Registered Member

    Joined:
    Jul 10, 2004
    Posts:
    14,789
    Location:
    The Netherlands
    Thanks for the info, I understand it a bit better now, but I will still need to do some more reading. So if I'm correct you're saying that SBIE probably makes use of inline and SYSENTER hooks? SSDT hooking is not possible of course. About the GMER logfile, interesting, but they are all user mode hooks like you said yourself.
     
    Last edited: Nov 19, 2014
  20. 142395

    142395 Guest

    What Chrome covers are code-execution exploit against browser and plugins (but only when you enforced plugin-sandbox. By default Chrome asks you when a plugin tries to access PC, IOW it asks you whether you want to disable plugin-sandbox. you can change this behavior through setting), and code-executon exploit via PDF when you use built-in PDF viewer.
    All other exploits are basically out of scope, with some exception when you enabled --enable-strict-site-isolation flag. This flag enforces '1 process per 1 page' policy and eliminates some of information theft vulnerabilities (also isolates memory-only malware).
    SBIE OTOH, also care about downloaded programs and documents as well. So it also covers code-execution exploit via Office document and local exploit by malicious executables.
    Both of them basically do nothing against info theft vulnerabilities such as Cookie theft, XSS, or SSL/TLS related vulnerability (I mentioned some exception though), and DoS vulnerabilities.
    Both of them basically do nothing against kernel vulnerability (there can be some exception in Chrome, but don't expect much).
    I think major advantages are mentioned already, but I'll add one more particular case. I use sandboxie even for legitimate software installation. This is because sometimes my setup interferes installation and might cause incomplete installation. I really hate such thing so I firstly install it in a sandbox to see if problem occur. If it occur, I can address this before real installtion. Of course it doesn't always work becuase sandboxed environment is different from real, and it anyway don't accept driver. But overall this strategy works well for me. Here you see sandboxie is actually not only for security! OTOH Chrome sandbox is only for security.
    The most disadvantage will be incompatiblity with particular apps. Actually in my system Chrome 64 bit with Norton interferes with SBIE even w/out DropMyRight.
     
  21. 142395

    142395 Guest

    I'm not sure about what method SBIE use, but at least inline hook is confirmed.
    As to GMER, it might be possible that kernel-mode hook was not used by chance because I only launced IE under SBIE. I'll test again with more stress on SBIE e.g. try to install AV in sandbox or try to elevate in sandbox, maybe next week.
     
  22. deBoetie

    deBoetie Registered Member

    Joined:
    Aug 7, 2013
    Posts:
    1,832
    Location:
    UK
    The other forms of info theft (scanning/exfiltration of data from drives and MyDocuments) are also important. My understanding - please correct me if wrong - is that the Chrome sandbox does protect MyDocuments, but Sandboxie is capable of much more granular permit/deny using the file restrictions settings. And that is very important to me.
     
  23. 142395

    142395 Guest

    Chrome renderer process don't have any access right (including read access to folder or registry) by itself, so it asks broker to do things like download (connect internet and write to disk).
    What is permitted or not permitted are all depends on policy, so theoretically there can be a hole which escaped many of prying eyes.
    However in general, it's quite hard for attacker to steal user file because he have to find a hole which allow him to access file and send it to remote server w/out violating the policy. What file can be accessed and what action is allowed are strictly restricted by dynamically generated rule(s). Also attacker have to remotely do this, but usual download or upload involves user-input.
     
  24. deBoetie

    deBoetie Registered Member

    Joined:
    Aug 7, 2013
    Posts:
    1,832
    Location:
    UK
    Great, good news, thanks. So essentially, it's only cases where the broker is subverted that you'd get disk access (which would then be controlled by Sandboxie if configured that way).
     
  25. Rasheed187

    Rasheed187 Registered Member

    Joined:
    Jul 10, 2004
    Posts:
    14,789
    Location:
    The Netherlands
    I've read a bit more, but I still don't understand everything, it's sometimes a bit confusing. It's best to ask it on the SBIE forum. But I do wonder what the difference is between the current methods that are used and the SSDT hooking method that was used in SBIE v3 on Win 32 bit.
     
  1. This site uses cookies to help personalise content, tailor your experience and to keep you logged in if you register.
    By continuing to use this site, you are consenting to our use of cookies.