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 ...
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 ...
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 ...
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.
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 ...
There are plenty of non-Linux solutions for embedded systems, ranging from an RTOS such as eCos, FreeRTOS, ThreadX, Nucleus and many others to a completely monolithic, custom made firmware without any specific OS environment. About the only way to find out for sure is to start disassembling and figure out how it works.
My old presentation may be of some use ...
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 ...
Intercept the traffic between the browser / plugins and the server. I would start with Wireshark.
The traffic between the client and the server will be some form of network requests which you can write code to generate / consume.
My college has its erp platform in a flash interface, accesible only via Internet Explorer.
Thing is, accessing the erp from amything other internet explorer results in the browser download a flash file "campus-lynx.swf". This means the platform is locked to windows only.
You are obviously wrong. Application work in firefox without any problems. ...
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 ...
So in the video he ask how that can be passable? and he answer that AVR used Harvard architecture , and data and code in diffrent address (not like x86)
Different means are used to access each.
In simple terms, only instructions and any operands embedded within the instruction stream would be read from program memory. Any "memory access" by code would go ...
Assuming nothing is cryptographically signed, that should be possible. You simply need to follow your steps in reverse. If you used binwalk's extract option, that made it too easy; you'll want to figure out how to unpack/pack the image manually (maybe the verbose option will provide more info on the steps taken). I realize this is a generic sounding answer, ...
This depends very much on how exactly you plan to write the data back; some options would accept only "payload", others may need OOB too.
If you use U-Boot's nand write, it seems it accepts data without OOB but you need to erase target pages manually first.
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.
I was doing a similar research and apparently there's no way to read it. STC says that it's a "feature" of their microcontrollers, the bootloader protects the code.
Links related to this question for anyone who might be interested:
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 .