xbox-scene.com archived forum

Please login or register.

Login with username, password and session length
Advanced search  

News:

xbox-scene.com forum restored.  registration disabled.  thanks to xboxexpert for the db dump and netham45 for cleaning it up!

Pages: 1 2 3 [4]

Author Topic: Let The Hacking Begin  (Read 356 times)

HoRnEyDvL

  • Guest
Let The Hacking Begin
« Reply #45 on: January 22, 2007, 03:51:17 AM »


By black listed im not just talking about xbe's im also talking about the kiosk disk etc.




Logged

vax11780

  • Guest
Let The Hacking Begin
« Reply #46 on: January 23, 2007, 06:42:06 PM »


Well not sure they will always release a patch cause once you know how the system works it will be much easier to hack or decrypted the update to view what's inside of that update and then we could modify it to not check the signature of the update...But don't think of that in a short future cause it will not be easy to crackdown that system


This is basically what happened with the PSP. The original firmware (1.0JP) was easily cracked or maybe not even encrypted (if forget which.) Then it was just a matter of stepping through the code watching what it did to the system update and duplicating the steps to decrypt the new firmware. A few carefully chosen patches and voila! the new firmware is loaded from the memory stick with new exploits added.

VAX





Logged

jaimebenlasnow

  • Guest
Let The Hacking Begin
« Reply #47 on: January 24, 2007, 08:04:37 AM »


But you guys out there will think this is possible well try to decrypt SHA-1 and then talk to us...But there's also something on the flash thing that could help us:

QUOTE

The layout of the flash by Garyopa:

I was doing some work on the 16mb NAND dumps containing the dashboard, kernal, etc.

Here is my original notes, which I sent to "Robinsod" and he has done some amazing things since.

Plus "Probutus" has released a program which can extract the files from a 16mb NAND dump.

I wanted to be the first to start a TOPIC on this new section, and lets keep this topic updated,
on the format of the 16mb NAND and the layout of each section and the block headers, so maybe
in the end we can get to work on decompressing and undecoding each section and hopefully get
the point of truely understanding the internal working of your x360 console, etc.

-------------------------------------------------------------------------------------------------------------
The 16mb NAND flash is not completely encrypted, it basically is a Microsoft compressed ROMDISK system.

It contains a small header, then a "encrypted" loader, and then a number of stored files in a "compact flash"
file system, these files match byte for byte the updated files in the "system_update", and are basically the dashboard files in stored signed Microsoft X360-XEX2 file format.

First a 4K header always the same, nothing special.

Then we have a 28,672 byte chunk of code starting at >1000, which looks encrypted and for the SMC,
but for some reason it is interchangable between systems, even tho it is different on each dump.

Then we have two small chunks with headers of CB and CD, whick look like start-up code for the CPU,
also different in every dump, and first CB is sometimes 26,080 bytes long and on other dumps it is 25,056 bytes long (why?, Pal, Core, more info on the dumps are needed first), and the second CD is always 22,256 bytes long.

Next we have the main kernal with a header of CE, which is the brain behind the dashboard,
and is always 352,368 bytes long.

The last two sections CF and CG are patchs or updates to the main kernal.
Sometimes there is none (factory fresh, no games played or live updates),
so the flash will have no CF and CG chunks, then first two appear (most likely from game discs),
and then more appear (most likely from live updates).

But the CF and CG always appear in chunks of two, and never see more than four in total so far.

The first CF is always 17,600 bytes long and the second CG is always 47,936 bytes long.

The CF chunk has a 32 byte headers on the front of it.
(I guess to tell the system where to patch into the main chunk)

The CB, CD, CE chunks only have 16 byte headers in them.

These headers contain length of the chunk plus a memory starting address for the CPU,
plus a build value/version like "1888", etc.

The CE chunk also has at the end a 6 byte CRC checksum, whereas the others don't.

640K FIXED COMMON BIOS PART (1/2)
-----------------------------------------------------------
>000000 = 4K COPYRIGHT HEADER
>001000 = SMC encrypted code --- Southbridge code, always starts here.
>008000 = "CB" encrypted code --  Bootup cpu code, always starts here.
>00E5E0 = "CD" encrypted code --  Sometimes starts at this address: >0E1E0
>013CD0 = "CE" encrypted code --  Sometiems starts at this address: >138D0
>06C000 = "CF" kernal original    ---  Base x360 kernal, always starts here.
>0704C0 = "CG" kernal original   --- THIS four parts are still encrypted as same as the rest above.
>07C000 = "CF" kernal live ver   ---  JUST the two parts are the "BASE" shipped factory version.
>0804C0 = "CG" kernal live ver   --- And the bottom two are the same until updated by "LIVE"!!

15200K VARIABLE FILE STORAGE AREA
---------------------------------
(Always start at location :A0000)
(But can vary at anytime/updated)
(Think of like a 15MB Hard Drive)
>0A0000 = mfgbootlauncher.xex
>0AC000 = xam.xex
>1D8000 = bootanim.xex
>23C000 = hud.xex
>25C000 = signin.xex
>268000 = friends.xex
>284000 = vk.xex
>2A0000 = updater.xex
>2A8000 = feedback.xex
>2BC000 = deviceselector.xex
>2C4000 = voicemail.xex
>2DC000 = minimediaplayer.xex
>2E8000 = marketplace.xex
>30C000 = quickchat.xex
>314000 = gamerprofile.xex
>328000 = createprofile.xex
>5F8000 = ximedic.xex
>688000 = dash.xex
>904000 = hudiskin.xex
>924000 = (xex2 file)
>928000 = (xex2 file)
>930000 = (xex2 file)
>934000 = (xex2 file)
>A18000 = (xex2 file)
>A1C000 = (xex2 file)
>A20000 = (xex2 file)
>A2C000 = (xex2 file)
>A34000 = (xex2 file)
>A38000 = (xex2 file)
>A3C000 = (xex2 file)
>A48000 = (xex2 file)
>A4C000 = (xex2 file)
>A50000 = (xex2 file)
>A54000 = (xex2 file)
>A58000 = (xex2 file)
>A5C000 = (xex2 file)
>A64000 = (xex2 file)
>A68000 = (xex2 file)
>AB8000 = (xex2 file)
>AC8000 = (xex2 file)
>ACC000 = (xex2 file)
>AD4000 = (xex2 file)
>AD8000 = (xex2 file)
>BBC000 = (xex2 file)
>BC0000 = (xex2 file)
>BC4000 = (xex2 file)
>BD0000 = (xex2 file)
>BD4000 = (xex2 file)
>BDC000 = (xex2 file)
>BE0000 = (xex2 file)
>BEC000 = (xex2 file)
>BF0000 = (xex2 file)
>BF4000 = (xex2 file)
>BF8000 = (xex2 file)
>BFC000 = (xex2 file)
>C00000 = (xex2 file)
>C04000 = (xex2 file)
>C08000 = (xex2 file)
>C58000 = (xex2 file)
>C7C000 = (xex2 file)
>C84000 = (xex2 file)
>C8C000 = (xex2 file)
>C90000 = (xex2 file)
>E58000 = (xex2 file)
>E5C000 = (xex2 file)
>E64000 = (xex2 file)
>E74000 = (xex2 file)
>E7C000 = (xex2 file)
>E84000 = (xex2 file)
>E88000 = (xex2 file)
>E98000 = (xex2 file)
>E9C000 = (xex2 file)
>EA0000 = (xex2 file)
>EA8000 = (xex2 file)
>EB0000 = (xex2 file)
>EB4000 = (xex2 file)
>EBC000 = (xex2 file)
>EC8000 = (xex2 file)
>F38000 = (xex2 file)
>F3C000 = Flash   LAYOUT (1/4)
>F3C200 = Filename TABLE (1/4)
       - mfgbootlauncher.xex
       - xam.xex
       - bootanim.xex
       - hud.xex
       - signin.xex
       - friends.xex
       - vk.xex
       - updater.xex
       - feedback.xex
       - deviceselector.xex
       - voicemail.xex
       - minimediaplayer.xex
       - marketplace.xex
       - quickchat.xex
       - gamerprofile.xex
       - createprofile.xex
>F3C400 = Flash   LAYOUT (2/4)
>F3C600 = Filename TABLE (2/4)
       - xenonjklatin.xtt
       - xenonclatin.xtt
       - ximedic.xex
       - dash.xex
       - huduiskin.xex
       - sysupdate.xexp1
       - aac.xexp1
       - bootanim.xexp1
       - createprofile.xexp1
       - dash.xexp1
       - deviceselector.xexp1
       - feedback.xexp1
       - friends.xexp1
       - gamerprofile.xexp1
       - hud.xexp1
       - huduiskin.xexp1
>F3C800 = Flash   LAYOUT (3/4)
>F3CA00 = Filename TABLE (3/4)
       - marketplace.xexp1
       - mfgbootlauncher.xexp1
       - minimediaplayer.xexp1
       - quickchat.xexp1
       - signin.xexp1
       - updater.xexp1
       - vk.xexp1
       - voicemail.xexp1
       - xam.xexp1
       - XenonCLatin.xttp1
       - ximedic.xexp1
       - sysupdate.xexp2
       - acc.xexp2
       - bootanim.xexp2
       - createprofile.xexp2
       - dash.xexp2
>F3CC00 = Flash   LAYOUT (4/4)
>F3CE00 = Filename TABLE (4/4)
       - deviceselector.xexp2
       - feedback.xexp2
       - friends.xexp2
       - gamerprofile.xexp2
       - hud.xexp2
       - huduiskin.xexp2
       - marketplace.xexp2
       - mfgbootlauncher.xexp2
       - minimediaplayer.xexp2
       - quickchat.xexp2
       - signin.xexp2
       - updater.xexp2
       - vk.xexp2
       - voicemail.xexp2
       - xam.xexp2
       - XenonCLatin.xttp2
>F3D200 - ximedic.xexp2 (ENTRY)

544K FIXED COMMON BIOS AREA (2/2)
---------------------------------
>F78000 - SETTINGS
>F78600 - ZERO
>F7C000 - TABLE
>F7C200 - SETTINGS
>F7C600 - ZERO
>F80000 - 512K EMPTY SPACE

Little tidbit, what is the "paddnu" at the end of the flash section, starting at >F7C000, it is different on
all dumps of the flashrom.

It is a checksum of the stored files?

Would like to dump the flashrom on original untouch system, then update the dashboard,
and see if "numbers" at >F7C000 changes.


Another quote on the file system
QUOTE

Locating the directory block:
A dump with the 16 bytes sparse data is needed for this. Scan the first page of every block for the
following pattern:

ww ww vv 00 00 FF 00 00 xx xx 00 00 yy yy yy yy

ww is the block number, vv is an incremental version number, xx needs to be 0 and yy is the ECC/EDC.

Format of the directory block:
Page 0, 2, 4, 6 contain information about the usage of every block in the flash. This information is
encoded as a 16 bit value. I am uncertain about the meaning of the highest bit. Usually all blocks
of a deleted file have this bit set. Without the highest bit the values are pretty trivial:
0x0000-0x03FF: This is the next block in a file (e.g. block 0x28 has a value of 0x29)
0x1FFB: This is a reserved block (the first 39 blocks and the last 4 blocks have this value)
0x1FFE: This is a free block (this also includes the directory block)
0x1FFF: This is the last block of a file

The odd pages contain the filenames, the starting block, the length and an unknown 32
bit value (guess: file type and version). If the first byte of the filename is 0x05 the file
is marked as deleted.

The interesting question now is: Why are the last 64 KB marked as reserved?


Well there is more in this post but if someone is interested in kernel hacking well go check that out




Logged

infamous_Q

  • Guest
Let The Hacking Begin
« Reply #48 on: January 25, 2007, 05:21:30 PM »


hmmm...not being a hardware coder you can pretty much ignore this post if u think its referring to the previous post, especially since i barley understood ne of it lol.

on the topic if the update discs. are they just one file? if not they're all signed right? like nothing could be done to alter some of the files? im sure i'll get flamed for it..but meh.
but what about a hotswap? SUPER risky clearly since it's updating the kernel. im not quite sure how it acts when you insert the disk. but assuming it lets you decide whether to install it right then or not...what if the signature gets read on the first attempt only? would it be possible to hotswap something in (assuming it just skipped the signature check since it'd already been read once) and then have it run our own kernel update?

then again not only is this serious speculation, but what exactly could we achiever through updating the kernel to w/e we want? mind you thats also a quick way to get band assuming that MS can read the contents of the current kernel rather than just the version numbers to check for an update.




Edited by infamous_Q, 26 January 2007 - 02:22 AM.


Logged

No_Name

  • Guest
Let The Hacking Begin
« Reply #49 on: January 26, 2007, 11:20:48 AM »


I dont know how the update is compiled, but if its one single file you wont be able to edit it as you would break the sig, but then if its not the updater would run first, again it would be signed and then it would introduce the update to the system, its at this point that I would see the update being pull off the disk, checked and the run/no run call is made.


I am not trying to shoot down ideas here, but pointing out the holes in the idea. I have a IT background but I am no security expert but if I can see holes in your idea I am sure the security heads has looked at the obvious attack points and came up with way to try and attack it and prevent those attacks.

I think its a dead end idea and my instinst is that you would kill the system trying it unless you knew exactly what you where doing and how the system will react to having a hijacked update appear.




Edited by No_Name, 26 January 2007 - 08:22 PM.


Logged

infamous_Q

  • Guest
Let The Hacking Begin
« Reply #50 on: January 26, 2007, 06:08:15 PM »


and that is indeed a very valid pont. im just trying to get some brainstorming going here..im just aching for the day i can' plug in external haddrives into my 360 and play w/e format of movies is on there. or load games, which i think we might be able to do through using a disc emulator (ie using some sort of hacked software to redirect disc requests from the dvd-drive firmware to the sectors on the harddrive of the game, but thats just another random idea).

like i said just tryin to get some brainstorming going, it already seems hitachi development has died out (which blows for us hitachi owners...still crossin my fingers for media stealth on the hitachi drives), and the last thing we want is for the 360's true power to never be released. homebrew would be wicked if u ask me. this time around though we just gotta make sure not to piss off MS enough (ie through cheating) that they ban ppl from live.




Logged

jaimebenlasnow

  • Guest
Let The Hacking Begin
« Reply #51 on: January 26, 2007, 06:21:47 PM »


Well the hotswap idea might work...But it will be very risky i don't know if the flash is copied into the ram or something an then do a recheck gor the flash everytime it will be a performance issue i think.But what i do know is thaht when you will replace the flash beetween two console or something it will certainly shut off cause the kernel will be read as corrupted or something like that and it will give you an error code (speculation:e71)...This is just speculation but i think robinsod and the gang is working on this.




Logged

xbox7887

  • Guest
Let The Hacking Begin
« Reply #52 on: February 21, 2007, 03:45:42 PM »


ok how bout this, where is the kernel stored?? is it all in one place or is it spread across a few chips and then loaded wen needed, if it was in one place COULD it be possible to solder a different chip in with say a modified xbmc pre loaded onto it??

Part of the 360's kernel disassembly...if you find a way to modify it let me know wink.gif

http://web.ics.purdu.../ppc_sample.txt




Edited by xbox7887, 22 February 2007 - 12:46 AM.


Logged

RolfLobker

  • Guest
Let The Hacking Begin
« Reply #53 on: February 26, 2007, 02:56:37 PM »


Sorry had 2 hdds crash so lost all xbox & 360 hacking work.
Havent had time 2 be online so will clean this up by the end of the week & sorry once again sad.gif the hdds are 2 screwed to be recovered.


ouch sad.gif

I just reinstalled XP yesterday (damn does vista suck  dry.gif ) and i'm using Acronis True Image to the max now.
Don't want to keep reinstalling shit all the time so I now have a nice Secure Zone (hidden partition) containing my c:\ (system) and d:\ (program files)
Made a checklist first and installed all necessary software  / updates.
Changed default folder location for My Favorites and such and put my Outlook .pst on a seperate drive.
Now if I screw up or my systems becomes unstable / slow I just do a 5 minute restore and everything is up an running again.

Ever consider backups? ;-)
I'v had my fair share of losses in the past and I must say that, finally after 15yrs of screwing up and losing data I now know what to backup and when.

Only need to burn my 800GB collection of series and movies now....
hmm... 800GB equals 200 dvd's. Divided by four burners times 15 minutes equals..... two sickdays tongue.gif

Very sorry for your loss. Does this mean you also lost that beta of the Utopia bootdisc ?
You know... that signed disc which rewrites the internal cpu-code to disable the hypervisor and alter the private key to the habibi derivative??  sad.gif

Ofcourse you are aware of this but keep backing up your data on cheap dvd's (not cheap as in crappy but cheap as in dvd's are not expensive)

Edit:
Whatever happened to NexGen by the way?
I notice you still have the link to http://www.xboxopensource.com/ in your sig but the domain has been taken over / expired.
Shame that it never really hit it off. Ofcourse now XBMC is the only good dashboard availlable but still a shame of NexGen (same goes for MXM, still wonder what happened to BenJeremy)
Sigh... the good 'ol days.... (thankfully I have lots of old threads bookmarked. Just yesterday I browsed through a thread about an xbox recovery disc. Apparantly Eh. hasn't been here since two years... time flies sad.gif)





Edited by RolfLobker, 27 February 2007 - 12:03 AM.


Logged

HoRnEyDvL

  • Guest
Let The Hacking Begin
« Reply #54 on: February 27, 2007, 02:38:21 AM »


Yeah sorry about my sig has been updated now
Our domain is
www.team-xos.com
40 Odd Posts deleted smile.gif




Edited by HoRnEyDvL, 27 February 2007 - 11:54 AM.


Logged

zachos1

  • Guest
Let The Hacking Begin
« Reply #55 on: April 15, 2007, 11:01:58 AM »


i am trying to put my xbox 360 0078fk driver in mode b. i tried with both slax 2, and slax 21.
it start to reading the slax but it never comes to the "disk spinning...." instead of that i get the follow:

dma_timer_expiry

dma status==0xff

hda:cache flushes supported



i will appreciate any help...


note: I have nforce chipset and vista windows




Logged

joes240nismo

  • Guest
Let The Hacking Begin
« Reply #56 on: April 27, 2007, 06:14:22 PM »


Well the hotswap idea might work...But it will be very risky i don't know if the flash is copied into the ram or something an then do a recheck gor the flash everytime it will be a performance issue i think.But what i do know is thaht when you will replace the flash beetween two console or something it will certainly shut off cause the kernel will be read as corrupted or something like that and it will give you an error code (speculation:e71)...This is just speculation but i think robinsod and the gang is working on this.

well.... no... the flash file IS just one signed file, able to run off of a burned CD/DVD, although it is probably hashed, checked then copied to ram, then run from the ram... or copied to the ram, hashed/checked, then run. no matter what order it WILL check the complete data that is or will be in the ram before it runs it... i think your just assuming it will hash/check the file, then in the middle of copying it you swap it for other code, but i HIGHLY doubt microsoft wont hash/check anything in the ram... good idea, but i would put a 99.95% chance on it NOT working. and what you said, the hypervisor's whole purpose is to detect/prevent unsigned code from running... this idea can pretty much be put to rest until running unsigned code is possible, (or i guess if you have the KK/firmware option still available to you)




Logged
Pages: 1 2 3 [4]
 

Page created in 0.107 seconds with 15 queries.