|
  |
 The “ultimate Dashboard Exploit” Aka Ude, Official thread! |
|
|
| rmenhal |
 Jun 17 2004, 07:21 PM
|
X-S Senior Member
Group: Members
Posts: 254
Joined: 3-May 04
Member No.: 117780
Xbox Version: unk
360 version: unknown
|
| QUOTE (PedrosPad @ Jun 17 2004, 08:33 AM) | | rmenhal, your posts after this focus on kernel-specific exploit fonts, yet still claim to contain an, albeit tiny, 'generic' font. This has left me slightly confused. Why the need for kernel specific-fonts if the 'generic' font does actually work? Please can you give me a few words of explanation? (when you'd use 'generic'?, and when you'd use kernel-specific?), and I'll include them when I next update the root post. Ta. |
First of all, both of the new generic and kernel-specific fonts are improvements over the old ones. They're much smaller, because there's no need for the landing zone or catch net anymore. They're so small now that there's really no risk of bert overflowing off the heap anymore.
The generic font, like all fonts before, still rely on an exact stack position. I think there are two weird situations, which on some boxes cause the stack to shift lower than what is usual:
1. For some boxes, the evox reboot features do this.
2. When some application/game manages to crash the kernel real good. On some boxes, the stack has shifted for some reason.
About 1: my xbox doesn't have this problem, but I guess at least Tomilius' box did. Also, I remember reading catfish installer readme (?) where he mentioned that he had to remove the reboot entries from evox menu, because the audio exploit wouldn't work after that and would just get corrupted. The only reason for audio exploit to not trigger is that the return address pointer in the stack is in a different place than usually. It just misses the mark.
About 2: YoshiKool described something along these lines. I've also several times managed to get - both swappy and swapless - audio exploit to not trigger and get corrupted on next boot after a nice kernel crash.
It's also probable that regular bert'n'ernie fonts have the same problem. But I think they happen to crash in a away that just causes a reboot once or twice. However, update.xbe happens to crash in a away that freezes the box. Freezing is a not problem if the user sits next to the console; just power cycle and the box works. A frozen box wouldn't make a remote Linux admin happy, though.
The kernel-specific fonts solve the problem by using a fixed location in the kernel. This location was determined when MS compiled and linked the particular kernel version. These fonts don't rely on any exact stack locations.
I provided the generic font, because I'm not sure if all the kernel versions are covered yet. Some post in these forums listed kernel versions, and it looks like we're still missing 4036 and 4972. I've never seen these versions mentioned elsewhere, though. 4036 could be a mistyped 4034 and 4972 looks more like an Xecuter version (or maybe X2 is based on 4972?). Are those two versions real?
|
|
|
|
| |
| dubey |
Jun 17 2004, 07:22 PM
|
X-S Member
Group: Members
Posts: 132
Joined: 9-July 03
Member No.: 48744
|
| QUOTE (Angerwound @ Jun 17 2004, 08:14 PM) | My release:
Hex edit the locations at the bottom of the .xtf file with the ones you desire. I suggest editing the ASM code and using NASM to recompile the XTF, much cleaner.
rmenhal's:
I haven't exactly gone about editing his code as of yet however, I'm almost positive its as simple as hexediting his .xbe with the desired locations or editing the ASM(if included) as stated above. |
how do i know what release i have lool
I downloaded the UDE package at "the usual place"
|
|
|
|
| |
|
|
|
I dont know what use that would be to you guys though..
They'll have ROE, as before.
