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.
Related
For example, when the magic_number is 0xa1b2c3d4, the ether_type is 0x0008.
Then, if the magic_number is 0xd4c3b2a1, will the ether_type be 0x0800?
I only have .pcap files that the magic_number is 0xa1b2c3d4, so I cann't verify myself.
Or someone may upload a .pcap file whose magic_number is 0xd4c3b2a1, then I can analysis myself.
Thanks.
According to tcpdump manpage :
That allows software reading the file to determine
whether the byte order of the host that wrote the file is the same as
the byte order of the host on which the file is being read, and thus
whether the values in the per-file and per-packet headers need to be
byte-swapped.
I think the answer is yes.
The Ethernet type field is always in big-endian ("network") byte order in a packet, so, to read it, you must convert it from big-endian byte order to your machine's byte order, using, for example, ntohs().
This is independent of the byte order of the host that wrote the file; using ntohs() will work on all machines with all pcap files.
(Bear in mind, however, that there are machines on which you would have to fetch the Ethernet type field - or any other multi-byte integral field - a byte at a time and assemble those bytes into the value, because those machines trap on unaligned memory accesses. See, for example, the EXTRACT_ macros/functions in extract.h in the tcpdump source.)
i use tcprewrite to rewrite my raw pcap files (change MAC address and then change the IP) from CAIDA dataset. I came across this problem.
command use as follows:
sudo tcprewrite --infile=xxx.pcap --dlt=enet --outfile=yyy.pcap --enet-dmac=00:00:00:03 --enet-smac=00:00:00:1f
the error
pcap was captured using a snaplen of 65000 bytes. This may mean you have truncated packets.
I tried to search for the solutions from web and unfortunately i cannot solve it. According to this thread
http://sourceforge.net/p/tcpreplay/mailman/tcpreplay-users/?viewmonth=201201
the error rise because of the packet is not captured since the beginning.
Does anyone has an idea how to solve this problem?
pcap was captured using a snaplen of 65000 bytes. This may mean you have truncated packets.
Or it may not and, in fact, it probably doesn't mean you have truncated packets.
The packet capture mechanism on some systems requires that some maximum packet length be specified, but it can be something sufficiently large that, in practice, no packets will be larger than the maximum and thus no packets will be truncated.
65535 was often used as such a maximum - Wireshark's done so even before it was renamed Wireshark, and tcpdump was first changed so that "-s 0" would use 65535 and then changed to default to 65535. tcpreplay is treating any maximum packet length < 65535 as "not trying to capture the entire packet", but warning about, for example, 65534 is a bit silly.
Tcpdump and Wireshark recently boosted the limit to 262144 to handle some USB captures.
(The limit is chosen not to be too big - the pcap and pcap-ng file formats allow up to 2^32-1, but some software might, when reading such a file, try to allocate a 2^32-1-byte buffer and fail.)
So, don't worry about it, but also don't explicitly specify a snapshot length of 65000 - explicit snapshot lengths are useful only if you want to capture only part of the packet or if you have an old tcpdump (or ANCIENT Ethereal) that defaults to 68 or 96 bytes, and, in the latter case, you might as well go with a value >= 65535.
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. :)
What happens if a wrong format IP is given to gethostbyname function in perl? One of our scripts was behaving weird when given a wrong format IP (say 1.1.1). On debugging, found that gethostbyname was returning a value when given 1.1.1 for example..any thoughts on this?... In my opinion, gethostbyname should return undef, right?
In the beginning of IPv4, before CIDR, addresses were considered to be composed of a network part and a host part. The parts could be written sort of independently in dotted decimal form, and didn't need to be fully decomposed into bytes. So 1.1 is host 1 on network 1, equivalent to 1.0.0.1 or you can also write it as one big 32-bit number: 16777217. There was a time when people used URLs like http://16777127/ to show how clever they were. That was ruined when spammers started doing it to fool filters.
Somehow, when I ping 1.1.1, it goes to 1.1.0.1. I would have guessed 1.0.1.1. I'm not sure what the rule is to decide how it's broken up exactly.
These old forms are not widely supported (or even understood) anymore, but they haven't been completely rooted out from all the tools and libraries.
P.S. on my first attempt to submit this answer, stackoverflow said:
Your post contains a link to the invalid domain '16777127'.
Please correct it by specifying a full domain or wrapping it in a code block.
Which is sort of what I meant by "not widely supported".
Numeric IPv4 addresses can be written as 1, 2, 3 or 4 numeric components. Each non-final component represents 8 bits (1 octet), and the final represents as many bits required to give the full 32 bit address. Thus, the following all represent the local loopback address:
2130706433
127.1
127.0.1
127.0.0.1
Each component itself may be written in decimal, hex or octal; thus the following all also encode the same address
0x7f000001
127.0x01
0177.0.1
0x7f.0.0.1
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