joakim

Member
  • Content count

    153
  • Joined

  • Last visited

Community Reputation

0 Neutral

About joakim

Profile Information

  • OS
    none specified
  1. Could you be so kind and translate the text in the messagebox into english? It's easier to understand then.
  2. Did you get results other than what we found back in 2009? See: http://reboot.pro/topic/9177-scratchspace-at-1024-ramdisk-size/
  3. Just mentioning it before I forget about it again, that at some point during some reversing I found that the $LogFile's smallest size can actually be 200 bytes. And not 256 as earlier suggested. So, if you want to, you can create even smaller NTFS volumes, as a PoC or project or whatever. I certainly don't remember any offsets, but the patch was almost identical to the already posted details (for XP), and it was performed on the wow64 untfs.dll on Windows 7 x64.
  4. In any case, settings and configurations like those written to registry, are not kept over a reboot when in WinPE. It is only kept in memory.
  5. @laddanator Do you have a screenshot of what it looks like, the stuff you want to tweak? Is it efi system or not? Btw, it's probably about time to start a new thread, and request help for a very specific challenge..
  6. Really cool! Thumbs up.
  7. The speed is partly due to autoit scripting overhead, but also coding style I presume. Source is available in download section along with compiled binaries, and in the source section where you can browse it and track changes. You can modify and use it to whatever you like. I don't have time to support it right now, and likely not this year either. Point is it takes a lot of time.. Btw, it is gui compiled in current version.
  8. Just adding some input regarding my own stuff. mft2csv does in fact let you choose (when starting the program) how timestamps are given (local time vs utc). Although not implemented yet, I had a wish to implement configurable output. The format of timestamps can also be changed without too much fuzz. The source is provided and I actually asked for suggestions at forensicfocus regarding timestamp format. The drawback with my tool(s) as they are rught now, is: Slower processing than most other. Missing full path However implementing full path is not that hard, so we'll see.. Not sure about the current state of analyzeMFT, but I was in contact with the author some time ago regarding missing fixups (which is important). That tool was of very much help for me in the beginning, and I studied his script well back then.
  9. Lets try another approach then.. What makes you think it does not work for you? (elaborate)
  10. Of course! If you succeed in creating a process with a duplicated token of the trustedinstaller, your process will hold a true duplicated token, and your system will not be able to distinguish it from the trustedinstaller.exe itself, at least when it comes to privileges. If you did not succeed in creating such a duplictade token with the tool, the console output should give an indication of what the issue is. So please post it if that's the case, or else it's pointless. Either way, bear in mind that certain registry key have rare permissions set. For instance 1 weird account has access, but not the trustedinstaller. If that's the case, then not even the trustedinstaller will have access. However, a process with such a powerful token, should have no problem adding the necessary permission to those keys, so try that.
  11. Now both tools have been updated to fix the issues described. Please report back any issues with it. Available: http://reboot.pro/files/file/237-runassystem-and-runfromtoken/
  12. In short, and as the name could imply, RunasSystem will let open any program in your session as local system. That is nice and very easy. However, sometimes you may want to mimick a certain token by creating a new process with a duplicated token, with more power that what winlogon.exe would give you, for instance the trustedinstaller. But for creating a true duplicate (something devxexec actually don't) of the trustedinstaller's token, we must be local system in the first place, hence the requirement for the strange procedure that not everybody understood. It is thus for that reason that RunasSystem must launch RunFromToken, in order to access and create a primary token (duplicate) of for instance the trustedinstaller. This requirement may not be necessary when creating duplicates of other less picky process tokens. In addition, to the above requirement, I noticed that you may need certain privileges on the process in order to use the functions like CreateProcessAsUserW and CreateProcessWithTokenW. That is for both the tools, as both of them use those functions. OK, I'll upload new version of both tools later today, that will also add to your account the necessary right if missing (so that it can also be enabled when necessary on the fly).
  13. There is only a test version of RunFromToken because that one require certain privileges enabled on its process. That's why I was hoping for some feedback on how the test version behaved in regards to that. As already explained at reboot.pro there is a chance that the right/privilege is not added your account, which will prevent you from enabling it if it does not exist in the first place. That too, I already have a version for, but I'm awaiting some feedback
  14. Yes feedback would be nice in order to solve it.. Did the test version work better for instance?
  15. The syntax has not changed, so the same command should work in Windows 8 as in Windows 7. Try "bcdedit /set {default} testsigning on" Feedback to the console should give you a clue about rate of success.