Jump to content

joakim

Member
  • Posts

    153
  • Joined

  • Last visited

  • Donations

    $0.00 

Everything posted by joakim

  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. 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.
  7. 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.
  8. Lets try another approach then.. What makes you think it does not work for you? (elaborate)
  9. 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.
  10. 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/
  11. 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).
  12. 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
  13. Yes feedback would be nice in order to solve it.. Did the test version work better for instance?
  14. 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.
  15. I must admit it is several years since I did this, but I remember noticed strange things about different versions of bootmgr.exe's. Read this thread; http://sanbarrow.com/phpBB2/viewtopic.php?t=1705 (maybe aim at page 2 and 3). My tests where done on Windows XP and tfpd32. Maybe there's some usefull information in there.
  16. Trust me, bootmgr has every single byte of bootmgr.exe, plus some more (16-bit). It's just that bootgmr.exe is compressed when residing "inside" bootmgr.
  17. Being a little picky, but it would be more correct to say something like; "BOOTMGR and BOOTMGR.EXE are actually the same file, but the first has some added code (16-bit) to make it a suitable local boot target"
  18. I don't understand the problem if there is any. Or I misunderstood the question..
  19. Since I don't have much time these days, I'll tell you how to. With a hex editor overwrite the string either by 00's or something else. For the 300KB: String is found at offset 0x1f78 For the 960KB: String is found at offset 0x9578 Sorry for the inconvenience.
  20. I never thought of it that way, and I understand your point. So if I were to change it, what would the preferred neutral name be? A few suggestions: BOOTSDI WINPE SYSTEM ROOT BOOT
  21. Did I miss something here? Please explain what makes a difference and how.
  22. Hmm, I can't remember if I put in some messages. Either way, I'm preatty sure they won't make any difference to you when booting Don't worry be happy.
  23. I am not sure if it was this one I used for the test; http://www.mediafire.com/download.php?8lxw24t00xaaef6 (960 KB) but it may look so. It was never handcrafted the way 300KB version was, so can probably be shrinked a bit more. I just don't have the time for that now, but you are free to give it a try. It's a nice exersice
  24. Grabbed one of my older 900 Kb versions and that booted fine, so I presume Windows 8 needs some "free space" inside the tiny partition to be happy wimbooting.


×
×
  • Create New...