I know how the 1st 8 general purpose registers are represented in PIN, like REG_GAX, REG_GBX and so on. However I cant seem to find in the user manual how registers r8 to r15 are represented.
REG_GAX and REG_GBX are shorthand registers, for example REG_GAX is REG_RAX in 64-bit or REG_EAX in 32-bit.
Excerpt from source/include/pin/gen/reg_ia32.PH, see also the file on github:
REG_GAX = REG_RAX, ///< eax on a 32 bit machine, rax on 64
As R8 up to R15 don't exist on 32-bit architecture, they have no shorthand except their own name (REG_R8, REG_R9, ...)
Related
I'm trying to disassemble a BIOS image for the 68000, and I'm having trouble getting IDA Pro 6.5 to correctly cross-reference addresses.
For those who aren't aware, the Motorola 68000 has a couple of interesting features/quirks related to addressing:
When given a 16-bit absolute address, the processor sign-extends it to 32 bits before dereferencing it.
The 68K uses a 24-bit address bus, so the high byte in a 32-bit address is ignored.
The original authors of this BIOS took advantage of these properties in a number of places to save a few bytes: for any address above 0xFF8000, it's possible to specify the address using only two bytes instead of four. For example, if I wanted to access the memory at address 0xFF9134:
lea (0x9134).w, a0
< sign extension >
lea (0xFFFF9134).l, a0
< discard high byte >
lea 0xFF9134, a0
The problem I'm running into is that IDA Pro is performing the sign extension, but then considers the entire 32-bit address instead of only the lower 24 bits. IDA ends up trying to cross-reference addresses that don't (or at least shouldn't) exist, and any segments/code/data I have in the 0xFF8000-0xFFFFFF address range get completely ignored.
I'm still new to IDA Pro, so I don't know if this would be solvable with a script, let alone how to write such a thing. Is there a way I can get the disassembler to correctly handle this dirty/clever addressing trick?
I have the same problem. My decision was to create custom_ana callback and then change every operand address as the following: op.add &= 0xFFFFFF.
But it is not so easy. Because you don't have fully recognized "cmd" at this moment, and you must prepare it by your own code.
Intel manual volume 3, said that there's only CR0,2,3,4 + CR8 in 32E mode, and CR1 is reserved. But when I compile instruction in title, N could be any value < 16. I disassemble the obj file and found that it's encoded just follow reference when N<8. And when 7< N <16, it's encoded same as before but a LOCK prefix is added(make it a "serializing instruction" as NOTED in MOV cr version?).
Why it's encoded without any complain and is this encoding legal? Are those CRs really exist or they are just alias for other registers?
I. About "LOCK" prefix: current x86 really doesn't have fixed prefix meaning. There is the set of one-byte prefixes which all have their initial meaning (LOCK, REP, CS segment, etc.) but the latter is applied only to instructions where it has direct sense. But there are other usages when an instruction doesn't have such sense. For example, F3 (REPE) before BSR/BSF converts them to LZCNT/TZCNT respectively. With ordinary memory readings, the same REPE converts to XRELEASE. Segment prefixes 2Eh and 3Eh before branch instructions are prediction hints (used in Pentium 4 line). So, don't treat basic prefix roles as thorough principle.
II. Ongoing question: why reserved CRs should not be encoded, to your mind? I don't see any principal violation in this. For analogy, why don't you require IO instructions to encode only existing ports? You'd accept CR space in the same manner as IO or MSR space, and this won't be a problem anymore. :)
I am reading brokenthorn.com ‘s O/S development tutorials one of the tutorials, the following code is there.
http://www.brokenthorn.com/Resources/OSDev3.html
I don’t understand why this code clear 510 bytes. org, bits, cli, hlt are there in the code too. Shouldn’t it be changed to less than 510 bytes? Could it be typo or something?
Thanks.
;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;
;*********************************************
; Boot1.asm
; - A Simple Bootloader
;
; Operating Systems Development Tutorial
;*********************************************
org 0x7c00 ; We are loaded by BIOS at 0x7C00
bits 16 ; We are still in 16 bit Real Mode
Start:
cli ; Clear all Interrupts
hlt ; halt the system
times 510 - ($-$$) db 0 ; We have to be 512 bytes. Clear the rest of the bytes with 0
dw 0xAA55 ; Boot Signiture
;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;
It's not clearing 510 bytes, it's clearing 510 - ($-$$) bytes. Since $ is the current position, and $$ is the start of the section, it's clearing 510 - (length of the section up to that point) bytes.
This will fill the block correctly up to two bytes from the 512 byte limit, and put the signature on the two last bytes.
The boot sector is 512 bytes long, and is identified as such by the final two bytes begin set to 0xAA55. This leaves 510 bytes for the loader's actual code, which is precisely what the provided example fills when assembled. If your resulting binary isn't precisely 512 bytes long then you may need to specify a plain binary output format, though in the case of nasm this is the default setting.
In practice there are other magic bytes which need to be present for partition tables and such, and typically the first stage loader is used for little more than reading in and executing some more code.
The NOP opcode for x86/x86_64 is 0x90, but which is the analog on the iPhone with the ARM instruction set?
MOV r0, r0 is traditionally used in ARM code, which has the opcode 0xe1a00000; MOV r8, r8 is used in THUMB code (opcode 0x46c0)
ARMv7 has an actual NOP instruction, with the following encodings:
0xbf00 2 byte thumb2 form
0xf3af8000 4 byte thumb2 form
0x*320f000 4 byte arm form
When targeting earlier versions of the architecture, assemblers translate NOP into the MOV instructions that moonshadow listed.
You shouldn't need to use the actual opcodes, as the development tools understand NOP.
I would like to add that non-conditional NOP for armv7 is 0xE320F000.
Note that if you are going to patch a file you will need to write bytes in reverse order (little endian) - 00 F0 20 E3
I want to build up an ANT network (e.g. see wikipedia article ) and develop sport accessories using the iPhone 3Gs with integrated ANT Controller (used by Apple for Nike+iPod devices) to communicate with them. I need to know which ANT version the controller is (ANT or ANT+), what it's able to do (receiver/transeiver) and how I can acces the controller with software on iPhone. Until know I was able to access the serial interface and open a socket over WLAN but the only information for this topic was this one. It's one year old before the 3Gs with integrated ANT and External Accessory Framework was released. Changed that something? Are there new efforts of other groups? Every information would be helpful. Thanks.
the apple / nike footpod is not an ANT compatible device. It works with a nordic transceiver nRF2402 but with a different protocol. I reverse engineered it:
The Apple foot pod works with a nRF2402 transmitter and a PIC16F688 microcontroller.
Repetition rate: 1000ms
Number of configuration bytes: 2
Number of address bytes: 2
Number of raw data bytes: 28
Remark: the configuring is sent just before power down, i.e. 2 bytes are transmitted at that time, first 0xe7 then 0x99. The device remains active for approximately 5 seconds after a step has been detected. The device works with a simple piezo sensor to detect footsteps.
A fully transaction is made by sending 3 blocks of 9 bytes, then 11bytes then 10 bytes (almost no gap between each byte within a block, bit clock is below 2us) with a gap of 1.5ms between each block. A crosscheck with the configuration frame of the receiver shows the following:
0x00 0xe0 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0xc2 0xbd 0x43 0x4f 0x33
This means (see datasheet of nRF2401; configuration):
- channel 0x19 -> 2425MHz
- RF power max; 16MHz clk; shock burst; 250kbps; 1 RX channel active
- CRC enabled; CRC 16bit; address length 16bit
- Address for channel 1: 0xc2bd (high byte first)
- Address for channel 2: all 0x00
- 0xe0 -> 224 data bits for channel 1
- 0x00 -> 0 data bits for channel 2
The address length is 16 bit, and 224 bits of raw data are transmitted. The standard device address is 0xc2 0xbd anyway the data sent via link starts with the following pattern:
Address: 0xC2 1. byte of block 1
0xBD 2. byte of block 1
Data: 0x0D 3. byte of block 1
0x01 4. byte of block 1
0x47 5. byte of block 1
0xA0 6. byte of block 1
0x54 7. byte of block 1
0x22 8. byte of block 1
0xA0 9. byte of block 1
. 10.byte of block 2
. 11.byte of block 2
.
hope this helps a little
What makes you sure the iPhone (3GS) uses a nordic transceiver? It seems not visible to me on the tear down at ifixit. We assumed the BCM4325 is used for the "ANT" communication as well.
by the way, the ANT and ANT+ protocol works with full speed 1MBit/sec instead of the lower footpod speed of 250kBit/sec. The length of a frame in the nike footpod is also different compared to the ANT protocol. From a HW point of view, it is possible to run an ANT or even ANT+ protocol on an i-phone without any external HW! The transceiver is already integrated. If one had access to the nRF2401 transceiver within the i-phone writing an ANT protocol handler is a piece of cake, the ANT protocol is a pretty stupid thing and easy to implement! The ANT+ is encrypted with an 8 byte key. I guess they use the safer algorithm but I'm not sure. See also: SAFER (Secure And Fast Encryption Routine) is the name of a family of block ciphers designed primarily by James Massey on wikipedia (source code downloadable at ETH in zürich or just ask me... good luck