#31063 - leonard_ - Tue Dec 07, 2004 2:36 pm
Hi,
Maybe I'm wrong but here is what I know from the forum: DS game roms can't be read directly using a ROM reader coz there is encryption (exept in the header).
Do you think this is "encryption" (I mean data must be decoded with a key) or simply "random shuffling" ?
In any case, many people can help here, but few can dump ROM. So my guess: could someone post a "raw" image of a DS rom, even if it's encrypted, shuffled, etc... Maybe someone could have nice ideas if he gets the file. ( including me ! :-))
#31077 - tepples - Tue Dec 07, 2004 5:18 pm
The problems here are that 1. the encryption uses a different key every time, and 2. the commands themselves are scrambled. It's not like Capcom CPS-2 where you can release an encrypted ROM and use various methods to get the XOR of the encrypted ROM with the decrypted ROM.
_________________
-- Where is he?
-- Who?
-- You know, the human.
-- I think he moved to Tilwick.
#31087 - EaDS Milliways - Tue Dec 07, 2004 6:54 pm
| tepples wrote: |
| The problems here are that 1. the encryption uses a different key every time, |
I have an RSA Keyfob that my company uses for network security. Every six seconds, the number on it changes (it has to be entered into the password field before you log on). If this is in any way related to the RSA logo on the back of the DS, then it's already accepted as a fairly strong level (enterprise ready) of secured encryption.
You can pore through the info at http://www.rsasecurity.com/ but if there are any specific questions about using it that I can answer, I try to!
#31090 - SimonB - Tue Dec 07, 2004 7:40 pm
Interesting to note is that RSAsecurity.com shows up in the forum logs reading all the DS encryption related topics :=)
Simon
#31092 - keldon - Tue Dec 07, 2004 8:11 pm
| SimonB wrote: |
Interesting to note is that RSAsecurity.com shows up in the forum logs reading all the DS encryption related topics :=)
Simon |
You'd have thought they invented asymetric cryptography
#31108 - willgonz - Tue Dec 07, 2004 11:40 pm
Look up the patent for the DS. I am sure it is (Patent Number) in the manual somewhere.
United States Patent Numbers:
5,207,426
5,291,189
5,327,158
5,337,069
5,371,512
5,400,052
5,483,257
5,495,266
5,509,663
5,608,424
5,708,457
D478,866
D468,743.
Canadian Patent Numbers:
2,037,909
2,048,167
2,049,899
2,049,900
2,049,914
2,051,655
2,055,718
2,055,724
96,338.
Start searching. http://www.uspto.gov/
#31115 - leonard_ - Wed Dec 08, 2004 12:21 am
| Quote: |
| The problems here are that 1. the encryption uses a different key every time, and 2. the commands themselves are scrambled. |
Ok so each time you get a dump you get a different file. And ? it makes things a lot harder, but it's better to have files to study than nothing, no ?
#31117 - MR.MOD - Wed Dec 08, 2004 12:59 am
Here It talks about the RSA BSAFE? encryption software and that some of the early investors and one is nintendo. Here it talks about the BSAFE Standards and Compliance. I don't know If it has anything to do with the carts encryption but it looks like it might.
http://www.rsasecurity.com/node.asp?id=1211 talks about encryption for video game systems and ARM processers.
Last edited by MR.MOD on Wed Dec 08, 2004 11:24 pm; edited 1 time in total
#31119 - keldon - Wed Dec 08, 2004 1:22 am
Having different results from the same data is a good thing; you never know what maths may reveal in the future.
What are the chances of the end bytes of each cartridge being 0 (before encryption of course)? What does encryption do if you attempt to read an address that can be addressed, but the cartridge simply does not have it? E.g. reading byte 1048578 on a 1MB cart (apart from an ACCESS_VIOLATION interrupt)
Like I said before aswell, what if you consecutively read the same byte? What is the distribution of returned results, even for the entire dump? May reveal something about their encryption technique, never know.
---
One question. Are the people who are getting the dumps heavy with cryptography?
#31251 - tonofsteel - Thu Dec 09, 2004 5:40 am
| MR.MOD wrote: |
Here It talks about the RSA BSAFE? encryption software and that some of the early investors and one is nintendo. Here it talks about the BSAFE Standards and Compliance. I don't know If it has anything to do with the carts encryption but it looks like it might.
http://www.rsasecurity.com/node.asp?id=1211 talks about encryption for video game systems and ARM processers. |
Every suggestion that encryption is done using RSA has turned up speculation that it can not be done with a stream etc. And it makes perfect sense.
However, since nintend0 was an investor to the "RSA BSAFE Cert-C ME" and it supports a multitude of encryption algorithms, AND is optimized for wireless and embedded devices, I say uh oh. There is RSA on the thing for a reason....
Reading some of the information available, there are some algorithms that can be streamed, and some that look suspiciously viable in the DS cart application.
As well it is optimised for... surprise! wireless applications. Someone was saying earlier that wireless is most likely not encrypted, but reading some info on the other side of those links makes me feel there is something ominous that is going to be discovered soon. Mabye not, I am not sure how far people are into understanding the data being sent.... I am mostly messing around with getting something running through the DS cart slot....
It almost appears at first glance that nintend0 has been sleeping with RSA to get rid of us pesky homebrewers. Just speculation.... but something seems very odd with this picture.
When reading through some PDF's there is even reference to using this encryption for memory applications....
Anyways if people are looking for information on encryption algorithms that are possible, i think this would be a very good place to start....
#31254 - keldon - Thu Dec 09, 2004 6:08 am
Even if they streamed the data; there is no way to stream different outputs. Basically you have very large prime numbers generated, which is a(the) task in itself, some multiplication and modulo maths and you have RSA encrypted data. With a matching prime number and modulo number I think, you can decode it.
Because the key is different each time it is read from it means it is generated on the fly. So to be able to encode it you need an on board multiplication and modulus circuit in each cartridge.
Well with electronics these days I guess you never know what's possible from not.
#31255 - tonofsteel - Thu Dec 09, 2004 6:12 am
Apparantly it can do:
Algorithms
Public Key Algorithms
RSA?, RSA with MultiPrimeTM technology
Symmetric Ciphers (Secret Key)
AES, RC5?, RC4?, RC2?, DES and 3DES
Message Digests
MD2, MD5, HMAC, SHA-1, SHA-2 and HMAC
Standards
Certificate format ? X.509 v3, WTLS
Public Key Cryptography Standards (PKCS) - #7, #10
Which all of are apparantly involved with the RSA BSAFE Cert-C ME system. So even if the cart is using DES, it will still have RSA on the bottom since RSA came up with some fancy algorithms to make them like 10 times faster or something along those lines.......
So the ITS NOT RSA encryption can still hold true, its just a encryption device or algorithm from RSA the company....
#31266 - ampz - Thu Dec 09, 2004 12:42 pm
Someone suggested reading data from the end of the card: Try reading a few topics here... The commands are encrypted, we don't have the capability to send read commands to the card (the read header command is the notable exception).
As for some of the encryption algorithms.. This is done in hardware, that means no multiplications, no divisions, and no modulus operations.
What ever encryption algorithm they use, it will only use additions/subtractions, logic, and shifts. It will also not use more than perhaps a hundred bits or so of RAM.
Rules out many encryption algorithms.
#31279 - leonard_ - Thu Dec 09, 2004 2:25 pm
my own opinion about DS crypto:
RSA-Bsafe program is a general crypto library for C/C++. some of the algorithm described can be fast on ARM ( especially symetric block cypher such as RC2 or AES).
I'm sure all these algos are NOT used in hardware for game ROM reading. If there is encryption in ROM cartridge, it's a basic system (such as XOR or pseudo random)
For wireless, the only fast stream-cypher in the list is RC4. But, we know data is not encrypted because some people saw ascci string in data packets.
To me, the big problem people working on wi-fi hacking will face is digital signature. It's possible that RSA is used to sign a large binary block. Data are not crypted, just signed. If you don't know the nintendo private key, you simply can't sign your own code , so you can't run your own code. Think about it, Microsoft Xbox signature private key has never been hacked !! ( people simply replace the BIOS to avoid the signature check).
So RSA-BSafe is only marketing words. All theses cyphers are only a list for journalist. BUT, it could be possible that an assymetric cypher ( such as RSA) is used to sign code.
#31286 - tonofsteel - Thu Dec 09, 2004 4:49 pm
| leonard_ wrote: |
my own opinion about DS crypto:
RSA-Bsafe program is a general crypto library for C/C++. some of the algorithm described can be fast on ARM ( especially symetric block cypher such as RC2 or AES).
I'm sure all these algos are NOT used in hardware for game ROM reading. If there is encryption in ROM cartridge, it's a basic system (such as XOR or pseudo random)
For wireless, the only fast stream-cypher in the list is RC4. But, we know data is not encrypted because some people saw ascci string in data packets.
To me, the big problem people working on wi-fi hacking will face is digital signature. It's possible that RSA is used to sign a large binary block. Data are not crypted, just signed. If you don't know the nintendo private key, you simply can't sign your own code , so you can't run your own code. Think about it, Microsoft Xbox signature private key has never been hacked !! ( people simply replace the BIOS to avoid the signature check).
So RSA-BSafe is only marketing words. All theses cyphers are only a list for journalist. BUT, it could be possible that an assymetric cypher ( such as RSA) is used to sign code. |
Um, yea, and if you read about some of those algorithms they use a simple XOR in their implementation. And that was the whole point of quoting that page, is because of implementation issues it narrows down the field.
But nintendo invested in RSA-Bsafe for EMBEDDED and WIRELESS devices, in case you missed that. And algorithms that can be made in software can be made in hardware as well. For all we know the DS decrypts the stuff using software.
And i doubt that RSA-Bsafe is for the next gamecube since it was made for embedded and wireless devices. And RSA is on the bottom of the DS.... hmmmm mabye a connection there?
#31287 - tepples - Thu Dec 09, 2004 5:40 pm
Game consoles are considered "embedded devices".
_________________
-- Where is he?
-- Who?
-- You know, the human.
-- I think he moved to Tilwick.
#31288 - EaDS Milliways - Thu Dec 09, 2004 5:44 pm
Here's a page that describes how one of the technologies work
http://www.myfuturecom.com/Products/rsasecurity/securid_hardware.asp
Since this is a "once every 60 seconds" thing, it wouldn't really be the case with the DS since each reading is yielding different results (for embedded devices, maybe it changes on each reading instead of every 60 seconds).
I think I may have seen a picture somewhere of the PSP where it also was using RSA, however I can't find it now. Has anyone else seen this?
EDIT: As another thought, perhaps the clock/alarm function is only there because they have something recording "beats" while it's "asleep" anyway, why not tie it to a clock? :)
Last edited by EaDS Milliways on Thu Dec 09, 2004 5:53 pm; edited 1 time in total
#31289 - EaDS Milliways - Thu Dec 09, 2004 5:48 pm
| tepples wrote: |
| Game consoles are considered "embedded devices". |
I think it's embedded in that the required hardware has been integrated into the system instead of being something separate.
#31387 - XSF04 - Fri Dec 10, 2004 7:27 pm
In any cases guys the DS will be able to run homebrews someday.
My 2cents theory: This is applicable in any domain. Everything that is constructed/build by human kind can be also dismantled/reversed by human kind.
One day your DS will run homebrews!
:)
_________________
-XSF04-
Excess for the way it meant to be.
#31391 - siul1979 - Fri Dec 10, 2004 7:46 pm
| XSF04 wrote: |
In any cases guys the DS will be able to run homebrews someday.
My 2cents theory: This is applicable in any domain. Everything that is constructed/build by human kind can be also dismantled/reversed by human kind.
One day your DS will run homebrews!
:) |
We all know the answer to the question, "Will we be able to run homebrews?"
, but the question should be "When?" =)
#31421 - tepples - Fri Dec 10, 2004 10:11 pm
| XSF04 wrote: |
| Everything that is constructed/build by human kind can be also dismantled/reversed by human kind. |
It'll be hacked, but how do you know this will happen before you're dead? For example, the community still hasn't managed to come up with source code for a functional equivalent to the frontloading NES's lockout chip. Homebrew NES developers either have to steal a lockout chip off an existing NES game's board or open the NES and snap a pin.
_________________
-- Where is he?
-- Who?
-- You know, the human.
-- I think he moved to Tilwick.
#31428 - Abscissa - Fri Dec 10, 2004 10:58 pm
| tepples wrote: |
| Homebrew NES developers either have to steal a lockout chip off an existing NES game's board or open the NES and snap a pin. |
Or beat it into submission with voltage spikes ;)
#31433 - tepples - Fri Dec 10, 2004 11:30 pm
| Abscissa wrote: |
| tepples wrote: | | Homebrew NES developers either have to steal a lockout chip off an existing NES game's board or open the NES and snap a pin. |
Or beat it into submission with voltage spikes ;) |
Not on later frontloaders that put decent ESD protection circuitry in front of the lockout chips so that the Macronix -5V trick used by Color Dreams, Camerica, and AVE games doesn't work.
_________________
-- Where is he?
-- Who?
-- You know, the human.
-- I think he moved to Tilwick.
#31478 - netdroid9 - Sat Dec 11, 2004 5:30 am
It'll happen this lifetime, as long as someone can be bothered to dump the NDS BIOS, WIFI (If it has it's own rom/ram), Several Encrypted Game ROMS, and everything else. Then you need to create an actual digital DS (Well, not really, but it'd make the job a heck of a lot easier) by finding out every piece of hardware it uses and puting it into a physics simulator, and then loading all the rom data into it.
Use the simulator to find out how the NDS interacts with the game cartridge. More importantly, record the commands the NDS uses to extract a key from the cartridge. If it uses different keys that is.
If someone does this, post the full simulation and all the interactions you got. Why? because the simulation doubles as an emulator :D
(I'm not sure there is a physics simulation capable of this, but there should be)
#31750 - FriedChickenAndOrangeSoda - Tue Dec 14, 2004 7:58 am
This thread made me flip my DS over, and actually check out the serial number sticker. Yup, there's an "RSA Secured" logo.
What's really secured though? The BIOS image? The DS carts themselves? The wireless traffic we know isn't encrypted, at least on the WiFi part. Maybe the NiFi stuff is? Interesting stuff up ahead, that's for sure...
_________________
Fried Chicken and Orange Soda
#31781 - EaDS Milliways - Tue Dec 14, 2004 3:08 pm
| FriedChickenAndOrangeSoda wrote: |
| What's really secured though? The BIOS image? The DS carts themselves? |
IMHO, if it works like their other products then the first connect between the cart and the DS is something to determine how the code will be encrypted and then the traffic is encrypted this way.
If there's no "clock" on the cart, that would mean that the randomness has to be based wholly on the DS, right? Actually, the more I think about the logic of that, the more my brain cooks. I'll need some coffee to cool it down...
#31948 - mike260 - Thu Dec 16, 2004 3:58 am
Hello,
I've been following this board with great interest, but I've got to inject a note of pessimism here: Doesn't it seem likely that Nintendo has signed their carts and netboot packets with public key crypto? It wouldn't stop people making identical copies of legit games, but it would make it impossible to create valid homebrew carts. Thus, the only use for flash carts would be piracy, which would presumably make it easier for Nintendo to pursue them legally.
Is anyone looking into alternative attack vectors? Eg:
- Modifying/replacing the BIOS
- Finding a wifi exploit
- Getting control of the system from a GBA cart
I'm planning to start poking around the DS from within a GBA cart as soon as I get a DS anyway...
#31949 - AdamW - Thu Dec 16, 2004 5:15 am
Well, if you read the forum, you'll see that's exactly what people are investigating :). Don't think there's a solid conclusion as of yet. Booting a GBA cartridge switches the system to an entirely different mode in which only the ARM7 CPU that is used to run GBA games is accessible, only one screen is accessible and none of the DS-specific stuff is turned on, so gaining control of the whole system through that vector seems unlikely. Wi-fi boot is being actively worked on as you can read in other threads.
#31951 - mike260 - Thu Dec 16, 2004 6:11 am
| AdamW wrote: |
| Well, if you read the forum, you'll see that's exactly what people are investigating :). Don't think there's a solid conclusion as of yet. Booting a GBA cartridge switches the system to an entirely different mode in which only the ARM7 CPU that is used to run GBA games is accessible, only one screen is accessible and none of the DS-specific stuff is turned on, so gaining control of the whole system through that vector seems unlikely. Wi-fi boot is being actively worked on as you can read in other threads. |
Regarding wifi, I meant an exploit along the lines of a buffer overflow or similar - IMHO wifo boot will prove impossible
Regarding GBA mode, it could be possible to use it to take a look at the DS BIOS, if nothing else. There's a loophole that lets you get the CPU into supervisor mode, right?
It's damn frustrating not having a DS to experiment with and having to live vicariously through you guys :)
#31959 - tepples - Thu Dec 16, 2004 7:35 am
You can get the GBA CPU into a mode where you can look at the BIOS, but then you can only look at the same BIOS that you've been seeing since 2001. There's only one bit of difference between the GBA and DS BIOS, and it's in an unused section, likely placed there so that GBA programs running on a Nintendo DS can detect its brighter screen and use the full 0-31 range of RGB color components rather than 8-31.
_________________
-- Where is he?
-- Who?
-- You know, the human.
-- I think he moved to Tilwick.
#31960 - mymateo - Thu Dec 16, 2004 7:43 am
| tepples wrote: |
| and use the full 0-31 range of RGB color components rather than 8-31. |
Quick questions:
The GBA can use the full range anyways, can't it?
If so, are you just saying that with the GBA (SP) screen, you can't actually make out colors using 0-7 in the RGB components, thus a good programmer just wouldn't use them?
#31961 - kerrle - Thu Dec 16, 2004 7:44 am
| mike260 wrote: |
| I've been following this board with great interest, but I've got to inject a note of pessimism here: Doesn't it seem likely that Nintendo has signed their carts and netboot packets with public key crypto? It wouldn't stop people making identical copies of legit games, but it would make it impossible to create valid homebrew carts. |
But this is exactly the oposite of what Nintendo would be interested in - they could care less if a few hobbyist get a web browser running on their device - where's the loss to them?.
If a pirate organization in China, however, can figure out how to mass produce copies of legit games, Nintendo is out a ton of money.
If anything, I'd expect a protection scheme which makes it nearly impossible to copy an existing game, but doesn't care about homebrew code.
#31963 - tepples - Thu Dec 16, 2004 7:49 am
| mymateo wrote: |
| The GBA can use the full range anyways, can't it? |
Yes, but if you try, you get Castlevania: Circle of the Moon. It appears Konami got the retail units too late to make any changes to the palettes.
| Quote: |
| If so, are you just saying that with the GBA (SP) screen, you can't actually make out colors using 0-7 in the RGB components, thus a good programmer just wouldn't use them? |
That's exactly what I meant. A game would detect the Game Boy Player using the splash screen method and the DS using a BIOS checksum, and then it'd adjust the brightness accordingly.
_________________
-- Where is he?
-- Who?
-- You know, the human.
-- I think he moved to Tilwick.
#31989 - mike260 - Thu Dec 16, 2004 6:35 pm
| tepples wrote: |
| You can get the GBA CPU into a mode where you can look at the BIOS, but then you can only look at the same BIOS that you've been seeing since 2001. |
Now I'm confused. I thought that there wasn't an MMU, just a protection unit. How is the system hiding the 'real' BIOS from GBA-mode code?
#32012 - netdroid9 - Fri Dec 17, 2004 2:58 am
Easy, the DS BIOS loads, sees the GBA Cartridge, loads the GBA BIOS and unloads itself.
#32013 - SmileyDude - Fri Dec 17, 2004 3:32 am
the GBA didn't have a MMU either, but it wasn't possible to read the BIOS directly. The only reason we have a dump of the BIOS is because of a bug in one of the functions in the BIOS that allowed extraction of the BIOS data.
I'm assuming that there is some basic functionality to turn on/off areas of the address space on the DS, just like there was on the GBA. Something fairly simple that just looks at the current mode of the CPU and adjusts the memory map as necessary. If the DS had a real MMU, that functionality would be handled there. But, since the DS doesn't, it's probably some custom logic that Nintendo put in place to protect the BIOS.
I would be interested in seeing if using the GBA BIOS might yield a way into the DS BIOS. But, my bet is that the DS BIOS runs on the ARM 9 CPU, and it's protection is tied to the state of the ARM 9. I would assume that the ARM 9 is in user mode and asleep while GBA games are running, so there probably isn't much possibility of getting to the DS BIOS that way.
_________________
dennis
#32014 - AdamW - Fri Dec 17, 2004 5:28 am
tepples: that's what a SMART game does, yes. a DUMB game like Final Fantasy Tactics Advance gives you a manual choice of display modes, explains vaguely that one might be better for GBA SP, one for GBA and one for Game Boy Player, and leaves you to figure out which one to use by yourself. sigh.
#32015 - ravuya - Fri Dec 17, 2004 5:42 am
| AdamW wrote: |
| tepples: that's what a SMART game does, yes. a DUMB game like Final Fantasy Tactics Advance gives you a manual choice of display modes, explains vaguely that one might be better for GBA SP, one for GBA and one for Game Boy Player, and leaves you to figure out which one to use by yourself. sigh. |
FFTA made a lot of really dumb decisions (although it's not the only game to have the LCD A/LCD B/TV crap -- I think Metroid Fusion did too, although I can't recall exactly). I don't know why some of the cinema scenes are unskippable for the first couple of seconds -- a friend of mine wondered out loud if it might be decompressing data then -- and if you look at the credits it was put together by five coders, but over 60 QA and art people.
_________________
Rav (Win/Mac/Linux games for free)
#32016 - mike260 - Fri Dec 17, 2004 5:46 am
| SmileyDude wrote: |
| the GBA didn't have a MMU either, but it wasn't possible to read the BIOS directly. The only reason we have a dump of the BIOS is because of a bug in one of the functions in the BIOS that allowed extraction of the BIOS data. |
That's the out-of-range SWI thingy, right? That's what I was suggesting could be used to get into supervisor mode, from whence the protection unit might be disabled.
| SmileyDude wrote: |
| I'm assuming that there is some basic functionality to turn on/off areas of the address space on the DS, just like there was on the GBA. Something fairly simple that just looks at the current mode of the CPU and adjusts the memory map as necessary. If the DS had a real MMU, that functionality would be handled there. But, since the DS doesn't, it's probably some custom logic that Nintendo put in place to protect the BIOS. |
If it is the same protection-unit as the GBA had (it's a standard ARM component BTW) then it's circumventable using the BIOS bug. But I guess it'd be pretty negligent of Nintendo not to close that loophole. It's got to be worth a try though.
#32017 - SmileyDude - Fri Dec 17, 2004 7:02 am
well, i'm going under the assumption that either it's a different protection unit, or there is one for both the ARM 7 and the ARM 9, and the DS BIOS is only accessable to the ARM 9.
Now, other parts of the system might be accessable via GBA BIOS bugs... but, I can't really even speculate on this.
BTW -- wasn't there code someplace that would put the GBA into supervisor mode? Or was that a complete figment of my imagination? If that code does exist, does it allow read access to the BIOS?
_________________
dennis
#32021 - tepples - Fri Dec 17, 2004 8:47 am
| mike260 wrote: |
| SmileyDude wrote: | | The only reason we have a dump of the BIOS is because of a bug in one of the functions in the BIOS that allowed extraction of the BIOS data. |
That's the out-of-range SWI thingy, right? |
Apparently, the check allowing reading the GBA BIOS involves both the CPU mode and the high order bits of the program counter. The buggy BIOS function was MidiKey2Freq(), which didn't check if one of the parameters was within the BIOS area. Other BIOS functions, such as CpuFastSet(), don't do anything if the source range includes any of BIOS.
_________________
-- Where is he?
-- Who?
-- You know, the human.
-- I think he moved to Tilwick.
#32027 - Sebbo - Fri Dec 17, 2004 10:37 am
i know its not a good idea to bring up old stuff in a forum, but...
keldon said
"Having different results from the same data is a good thing; you never know what maths may reveal in the future. "
how about some dumps of the same game on this forum (or even links to the dumps) so that us who know some advanced maths can try and work something out? i said this in another topic, but matrix encryption would be a smart idea for this sort of thing, and the DS can do it (a XOR is a matrix, but only really simple).
does any one know what the largest array for a matrix is that the DS can handle? if it does use matrices, the encryption matrix won't be too small, or too big either
again, can we have some dumps posted on the site? i wanna see if i wasted 2 years of schooling on advanced maths or not :-P
[/quote]
#32037 - netdroid9 - Fri Dec 17, 2004 1:05 pm
I'd like a look as well, but I don't have a DS :(.
April 2005 date set for the DS in Australia... WHY NINTENDO WHY?!?!?!
#32041 - mike260 - Fri Dec 17, 2004 1:43 pm
| tepples wrote: |
Apparently, the check allowing reading the GBA BIOS involves both the CPU mode and the high order bits of the program counter. The buggy BIOS function was MidiKey2Freq(), which didn't check if one of the parameters was within the BIOS area. Other BIOS functions, such as CpuFastSet(), don't do anything if the source range includes any of BIOS. |
Ah, I was referring to a different bug. Look at 'BIOS System Call Handling' in this doc: http://wwwhsse.fh-hagenberg.at/Studierende/hse02006/uclgba/gba-howto/ar01s03.html
#32066 - darkfader - Fri Dec 17, 2004 7:25 pm
<deleted>
Last edited by darkfader on Tue Mar 01, 2005 8:40 pm; edited 1 time in total
#32069 - mymateo - Fri Dec 17, 2004 9:19 pm
| netdroid9 wrote: |
I'd like a look as well, but I don't have a DS :(.
April 2005 date set for the DS in Australia... WHY NINTENDO WHY?!?!?! |
There are plenty of ways to get your hands on a DS right now. eBay has lot of 'em, and a good number go for barely over the retail price. Add shipping, and I think you may end up having to pay 15 to 25% more than when they come in stores, but if it's worth it to get a DS now instead of later...
#32089 - netdroid9 - Sat Dec 18, 2004 2:30 am
I don't have a credit card though :(
#32090 - AdamW - Sat Dec 18, 2004 2:42 am
www.bidpay.com - international money orders, paying eBay sellers for the purpose of, $5 a pop.
#32096 - mike260 - Sat Dec 18, 2004 3:47 am
| Quote: |
BTW -- wasn't there code someplace that would put the GBA into supervisor mode? Or was that a complete figment of my imagination? If that code does exist, does it allow read access to the BIOS?
|
Oops, looks like I was talking out my arse - I just tried this out on a GBA, and getting into supervisor mode *doesn't* let you see the BIOS. Doesn't let you do anything out-of-the-ordinary as far as I can see. The protection unit I assumed was controlling BIOS access doesn't appear to exist either - looks like the BIOS is only readable when the PC's inside it.
#32098 - DekuTree64 - Sat Dec 18, 2004 3:52 am
How did you get into supervisor mode? I've never heard of any way to do it, and if I remember right, even the PC gets garbage from the BIOS if you bx into it. Try branching to the BIOS in supervisor mode and see what happens.
_________________
___________
The best optimization is to do nothing at all.
Therefore a fully optimized program doesn't exist.
-Deku
#32110 - sgeos - Sat Dec 18, 2004 5:20 am
| AdamW wrote: |
| www.bidpay.com - international money orders, paying eBay sellers for the purpose of, $5 a pop. |
Before I had a credit card, I bought a whole bunch of stuff off ebay using money orders. IIRC, I used Canadian postal money orders. (I don't recall money orders from the bank working.)
-Brendan
#32116 - mike260 - Sat Dec 18, 2004 5:45 am
| DekuTree64 wrote: |
| How did you get into supervisor mode? I've never heard of any way to do it, and if I remember right, even the PC gets garbage from the BIOS if you bx into it. Try branching to the BIOS in supervisor mode and see what happens. |
Basically, the BIOS handles SWI nn by looking up entry nn in a jump-table and jumping to that address. But the jump table only covers 42 entries, and the BIOS doesn't check for out-of-range SWIs. Specify an out-of-range SWI, and the BIOS will happily fetch garbage off the end of the jump-table, interpret it as an address and jump to it.
Luckily, shortly after the jump-table in the BIOS is the number 0x02002040, which is an address in WRAM. So calling SWI D4 will effectively get the BIOS to jump to 0x02002040, still in supervisor mode.
| Code: |
void supervisor( void(*func)() )
{
u32 *trap = (u32 *)0x02002040;
trap[-1] = (u32)func;
//LDR PC,(PC-4)
trap[0] =
(12<<0) |
(15<<12) |
(15<<16) |
(1<<20) |
(1<<24) |
(1<<26) |
(14<<28);
__asm("swi 0xD40000;");
}
|
#32268 - FluBBa - Mon Dec 20, 2004 9:56 am
The GBA starts in System mode, you only have to change the CPSR mode bits to enter Supervisor mode.
_________________
I probably suck, my not is a programmer.
#32279 - Mr. Ploppy - Mon Dec 20, 2004 2:57 pm
| sgeos wrote: |
Before I had a credit card, I bought a whole bunch of stuff off ebay using money orders. IIRC, I used Canadian postal money orders. (I don't recall money orders from the bank working.)
-Brendan |
Do you know if Canadian Tire money works?
_________________
I'm just off to Hartleypool to buy some exploding trousers. Cluck, cluck, gibber, gibber, "my old man's a mushroom", et cetera.
#32331 - mymateo - Tue Dec 21, 2004 4:05 am
Lol, Mr. Ploppy. But if you're serious, then "no" unless you plan to buy your DS from Canadian Tire. Canadian Tire Money can only be used at Canadian Tire.
#32334 - sgeos - Tue Dec 21, 2004 4:19 am
| Mr. Ploppy wrote: |
| Do you know if Canadian Tire money works? |
Have a friend or relative buy your Canadian Tire money on a $1 for $1 exchange. Use your new (and ever so strong) Canadian dollars to buy your money order.
I offered to buy a gift card from my sister at face value. It didn't work out because I've returned to Canada briefly... *I should stop rambling*
-Brendan