General Motors > Informatique
[MAC] Le Topic Apple
SaVio:
c'est vrai que passer le cable derriere c'est trop compliqué :o
mega-stef:
--- Citation de: bitman1er le 25/05/11 22:56 ---http://hfr-rehost.net/http://self/pic/469da90c9b20ecb744c2443519cc1feea378354b.jpeg
--- Fin de citation ---
bizarrement, en vrai, le cable est bien plus long :o
Bitman:
--- Citation de: mega-stef le 25/05/11 23:03 ---
bizarrement, en vrai, le cable est bien plus long :o
--- Fin de citation ---
j'espere bien sinon c'est tres con :D
Rajesh Koothrappali:
--- Citation de: mega-stef le 25/05/11 23:03 ---
bizarrement, en vrai, le cable est bien plus long :o
--- Fin de citation ---
Y'a plus de câble maintenant surtout :o
a poil laineux:
OMAGAD [:totoz]
--- Citer ---
iPhone 3G 8GB – Memory size problem
I have a case where the suspect has destroyed his cell phone during his
arrest. The phone would not function at all and is in small pieces. I located
the 48 PIN TSOP NAND chip and found that it was intact. I recovered the chip by desoldering it and cleaning the pins for data reading with a programmer.
I placed the chip in the reader and tried to read it as an 8GB chip as
the iPhone indicated that it was an 8GB model. The programmer kept erroring out and when it did a read, it was only a partial read. One read would get 1.6 GB,
then one would get 5.3 GB, the one would get another random amount, and so on, all of them had error alarms going off during the process.
This led me to try out other programmers, specifically, one that allows
me to manually configure the size of the reads from the NAND chips. This is
when I actually read the chip number off the chip itself. The number for this
chip was MT29F64G08TAA. I located the data sheet and determined that this chip in fact is a 64GB chip.
I reconfigured the programmer to read 64GB and it read with no errors.
As a test, I did a second read for 128 GB and it read up to 64 GB and then 0′d
out for the next 64 GB. This demonstrated that the chip is actually 64 GB in
size and that there is no restriction to read just 8 GB as indicated by the
iPhone 3G 8GB model.
The dump creates two file, 32 GB each. I can read each one using Encase
and they are different, indicating that it was not just reading 32 GB and then
repeating itself. Both 32 GB dumps had different header information which
indicates that I was not just getting 8 X 8GB reads as well.
I have discussed this problem with another expert in our field, Shafik Punja
of Calgary PS, and his thought was the forensic tools are only reading the 8GB
defined partitions through the USB ports. This may be a function of the iPhone
hardware, software, Controller Chip or the Flash Translation Layer that limits
the usage of 8 GB of the 64 GB found on the chip.
Unfortunately, NAND works in a manner that does not restrict this
limitation defined by the iPhone. NAND will use the full 64 GB of the chip as
required to store data and allow for the process of the Wear Levelling
functions. The memory will use the full capacity of the NAND chip and then move around and wipe data as required to store and update the user’s data, , using the full capacity of the ship, that being 64 GB.
During the analysis of this iPhone, I am recovering data
throughout the chip read and some of the user data dates back 3 years including
SMS text, internet history, emails and call logs.
I have opened 3 other iPhone 3G 8GB boards to verify this, one was a
Micron chip similar to this one, another contained a Samsung Chip (K9HCG08U5M SCBO) that shows 64 GB size (the two letters CG indicate the size at 64GB) and another showed a Toshiba chip (TH58NVG6D1DTG80) where the letters NV show it as a 64 GB chip.
Is this just a function of this one type of iPhone or are the other
models (3GS and 4.0) utilizing the same process? How about other types of cell
phones, is this common practise for then as well?
Another expert, that will remain nameless as I have not asked his
permission to disclose it, provides this explanation:
Basically, this is very similar to a USB
drive that its partition is being imaged (Fat16/FAT32 …). Actually this USB
drive has a flash chip inside that in most cases will be larger than the actual
partition (each USB drive manufacturer uses his own FTL and the ratio between declared size and actual flash size is their secret).
You can also see this from a different angle:
If an iPhone physical dump is in dd format, there are no flash spare area’s there, so only the “live” partition sectors are extracted, so there are generally other flash physical sectors that are not extracted.
I have not done any validation on the other chips yet but plan to in
the next few weeks. Shafik suggested that I find another iPhone 3G and then do
a physical using the tools and then do a chipoff to see if there is additional
data recover in that 56 GB unallocated space. I will do this when I can get my
hands on some functioning iPhone 3G’s.
Larry Smith of LVMPD (student of the Chipoff class) had some further
questions into this and here are my responses:
“When you say “During the analysis of this iPhone, I am recovering data throughout the chip read and some of the user data dates back 3 years including SMS text, internet history, emails and call logs.” does that mean you are getting data beyond the 8GB formatted area? Your getting data in the 56 GB “unreadable” area?”
Yes, I am reading throughout the whole 64 GB dump. The information I am recovering is all related to my Suspect so far. What I have to validate with a new test 3G 8 GB phone is the process that Shafik discusses, get a logical and physical dump using the tools, then do a chip off and see if there is stuff in the 54GB area that shows up that did not show up in the tools dumps. There is a lot of duplication of the data and I have to look at whether this is caused by the FTL/Wear Levelling processes like I showed everyone in class, or is the iPhone setup to make duplicate images of the 8GB user partition? The other thing I need to test is whether the chip reader is reading the 8 GB over and over again (8 x’s
over????) but I think I can throw that theory out when I got the reader to read
128 GB and it 00′d out after reading 64GB. If the chip reader was reading just
8 GB over and over again, why not 00 out after reading 8 GB?
“Well, What if the iOS can use that extra 56 GB area for the wear levelling process?”
That is one thing that I am thinking. What reason would Apple put a larger physical chip in the iPhone then they present to the user, is that space used for the wear levelling process to make the phone run faster, especially when the user has almost used up all the 8 GB capacity?????
“Could the OS be programmed to read (only) 8 GB of non contiguous chip space? In other words as the space marked as 0′s gets larger and it can no longer read it, can it reach out for more space in the “unformatted” area to keep its 8GB capacity? Would you see that when
you are reading a chip?”
If that were the case, then we are still left with the 54 GB of residual space that contains important deleted user data, aka evidence. This would mean that the forensic tools are dependent on the iPhone’s controller ship or FTL to let it know what it can read during the acquisitions. How are the tools that do a physical read dealing with this? I would have to validate that theory when I do the new test phone, shopping on Ebay as we speak….. (-:
Shafik also responded with:
“Why is Apple producing iphone 8gb that contain 64gb chip sizes? Economics
perhaps. It might be easier to keep production costs down and produce devices
that state they are of different size capacities and in reality the same size
chip is being used for all of them. I would suspect that if this is occurring in iphones the same could be said about iPod Touch and iPad devices.”
I would like to open this for discussion with other experts who are
involved in the physical and RAW data extractions of mobile phones and see if
anyone can help me with more research on this. I would hate to be missing out
on all this valuable user data if it is there for the picking. Also, how will
something like this shape up in court when a defense lawyer can say that the
evidence to exonerate his client could be found in that 56 GB and you’re not
disclosing or examining this?
This is strictly a discovery that I have run across and I, as others, are looking to find answers to some simple observations made by this discrepancy found on the iPhone 3G.
--- Fin de citation ---
ami apple user, ALL YOUR BASE ARE BELONG TO APPLE §§§
FAiRLiGHT:
chouette, y'a un apple store qui ouvre le 4 juin à lyon :D
Navigation
[#] Page suivante
[*] Page précédente
Utiliser la version classique