Hardware 3DS Update coming...

KingVamp said:
A Gay Little Catboy said:
Even if flashcards don't work in 3DS mode now, you know no one is going to want to just stop there and if it gets hacked within the 1st year, even a minor hack like the DS-Mode looks bad on Nintendo's end.
No one? I'm stopping at ds. Not everyone and their grandma is going to pirate 3DS games.

tongue.gif
I am talking about the flashcard devs. If their grandmothers help and succeed in hacking the 3DS I might be a little concerned about Nintendo's security.
 
Ikki said:
KingVamp said:
A Gay Little Catboy said:
Even if flashcards don't work in 3DS mode now, you know no one is going to want to just stop there and if it gets hacked within the 1st year, even a minor hack like the DS-Mode looks bad on Nintendo's end.
No one? I'm stopping at ds. Not everyone and their grandma is going to pirate 3DS games.

tongue.gif

I'm pretty sure he meant the flashcart devs. Maybe their grandmas too.
rofl2.gif


Even then we do not have to use 3DS function for piracy and used it for homebrew or even buy a 3DS mode cart.
 
I don't have an iEvo, and I don't know much about it, but... The DSi mode. Doesn't it have an entire ROM in its bootloader? Like, one that will have the same checksum/hash as the original game? I mean... It just uses a savefile hack, and the default game code loads that hack. Doesn't that mean that this is nearly invincible?
 
TehSkull said:
If the player can access it, why couldn't Nintendo?
Flash carts aren't standardized, the way the flash cart's firmware and kernel works is different per flash cart (well, maybe all the DSTT clones work similarly), there's no set standard for Nintendo to rely on. They could reverse and block one cart with that method, only to have all the other carts go undetected.
 
Rydian said:
TehSkull said:
If the player can access it, why couldn't Nintendo?
Flash carts aren't standardized, the way the flash cart's firmware and kernel works is different per flash cart (well, maybe all the DSTT clones work similarly), there's no set standard for Nintendo to rely on. They could reverse and block one cart with that method, only to have all the other carts go undetected.
Couldn't they use multiple methods?
 
KingVamp said:
Rydian said:
TehSkull said:
If the player can access it, why couldn't Nintendo?
Flash carts aren't standardized, the way the flash cart's firmware and kernel works is different per flash cart (well, maybe all the DSTT clones work similarly), there's no set standard for Nintendo to rely on. They could reverse and block one cart with that method, only to have all the other carts go undetected.
Couldn't they use multiple methods?
Yes, but that's going to take a lot of time and manpower. They'd probably have to dedicate a team and chunk of resources to cracking just one cart.

Flash carts aren't simple to reverse-engineer. There are some things that say "no, fuck you" even if you're a big company. For example not even the FBI can crack the kind of encryption that Truecrypt uses.

EDIT: And just to note, the main firmware file for a flash cart is often an NDS file and the cart just redirects reads to it. An NDS file is a copy of the actual DS filesystem, remember? Thus Nintendo would have to crack the flash cart's OS as well, and a change/update to the OS would be all that's needed to bypass the block in that case.

If this was feasible Nintendo would have done it.
 
jceggbert5 said:
Rydian said:
For example not even the FBI can crack the kind of encryption that Truecrypt uses.
Epic Win...

Also, how much space does the DSTwo have for a boot loader?
Idunno'. That's the kind of info they tend to not push out. I suppose an "open" system like the iSmart might have that info in it's docs, but that cart's usually not a concern (or representative of other carts).
 
KingVamp said:
Rydian said:
TehSkull said:
If the player can access it, why couldn't Nintendo?
Flash carts aren't standardized, the way the flash cart's firmware and kernel works is different per flash cart (well, maybe all the DSTT clones work similarly), there's no set standard for Nintendo to rely on. They could reverse and block one cart with that method, only to have all the other carts go undetected.
Couldn't they use multiple methods?

That's basically the equivalent of installing Anti-Virus on a computer to solve the problem of a security hole you've found. You're solving the wrong problem by trying to detect flashcarts individually. Because you're playing a cat and mouse game with hackers. Flashcarts use an exploit to launch into DS mode, fix the exploit, and flashcarts get disabled which is a more universal way of disabling them without potentially impacting existing legitimate carts.

I suspect that somehow the backwards compatibility is a huge problem such that they can't seem to do this. I don't think they want to spend the resources trying to plug the leak of an old wooden beaver dam. They'd much rather ensure the new Hoover dam is secure and not leaking. If they can secure the 3DS games then that would be a win at this point.
 
t377y000 said:
Nice i sure hope Netfront gives us 3DS owners flash support, for sites like youtube.
unlike sorry retard Opera,
tongue.gif
i think we DSi owners only got 1 DSi opera browser update from them & is wasnt flash
sleep.gif

You're an idiot... Not just a little idiot either, but a big huge idiot. DSi didn't get flash support because the DSi has a 133mhz processor... You were never ever going to be able to decode youtube video on that.

Opera on mobile phones have full mobile flash support (including being able to play youtube) but they are on phones that have 600mhz+ processors. Honestly the type of webbrowser nintendo decides to use should be little to no consequence as long as they have the basic features... It was probably just cheaper to go with them versus Opera for 3DS.

Doyama: You hit the nail on the head... The problem is that all of the DS (regular) encryption keys have long been known... What initially happened was that you required a passthrough cart to pass commands to the GBA slot... To accomplish this they had to use a real cart to bypass the DS's security and then used a hole in the DS firmware to allow for playing games (and dumping the firmware itself unencrpyted for dissecting)

Nintendo DID fix this with the updated DS models (red models of DS phats and later), the problem was that once the hackers got inside the system, they had all of the keys needed to fake a real DS cart.

The DSi originally fixed this by using a whitelist... Basically a giant list of all existing games at the time, the DS flash carts obviously didn't match this (they all had custom icons/headers) and thus couldn't load. Newer DS games wouldn't be on the white list, but they'd have an additional security with a new encryption not known to the hackers. Hackers got around this by using official icons/headers from real games that were on the whitelist... Nintendo's response? Use a combination of white and black lists... Basically if the game matches a game on the white list that's a KNOWN pirate cart game as well, it does an additional integrity check on the cart (making sure additional files in the ROM match what they should be)... Hackers to get around this, then choose ANOTHER white listed game... Lather, rinse, repeat.

The only way nintendo can truly stop DS carts at this point is to have a massive white list that covers the ENTIRE game's integrity, EVERY games integrity. The problem with this method is that DS games can be quite large, and scanning 128MB of data before it can boot a game would take a while and would be VERY frustrating to end users... so it's not an option. At this point nintendo is just trying to frustrate hackers while doing their best to keep the 3DS carts secure.
 
Rydian said:
Nollog said:
So it stores information on the pokemon you're raising magically?
The hypothetical situation was if the 3DS tried to access the filesystem. The situation would fail as the pokewalker is not accessed like a filesystem.

Just like when you're requesting a web page from the internet, it is stored on a filesystem, but your computer is not accessing it the way it would access a filesystem.
Data needs a file system to be read and written.

Yes it is. It's reading the data from the filesystem.
It is downloaded from a server, and put on your computer, where it is read and decoded.
 
Nollog said:
Data needs a file system to be read and written.False.
[*]You don't need a filesystem to keep things in temporary memory.[*]http://en.wikipedia.org/wiki/Dd_(Unix)
That linux command can be used to read and write data to a drive without a filesystem. In old days it was used to squeeze a bit more space out of a floppy since you wouldn't have the filesystem overhead taking up additional space.
Nollog said:
Yes it is. It's reading the data from the filesystem.That's not how the internet works.
In the case of your web browser loading a page it's reading a stream of data from the network.

The reading from the filesystem is handled by the server It reads the data it needs and then sends data across the network (note that the data it sends is often not the data it reads from the drive, what with how common server-side programming languages are). I can give you an example of a server reading data from a filesystem and then sending completely different data that doesn't exist on it's filesystem if you'd like, I'm not including it because this post is messy enough already.

QUOTE(Nollog @ Mar 1 2011, 01:20 PM)
It is downloaded from a server, and put on your computer, where it is read and decoded.
No, it's read and "decoded" in memory. Caching is on the harddrive is done after getting it, and is optional. Is was implemented in PC browsers because at the dawn of the internjet it could take several minutes to download a page (there was shit before 56K dialup even), thus if the browser cached it it wouldn't have to download it again on an upcoming visit, making browsing faster.
 
Nollog said:
Rydian said:
Nollog said:
So it stores information on the pokemon you're raising magically?
The hypothetical situation was if the 3DS tried to access the filesystem. The situation would fail as the pokewalker is not accessed like a filesystem.

Just like when you're requesting a web page from the internet, it is stored on a filesystem, but your computer is not accessing it the way it would access a filesystem.
Data needs a file system to be read and written.

Yes it is. It's reading the data from the filesystem.
It is downloaded from a server, and put on your computer, where it is read and decoded.
But as soon as your internet connection (or in the case of the PokeWalker, the infrared connection) is cut, there's no more access.
If Nintendo could somehow reverse engineer a flashcart's bootstrapper (which should contain info as to how the microSD is accessed) and block that method, there goes a hardware series.
 
TehSkull said:
But as soon as your internet connection (or in the case of the PokeWalker, the infrared connection) is cut, there's no more access.
If Nintendo could somehow reverse engineer a flashcart's bootstrapper (which should contain info as to how the microSD is accessed) and block that method, there goes a hardware series.

Internal Memory in Flashcarts?
 
Rydian said:
Nollog said:
Data needs a file system to be read and written.False.
[*]You don't need a filesystem to keep things in temporary memory.[*]http://en.wikipedia.org/wiki/Dd_(Unix)
That linux command can be used to read and write data to a drive without a filesystem. In old days it was used to squeeze a bit more space out of a floppy since you wouldn't have the filesystem overhead taking up additional space.
Nollog said:
Yes it is. It's reading the data from the filesystem.That's not how the internet works.
In the case of your web browser loading a page it's reading a stream of data from the network.

The reading from the filesystem is handled by the server It reads the data it needs and then sends data across the network (note that the data it sends is often not the data it reads from the drive, what with how common server-side programming languages are). I can give you an example of a server reading data from a filesystem and then sending completely different data that doesn't exist on it's filesystem if you'd like, I'm not including it because this post is messy enough already.

QUOTE(Nollog @ Mar 1 2011, 01:20 PM)
It is downloaded from a server, and put on your computer, where it is read and decoded.
No, it's read and "decoded" in memory. Caching is on the harddrive is done after getting it, and is optional. Is was implemented in PC browsers because at the dawn of the internjet it could take several minutes to download a page (there was shit before 56K dialup even), thus if the browser cached it it wouldn't have to download it again on an upcoming visit, making browsing faster.
"dd is a common Unix program whose primary purpose is the low-level copying and conversion of raw data. dd is an application that will "convert and copy a file" [1] according to the referenced manual page for Version 7 Unix and is most likely inspired from DD found in IBM JCL, and the command's syntax is meant to be reminiscent of this;[2] in JCL, "DD" stands for Data Description. dd is used to copy a specified number of bytes or blocks, performing on-the-fly byte order conversions, as well as more esoteric EBCDIC to ASCII conversions.[3] dd can also be used to copy regions of raw device files, e.g. backing up the boot sector of a hard disk, or to read fixed amounts of data from special files like /dev/zero or /dev/random.[4]
It is jokingly said to stand for "disk destroyer", "data destroyer", or "delete data", since, being used for low-level operations on hard disks, a small mistake, such as reversing the if and of parameters, can possibly result in the loss of some or all data on a disk."
Unix isn't linux, but forgetting that, RAW is a filesystem.

Websites are cached to your hard drive when you visit them.

RAM has order, if it didn't nothing would work.
 
RoxasIsSora said:
TehSkull said:
But as soon as your internet connection (or in the case of the PokeWalker, the infrared connection) is cut, there's no more access.
If Nintendo could somehow reverse engineer a flashcart's bootstrapper (which should contain info as to how the microSD is accessed) and block that method, there goes a hardware series.

Internal Memory in Flashcarts?
Isn't that what NinjaPass did, sorta?
 

Site & Scene News

Popular threads in this forum