It's not so much knowing what M$ is looking for but knowing what should be there on a retail console, and then writing your own code to create a response based on that.
The kernel only communicates with the HV through syscalls ("sc" instruction). Besides the functions in the syscall table I'm pretty sure the kernel doesn't communicate with the HV. Unless you're talking about something else.
edit: post got ruined, what dwack said lol.
Maybe I'm missing something, but if you want to disable internal memory why don't you just patch the routine in the kernel? What're you worrying about HV for?
A server was used to sell it like a service. It's much easier / more stable to locally load a clean hypervisor from your Xbox hdd and locally generate a valid response.
You're misinformed on a lot, like how you keep including me in XBLS business matters for some reason. But anyway, I don't really understand what you're trying to say in regards to them abandoning anyone. If a cable company goes under do they continue to supply their old customers with TV and...
I wasn't speaking for myself lol. I was referring to xbls offering their service being more beneficial to the scene then you sitting here not doing anything.
As for your question I was not directly involved with them. Also they don't owe anyone in this "scene" anything. It's not like there's...
lol you're right bro. I would much rather waste my time complaining about a modding scene that I dont contribute to on a meaningless forum then contribute to the scene and make money at the same time.
IIRC xebuild patches use the mapped memory addresses, so you just have to load the kernel with the correct loading address (0x80040000) and your addresses should line up with xebuild's.
Wouldn't it be easier to release something that loads the HV locally? It really makes me think these kids were leaked/stole files that they don't even know how to use. If they really wanted to "crack" XBLS they should patch all the server calls and patch their binary to load the HV locally.
But...