To extend the answer of perror:
Perhaps you should take a look into a recently published whitepaper named Breaking the x86 ISA, by Christopher Domas. It was published on blackhat17 and describes an approach for digging into x86 chips and extracting hidden machine instructions.
Breaking the x86 ISA
A processor is not a trusted black box for ...
Although I think the questions are too broad and I agree with @cb88 that the datasheet should give you all you need to know, I'll try to answer some.
How to dump the memory
First option is desoldering the chip from the board. After having done so you have 2 options
Read the chip out using a chip programmer like e.g. Dataman that supports your ...
As you may suspect, it very much depends on the hardware. In general, you are correct, JTAG and/or UARTs can be often be used to get a copy of the firmware (downloading a firmware update from the vendor is usually the easiest way of course, but I'm assuming that is not what you mean).
JTAG implementations typically allow you to read/write memory, and flash ...
I found the solution. Double click the variable name (configSpaceBuffer in this case) which brings up the stack window for the method where you can undefine the invalid variables and then define it as an array.
Here is the output after this change:
_this->ConfigSpace1 = configSpaceBuffer;
_this->ConfigSpace0 = configSpaceBuffer;
I downloaded the EZ-ZONE Configurator and reverse engineered it to see how it works.
The serial data you're seeing is actually the BACnet MS/TP (master-slave/token-passing) protocol. You can find the Wireshark protocl decoder for it here. However, to save you the time, I'll help you get to the meat of calculating those check bytes.
In BACnet parlance, 55 ...
The markings look like an Atmel part (it starts with "AT", which is common for Atmel parts). Given the size of the chip and context which you provided, I figured it was probably a serial EEPROM. Looking through Atmel's serial EEPROM datahsheets, your mystery chip is almost certainly an Atmel AT25128B-SSHL SPI EEPROM, which matches your chip's product ...
Are there open source projects that completely restore the inner circuitry of modern Intel CPUs?
Not for modern CPUs. Not even for 10-15 years old CPUs.
In 2015 the reverse engineering of Intel 8080 was finished, and this CPU is from 1974 year (actually, Soviet i8080 clone KR580VM80A from 1980s was reversed). Both CPUs were made with 6 μm feature size, ...
Well if you want to know how it was done exactly
Then download the Z80 die shot of model you want to investigate, crop the ALU part and identify all the gates you can until you dig to Zero flag your self (sorry for indirect answer).
Here my Z80 ALU post processed die shot
white - metal
green - poly-Si
red - dopped-Si (diffusion)
Gray - conductive ...
It was made by humans so there's a spec.
I googled it.
Here's a manual which talks about the Axial MX from Accom ~2005. If it's a series of edit controllers, they'll likely work the same under the hood and use the same protocol from one version to the next.
Looks like an RS422 Serial. So you just need to hook it up to a computer with a serial port and take ...
As Jason Geffner said its a DIN 45326 connector.
As far as I know they're normally used in audio, but here is a pin out while used for serial.
Next step would be using an Oscilloscope to determine the baud rate (and voltage). Often the oscilloscope software has some build in tools for automatically determining the baud rate. If not, you simple divide 1 by ...
But surely something must know where all the devices live in memory, because something is responsible for routing memory reads/writes to the correct device.
In embedded devices there's nothing like PCI (well, it may be present but it's just one of the many HW blocks). So you can't just scan all possibilities to discover the existing devices. The code must ...
To create a full duplicate, able to generate valid transmission packets you'll need the following information:
Button press mapping
32 bit of KeeLoq encrypted data
See attached Figure 1-2, from the datasheet, near "Transmitted information" at the bottom right:
Using those three pieces of information you can theoretically create your own ...
Frying your board:
Just touching one single pin of a chip, or connecting it to ground over a reasonably high-resistance voltmeter, will generally not fry a board. However, there are ways to fry a board:
static electricity. Every instruction to insert a PCI card in your computer comes with a warning about that, and there is a reason. However, i found ...
In fact, the CPU are much more checked and verified than programs. It is very unlikely to find a (significant) bug in a CPU. Even though it happens from time to time.
Therefore, it is much more interesting to look at software bugs (because they are more likely) than hardware bugs.
Yet, you have a few occurrences of hardware bugs that led to disclosure of ...
For figuring out JTAG pinout, there are many hits on google for "JTAG Finder". I also have my own implementation:
It's for mbed but I tried to make it easily portable (original version was for a Stellaris board).
Here's a quote from the comment which describes the basic approach:
The overall idea:
I had to add just a few things to have a clear mind (although the other answer is really good and got my up-vote already).
Single pin touching with a probe can blow up your HW.
And I do not mean the obvious static charge or what so ever from the common reasons. With nowadays chips some pins runs on very specific voltage ranges and even a high impedance ...
I don't have an actual answer but here's a few leads.
Freescale has some chips in the i.MX6 family with the EPD interface:
I think the signals are described in the CPU datasheet, but not the protocol. Even with the older devices when a dedicated controller had to be used, its datasheet would describe only the ...
I created a video how I identified a possible JTAG connection with a multimeter. Here is a picture showing which pins are connected and it matches with a standard JTAG pinout for VCC and GND. This is an indication that it could be JTAG, though it doesn't have to be.
Extracting the content of a hardware chip is known as "snarf"ing. (That term may help with your Google searches.)
To snarf the contents of a chip, you need a ROM reader/programmer, such as one of the devices from http://www.needhams.com/programmers.htm
There is no SPI specification that dictates things like read codes or address lengths, AFAIK; these are chip-specific and have been generally standardized by vendors of SPI EEPROMs and flash chips (though I"m not aware of any formal agreement among vendors).
Most SPI EEPROMs use two bytes to specify the read address, because they are so small that they only ...
(I'll assume you're talking about the boot process using legacy BIOS as UEFI situation is different)
The boot manager is not a PE, or, rather, not just a PE. It starts with 16-bit realmode part. You can check it yourself by looking at the file.
0000000000: E9 D5 01 EB 04 90 00 00 │ 00 52 8B C3 0E 07 66 33
0000000010: DB BA 01 00 E8 34 00 E9 │ 51 01 2E 88 ...
If this a commercial device sold in United States, it must be FCC certified and so must have a label with the FCC ID mentioned somewhere. You can use this page to search for any documents FCC has on file for this device. They should mention the frequencies on which the device operates.
Consider the code that you were able to modify. The decimal representation of your modified code is 065375.
The checksum of 064095 = 3*0 + 6 + 3*4 + 0 + 3*9 + 5 = 50 (≡ 0 mod 10).
The checksum of 065375 = 3*0 + 6 + 3*5 + 3 + 3*7 + 5 = 50 (≡ 0 mod 10).
So it seems that this disk was accepted because the checksum matched, while your other disks weren't ...
First a thought regarding the volumes that don't seem to line up. The first link in the Q discusses purge and charge sections - these will contribute to the volume and it's possible that the table of volumes assumes some contribution from these processes that may not be the minimum
Second - some more data for you:
We have a water dispenser disc (it ...
The way I did it on the Kindle was to load the flash partitions into memory and then using memory dump commands to dump them in hex format (and then some Python script to convert hex back to binary). It was kinda slow but did achieve the goal.
Your U-Boot does not seem to have the bbm command but fload - load binary file from a filesystem image for system ...
I use sf read and it works pretty good. It can be called as follows
sf read [addr] [offset] [len]
So for your case, reading romfs would look like this:
sf probe 0; sf read 0x82000000 0x40000 0x370000
Then you can transfer the file to tftp server:
tftp 0x82000000 romfs.cramfs 0x370000
You can also use sf to write to the SPI flash (more info can be ...
The first step is to figure out the purpose of each of those pins. The easiest way to do this is to Google for the LAC-M3600R's service manual (note that this is different from the user manual). That device's service manual contains the following diagram for the back of the faceplate:
As you can see above, the pins are (beginning from top-right, moving ...
I believe both keyfobs send the same data which is
1111 0000 0100
Second keyfob is repeating signal 3 times.
DIP encoding to signal would be byte by byte with swapped nibbles.
00001111 10 => 11 11 00 00 01
Try to use Autodetect parameters in URH.
CPLDs are frequently used for glue logic. They are quite limited compared to FPGAs and implement a sea of gates design rather than more general LUTS found in FPGAs. Although that probably isn't always the case some CPLDs may be nothing more than a tiny FPGA with a built in ROM.
CPLDs usually have a built in ROM making them harder or near impossible to RE. ...
Turns out openocd for ARM11 had a few bugs in it. I ended up making a few changes to get it working as per the arm spec:
Turning on the drain of the data aborts. The check should be:
if (!(dscr & DSCR_STICKY_ABORT_IMPRECISE))
Then added the following code before the C1 control register
/* Enable Debug Cache write back, and ...