Jump to content
OGXbox.com

xxkryptos

Members
  • Posts

    11
  • Joined

  • Last visited

Recent Profile Visitors

The recent visitors block is disabled and is not being shown to other users.

xxkryptos's Achievements

Rookie

Rookie (2/14)

  • Collaborator Rare
  • Week One Done
  • First Post
  • Conversation Starter

Recent Badges

4

Reputation

  1. > That's because it loads the BIOS through the LPC, so the xbox will need access back to it just like a PC, which obviously its based on. I'm not trying to be a dick. Hopefully not coming across that way. But why? This is not "Obvious" to me. Calling back to bios / firmware is a relatively new concept. I won't believe that the xbox does this until you show me the asm.
  2. This is nutty to me. I will try it soon. I don't doubt that it's the truth. First thing I'd do is let the kernel get loaded, search for some code signature in kernel land, then disable the signature check in the loaded kernel. The kernel exports are a little difficult to figure out, but you *can* edit high memory and do this. Hell, even if you can't do it by the API, everything runs in kernel mode and you have free reign. "You" means TX or whoever btw, not OP. I think they could have had a better product. Where does X3 / clone hand off control? You could compare high memory to a real console (Your console with the chip lifted). What gets modified? anything? Would love to see this under the debugger.
  3. > Call back to the lpc bios function seems out Can you elaborate on this? My mind might be fogged up by modern day UEFI booted systems calling into runtime services. Kernel is loaded into memory at this point. You've booted up and ran unsigned code. If you need to reach back to the LPC bus for services then maybe its a chip issue. I don't know where or why this would happen, but I'm not well versed? What BIOS callbacks are you talking about? Edit: This seems like a kernel issue to me. Maybe? You load an unsigned dash no problem. The dash probably calls back to the kernel to do an executable load. At this point it freaks out. In my mind, the chip did its job. If something doesn't maintain control after this it's another problem.
  4. Double post, but it's been a day and I've solved my issue. The pin I was trying to power from was "VCC-TARGET". This pin is intended to detect the voltage off of your target board. Your target board will not always be running on 3.3V so this lets the JTAG device know what voltage it should be talking to the board with. Keep it connected, but do not expect it to power your board. You will need to power the modchip with an external power supply. As I discovered, some cheaper power supplies will cause issues. I can't tell you why, but hopefully this thread is anecdotal evidence that not all power supplies equal. I've successfully applied external voltage with an Adafruit Trinket 3V and a Bus Pirate v3.6a. With the Bus Pirate, I had to connect via serial, select UART mode, and enable power with the "W" option. I'm sure other supplies will work, but this is what I had handy. Another notable thing. I was using the `jtag` binary after installing `urjtag` on Ubuntu. This hangs or crashes after the detect command. This is probably because the software freaks out when it can't find the Lattice definition file on your computer. The 'urjtag' code in the Ubuntu repository is old and does not gracefully exit upon this particular error. This has been fixed by the people maintaining urjtag. The version in the Ubuntu repositories is from around 2007. Build the newest tagged version from source (or download it) and install it. The install makefile option is a little jacked too. You might need to copy a specific library into your path, preload it, make sure it gets loaded, etc.
  5. Daaaaaang! Can't believe how dead this comment section is. This is cool as shit. What'd you print this on? Did you have to fit pieces together? Is the jewel a sanded OEM jewel? How did you bond it? Did you fit an xbox motherboard in there? What are the dimensions? Did you try to size it to the real thing? I'd love to see alpha 1 hardware in there. Super cool!
  6. I recall doing this some time ago with a DB9 serial doohicky and the software ponyprog. I was able to do it more recently on a DVT4 with a BeagleBone Black and some test clips. There are no-solder options for recovering the HDD key, but you might need to find the right clips. Some are girthier than others Is FatXplorer still the go-to software for creating drives? Wasn't that some C# GUI program with loads of adverts to buy the full version? The other options were to run some linux boot disc just to run one utility right? Couldn't one write a program to simply write an image to a drive like a dd wrapper... hell, just instruct the user on how to use dd. Then send ATA commands to program the drive with a key? Obviously the problem here is distributing Microsoft binaries. Can't assume the user has a whole hard drive image laying around. So instead, it's assume that the user has all the files needed to create a hard drive image. I get it, but it's stupid. Write image, set key, done. To OP: Like others have said: read EEPROM, get the key, create a new drive, or install a modchip that lets you use an unlocked drive. You might still need to have specific files on you hard drive. Begin by checking if the drive you wish to replace with is supported. I don't know exactly why a drive would be unsupported or not, but these are good bets.
  7. I'm trying to write a bitstream to a spare Aladdin XT2 Plus modchip with a knock-off USB Blaster. The USB Blaster in question is one that came with an AliExpress FPGA dev board. It looks like an official product, literally says "USB Blaster" and "Altera" on the sticker. One of those knock-offs. I only mention this because it could pertain to the issue. The github page linked says to externally power the modchip, which I am doing. I've found that if I connect 3.3v from an Adafruit trinket and leave the 3.3v line from the USB Blaster connected, I am able to run `urjtag` on Linux, connect the USB Blaster, and run the `detect` command. This reads out the device ID and hangs. I give the process a `SIGINT` and it segfaults. Seems promising, but I don't trust this to write the configuration to the chip. Possibly an issue with `urjtag`, but I can always debug that myself. Should the USB blaster be providing 3.3v while there is an external source providing 3.3v? This doesn't make sense to me, but it's the only way I've been able to get a partially successful ID from the Lattice chip. I also have this power supply. It takes my 12v wall wart and gives me some nice 3.3v headers. I've double checked with a multimeter and it seems to do what it says. When I power with this, it does bad things to the USB Blaster. I tried first without the 3.3v line from the USB Blaster and again with the 3.3v line connected. Both times, the USB Blaster is not even detected by my computer. It takes a minute or two of being unplugged before the USB Blaster is recognized by my computer again. This particular power supply has an on/off switch. I can switch it to off, plug in power leads to the modchip, and this still messes up the USB Blaster. It won't be detected even though the external power source is turned off. What could be causing this? Completely out of scope, I've heard that the Xecuter 3 uses a Lattice chip in the same LC4XXX family. From what I understand, they scrubbed the markings on the CPLD and made it look like an Actel chip to make cloning more difficult. There's a schematic publicly available, but from what I can tell, it requires transplanting chips from a working Xecuter 3. I seem to recall hearing that they locked the chips during manufacturing so the configuration / bitstream couldn't be copied. Does anyone have any recollection of this?

Board Life Status


Board startup date: April 23, 2017 12:45:48
×
×
  • Create New...

Important Information

By using this site, you agree to our Terms of Use.