Maybe to clarify a bit (as much as I know about hardware support for virtualization, I could be wrong): The VMCALL instruction can be made from anywhere, it is up to the hypervisor to determine the VTL and whether or not the caller was allowed to make it. I have never tried it, but I imagine you fault or get an access denied error if you try to issue a VMCALL instruction from userspace with an otherwise properly-formatted input code page. User/kernel communication is usually done through a driver, then the driver can make the VMCALL from ring 0. So to answer your question, yes it is easy to step into with a debugger since there isn't any protection on the caller side, it all happens on the callee side. You need to have a kernel debugger attached to see it happen though. Happy debugging-
There are some tutorials out there on using a split named pipe to talk to the HV from an established KD session you might look into. I have never tried it myself.
Could you direct me to one of these? Depending on what you mean by "talk to the HV" that could be useful. As far as the other stuff goes, I'm at the point where I can step until I reach the systemcall (VMCALL) trap instruction in the kernel, but once that instruction executes I can't step into the hypervisor's handler... I know this is by design, and just thinking about this makes it sound impossible as being able to kernel debug relies on the kernel being effectively a guest to the hypervisor, but I figured I might as well ask.
Ha I'm actually up against this exact thing right now on the PC side for the last 2-3 days. Conceptually I know it is possible, I just have to find the right magic spell. Most things I have found seem to be a derivative of this: http://www.securitylab.ru/contest/444112.php He does some really weird shit at the beginning of the article for reasons I don't really understand, and I don't speak Russian (unfortunately)... It looked the most promising but I was holding it off as a last resort as I have a few things left to try first. Maybe it will work for you.
Lmao thanks for the help but I'll hold off on the obscure Russian documentation for now, maybe I'll come back if I'm very desperate . I'll just do static analysis on the HV, its no big deal
I see. Well there are some pretty big bug bounties there if you do manage to find something with a POC...
Just to be clear here, I am working on the Xbox 360 hypervisor... I know it will be similar to HyperV and looking at how HyperV works can be valuable but I just want to make sure there wasn't a miscommunication somewhere. I very much doubt there are any bounties for the xbox, but good luck in your research and thanks for the docs anyways. Here are some English sites talking about the same stuff as the Russian source -- the HyperV host can enter debugging mode which allows you to trace through the hypervisor itself; this will not apply to the 360. http://hvinternals.blogspot.com/2015/10/hyper-v-debugging-for-beginners.html http://en.community.dell.com/techcenter/virtualization/w/wiki/3029 https://docs.microsoft.com/en-us/wi...debugging-hyper-v-via-a-1394-cable-connection https://docs.microsoft.com/en-us/wi...ing-hyper-v-via-a-null-modem-cable-connection
Yeah I'm aware. They aren't that dissimilar from what I understand, but I could be wrong. Mostly I'm going off what others have told me. In any case I didn't see any talk about Xbox either way, but $250k for RCE would probably worth clarifying at least https://technet.microsoft.com/en-us/mt784431.aspx Best of luck-
Blah.. thought I replied to you earlier but seems it didn't go through... Yeah I'm really not that sure what it's for actually, when I wrote my earlier post I was confused between it and the LDV stuff, only realized that after rechecking RGBuild. It could be CPU key related, or might even just be a random array of bytes as a kind of nonce/confounder to help with the per-box data security, checking the bootloaders would be the best way to see how it's used. If it's not used in the bootloaders it could be used in HV/kernel though, at least I remember seeing some subs grabbing data from the bootloaders, not sure if they were still in memory or if it was reading from NAND though. Heh thanks, it's no problem, glad I could help people out Anyway I thought they ran the same kernel? IIRC it just changed how it did things based on the KV console type, I think one of the RGL patches actually just removed a single check for it, and then you could eg. use a shadowboot based on RGL to make a 'true' test->dev (although I guess generating a dev KV would probably be the easiest method) I think that's at one of the reset vectors, can't really remember right now though... There should be some IDC scripts floating around which could name all the vectors + a few subroutines, I think my own one managed to name around ~70% of the HV subs, but I know other people have made much better progress naming/scripting the HV + loaders, let's hope one day that someone will decide to release their info You probably know this but HvxDump makes use of that stuff, if you want to know how to use expansions you can probably just search it for sc opcodes, to find where it passes the expansion to HvxExpansionInstall and how it gets data out from it etc. Actually I think I wrote my own clone of it years ago to learn how it all worked, if I find it I'll send you the source if you'd like. Pretty sure that had a detailed mapping of the expansion header too. I think the key used to sign expansions was changed to a non-public one not long after HvxDump released though, so you'll probably need an earlier recovery or a patched kernel to make use of them. Pretty sure retail has all the dev ones removed with the table entries set to 0, but test/dev should be the same as each other, like I said above I'm pretty sure they use the same HV/kernel. Heh yep, quite a few pieces of code from the kernel (mostly security stuff, XeCrypt*, memcmp..) seemed to be shared with the HV and even the bootloaders, that's pretty much how I wrote up my own BL/HV scripts. With RGL we never had any HV symbols, but luckily we had kernel ones Don't really think I do Most of the useful stuff I wrote on there (STFS, FATX, bootloader headers...) probably ended up merged into free60 anyway. I think there might have been some guides on how to setup IDA for loading bootloaders/HV too, maybe even had my IDC scripts on there... but that's all lost to time now (I might still have my scripts though, I'll see if I can dig them up later) And at one point we did have every POST code mapped, not sure if that list was ever posted on there though. EDIT: also I should note that I could be completely wrong about the test kit stuff, since I've never actually had any experience with them, the shared kernel part mostly comes from recoveries only having a single kernel image from each board, though maybe test kits used special recoveries, or maybe I'm wrong and they did have seperate test kit images inside too... please correct me if I'm mistaken
I looked into it a touch more and it looks like it might have something to do with the MAC address and a few other values I didn't recognize. I might go back later, but it was really just a passing curiosity. The reason why I thought they were different is because of the different symbol / kernel executables from the SDK. There is xboxkrnld.exe and xboxkrnlt.exe. They are different files, krnlt is missing some subroutines IIRC. Do you know what all those different kernels could be? I ended up finding a very helpful IDC script from the xboxhacker days, it might even be yours I'll ask around if anyone has any withholdings on making it completely public The existence of HvxDump was what kept me looking for answers, but if the key was revoked then that idea is out of the window I suppose... That would be fantastic! That's a shame. Is there anything more to loading bootloader/HV as PPC? If there is something else that would make my life easier there I would love to see it
Other than using an IDC script after loading it I don't think so, never saw any plugins or anything released for them, wouldn't be surprised if someone did make a plugin that could handle it all though... Ah yeah I think you're right actually, looking into the recovery they also have 2+ xboxroms for each board, never thought of the extra ones being for test kits really, like I said before I always guessed test kit stuff would just be a few checks or something. Could be that test kits kernels are closer to retails to make the test environment match better, can't really see any other reason for them to use completely different kernels/HVs... I think Sony test kits are kinda like that, pretty much just retails that can run unsigned code, with no debug functionality at all. I wonder what happens if you do try to force the proper dev kernel to run on a test kit then? I'd guess there's probably checks to try and stop that, but those should be pretty easy to bypass.
I was referring to ISO recoveries which only have 2 shadowboot ROMs. The remote recoveries are a can of worms I haven't dared open up. I saw that there were 60+ ROMs from 2005 onwards (targeting? newer flash versions throughout) and looked no further. I didn't know they had any information about the motherboard? I assumed the reason why the 3BL was seperate on devkits/shadowboot ROMs was so they could have enough space to store the init code for any motherboard and make generic images (seeing as they have plenty of NAND flash space)? That's a pretty reasonable explanation. I have a few ideas about doing that, but without a test kit of my own (because I would probably end up fucking it up...) I haven't been able to test much. I really want to try just flashing a dev NAND to a test kit to see what happens, because from what I can tell it should work just fine. Shadowbooting would be a way to test that theory out, but it's a catch-22 where (I think!) test kits use a different key to sign the ROMs, and you can't get past that without running the dev kernel. Side note: it doesn't make a whole lot of sense to be calling shadowboot images ROMs. The whole concept of ROM files probably comes from dumping actual ROM cartridges for older consoles, but that whole idea just doesn't exist in the context of the 360.
Remotes have the 1888 base per mobo for some reason, and then the recovery-version kernel for each mobo too (no idea why there's so many different ones per mobo though, could be something to do with NAND type too perhaps), the motherboard info comes from a field inside the SMC. I actually forgot that ISOs have shadowboot files in them heh, not really sure about how 3BL is stored in them, I wonder what the SMC in those says, if they have an SMC at all, doubt shadowboot images would really even need an SMC. As long as you have an external flasher it'd be pretty safe I think, NAND-X worked well with my kit. Hardest part is probably finding a test kit at a decent price it's actually kinda funny how test kits seem even more rare than dev kits these days. That's possible, I guess you could probably check that by comparing the bldrs in the xboxromw2.bin against the xboxromtw2.bin, doubt they'd use different bootloaders, so if the signature is different between them you know it's using different keys. Heh true, IIRC the original Xbox had its images called xboxrom.bin too though, maybe orig Xbox kernel couldn't be rewritten once it was flashed.
Haha we took different approaches to analyzing shadowboots. I probably made some generalizations about all shadowboot images seeing as I only ever looked at those from ISOs. The ones in ISO do have SMC, I haven't touched the config though. Yea I would do that myself, I just wouldn't want someone testing for me to have to take it apart and wire up a flasher if it bricks. I've been looking for a cheap one, but all I've seen are sealed jaspers for an arm and a leg. As soon as a cheap, beat up xenon or zephyr comes up I'll be on it
Ive got a loader for IDA for bootloader that I started like 3 years ago. If you want we can bring it back from the dead. Right now it only really does 2bl.
What would that look like? You open the shadowboot ROM, how do you select which boot loader to analyze? I didn't think you could do interface stuff like that with a plugin. I haven't had any issues just extracting all of the parts so far, but if there is a good way of doing it that makes the process easier I'm definitely interested
This was more for specific bootloaders already extracted from a nand or rom. If you wanted to not have to manually extract them, I'm sure there is a way to load the specific bl into ida right from the rom.
Ah I see what you're saying, that makes a lot more sense. Yea that would be helpful, a loader that would read the name of the boot loader and label accordingly
I still have my xenon I don't mind testing on, and I have a nand-x. I can flash whatever you want me to. Lol
Neat, that's an actual loader plugin too? or is it an IDC script? I made a few scripts for loading the BLs which worked pretty well, but a proper loader would be a lot better imo. I've never really worked with the IDA SDK before though, if you have a starting point I can probably try adding some stuff to it. Most of my script just named things based on signatures though, idk if IDA SDK supports doing things like that. Also I think a loader that just loads up the bootloaders in extracted form might be better than a loader that loads from a NAND/SB image. Seeing as you could only really have one BL loaded at a time, if you were loading from a NAND image you'd still have to make separate databases for each loader anyway, kinda makes any code for loading from a NAND image redundant in a way... Especially since there's already plenty of tools that can extract loaders from a NAND for you (then again I haven't actually seen any truly open-source tools that can do that though, RGBuild comes close since you can always decompile it, but the code was never actually released... hmm)
