So, I have figured it out myself in the end. I'll try to describe the process.
First, a bit of background on NAND: it is organized in pages which are grouped into blocks. You can read or write a single page at a time but erasing (which turns all bits to 1s (so bytes to FFs)) can be only done one block at a time (writing can only change bits from 1 to 0 but ...
Hard to say with so little info, but I suspect that you edited the data after it has already been parsed by the game code. You probably need to intercept the moment it arrives from the remote server and change it then.
I am a developer of the Rockbox open-source project. We figured out the encryption of the firmware upgrade a look time ago by essentially doing the same thing (dumping the chip).
upgtool can extract the firmware from UPG tools, those can be extracted from the firmware upgrade installer using cabextract and looking at the file Data/Device/NW_WM_FW.UPG It ...
The bootloader is in the flash, so you have to dump it first by using:
dd if=/dev/mtd0 of=/tmp/mtd0
nandump -of /tmp/mtd0 /dev/mtd0
After it you have to copy to an SD card, USB device or send via netcat (nc) to a socket. Of course you can do it in one step also.
You can send files via netcat with 2 easy steps.
Start netcat in your PC in ...
First of all the ECC scheme used does not necessaryly have to be the for all the flash erase blocks. There are ususally 3 different types of flash partitions used and for every type the method to specify the used ECC code differs:
The one that are accessed by the ROM bootcode
The ones that are accessed by the bootloader (usually u-boot)
The ones that are ...
This combination (up, up, down, down, left, right, left, right, A, B) is a well known Konami code so just pressing those keys should trigger it.
The real question here is when, or if at all this code is loaded so that it actually is hooked-up and can be triggered.
Hello I actually solved my problem , the answer was in the environnement if you read carfully you can get the commands that save the linux parition from the kernel_load_address :
actually the problem could be solved by simply transferring the linux.bin image using ymodem to the memory of the device then simply write the image from the correct loaded address ...
It seems you have an SPI NAND chip and not a more common SPI NOR on which flashrom specializes. The support for SPI NAND in flashrom is pretty new, covers only Toshiba and Micron for now and is not even merged in the master branch yet, so it's very unlikely your build even has it. You can try to either add support for GigaDevice on your own (e.g. from the ...
In the automotive domain take a close look at the Unified Diagnostic Services (UDS) protocol. Most modern cars implement at least some of the services provided by UDS, typically over the OBD-II CAN interface.
For reading out flash memory, service $35 (Request upload) can be used, if implemented. However, most likely you will have to get security access via ...
The MX25U1635E is designed for 1.8 volt logic, whereas your programmer is designed for 3.3 or 5.0 volt logic. You're going to need a 1.8 volt adapter for the programmer or you will damage the MX25U1635E.
If you google CH341A 1.8 volt adapter, you can find them for relatively cheap.
I'm not too familiar with eCos, but my guess is that device address is not a memory address but the address of the hardware device used to access the SPI chip by the OS and bootloader, i.e. something similar to the PCI address like B0:D31:F0 (bus 0, device 31, function 0) on the PC. You should try to find where the flash is mapped into memory and read the ...
Just a fast answer as future tip for NAND issues.
When make reading of NAND flashes (doesn't care if bga, tsop..), not all programmers make clear dump, normally it includes dummy blocks as you mentioned OOB data.
As NAND dumps should be multiple of 8, like 64, 128, 256MB...if the file you dump is larger than typical size, e.g. 132MB, then is mandatory to ...
The SD card controllers are usually embedded deeply into the card and do not offer easy access to their firmware (SPI or otherwise). However, they may have undocumented backdoor commands over the SD interface that are used for factory testing.
You can find the details and investigation of one family of controllers in bunnie & xobs's 30C3 talk: slides, ...
Do these extra bytes appear at regular intervals? If so, they could be the spare or OOB(out of band) bytes which are present in most NAND chips for error checking or housekeeping (bad block management etc.) in most cases you can discard them and analyze just the “useful” data. See my other answer for some background.
If the specific ECU you have implements flash reading CAN commands and if you know the command format (and possibly some password necessary to unlock them) then it may be possible.
Unfortunately to discover these commands you need to analyze the firmware so it is somewhat of a chicken and egg problem.
At a guess, it is using NAND flash. This type of flash has good density and is reasonably cheap but it has one limitation: individual bits can be only toggled from 1 to 0 but not the other way around. If you need to set any bit to 1, you need to erase it, and NAND can only be erased in whole blocks (block size and layout is chip-specific). So, to write ...
After to study Chapter five of MPC5606's reference manual, I expected
that the tool would send a 64-bits password, but I didn't found it in
communication yet ( the time of communication is too big, almost 10s
Since we don't have your log, we can't tell if the password is present. Quite possibly your specific device does not have security option ...
I don't know if it applies exactly but the following document from QNX suggests that:
spare is made up of "sequence #", "file ID", "offset", "CRC" and "ECC"
there are special blocks that contains wear-levelling information such as bad blocks, erase count and file system hierarchy
Thus it is possible the information you are looking for is not in the spare ...
https://www.microsoft.com/security/portal/threat/encyclopedia/entry.aspx?Name=Exploit%3aJS%2fMeadgive this malware will download packages based on existing vulnerabilities.
One way to handle this would be to setup a virtual machine with one of these vulnerabilities and use Wireshark to monitor network activity and ApateDNS to forward any DNS ...
Since there is no standard NVRAM format, you will need to find whatever code reads and/or writes it and analyze how it works. If the maker provides GPL source code, maybe some details can be gleaned from it. However, in some cases the format may be obvious by just looking at the data with a hex editor/viewer, e.g. see this blog.
Sounds like you're good to go. Yes the Raspberry has a SPI interface so you can connect the Winbond to it and use the "flashrom" to dump it. Attach the SOIC clip to the chip and connect the pins to the Raspberry Pi respective pins:
Also the appropriate voltage Vcc 3.3 or 5. Pi can provide both .
You should check this talk at BlackHat 2014 and this one from Bunnie & Xobs at 30CCC.
I could go about some details but it's so vast, it is meaningless to try to explain the details of reversing a chip here. Decapping can be helpful if you're willing to probe the IC using needles and an oscilloscope and reverse engineer a protocol or extract data; or ...
If it's really a NAND flash chip conforming to ONFI standard and if you have an universal programmer, it should be possible to read its ID.
www.onfi.org/~/media/onfi/specs/onfi_2_1_gold.pdf — refer to section 5.5 "Read ID Definition"
Also, your programmer may prompt you to specify what kind of NAND chip you're trying to read in order to determine its ...
Igor certainly knows six or seven orders of magnitude more on this subject than me, but it seems to me that if you're trying to get at the flash chip, not the USB controller, you probably won't get that from the VID/PID. I am probably wrong, bc Igor, and bc I'm unfamiliar with USB Flash Drive designs.
But if I'm right, and if it is an SPI chip, you can ...
The site flashboot.ru collects various utilities for working with USB flash drives, including identification tools which can detect the vendor and device ID of the device, and in some cases even the exact flash chip:
Turns out this was a problem on my end.
For those curious: it turns out that the file I wanted to load was a pure .SWF file. I don't have enough experience with Flash to have immediately known a Loader().loadBytes() with a data type of "data.BINARY" was necessarily going to be a Flash file (as opposed to some form of assembly).
The file was obfuscated ...
Please try https://ohse.de/uwe/software/lrzsz.html
And also, read about kermit, xmodem, ymodem and zmodem protocols - these are file transfer protocols over serial lines.
U-boot has a support to receive files with "loady" command. We use it together with lsz command from lrzsz package, to update the bootloader.
I cannot see any support for sending files, ...