boot loader's size - operating-system

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.

Related

SD card does not return token on SPI single block read

I have a Buffalo SDHC SD card with 4GB of storage, and a Raspberry Pi Pico. I have connected the SD card to the Pico's relevant SPI pins and have set the SPI clock speed to 1MHz.
I have reset the SD card with command 0, and have received a successful R1 response of 1 (to clarify, that is all I have done).
Now, I want to read a single block (512 bytes), and after researching, the command code is 17 and the arguments is the block index I want to read (in my case, 0 - 0-511 bytes). I have sent the command, and have received an R1 response of 1 (meaning card is in idle mode), however after some research, I was supposed to also receive a "token" containing 0xFE indicating a successful read followed by the bytes in the sector, or an error code.
However, the only things I am receiving after the initial R1 response are 0xFF bytes which would indicate the SD card is idle. I have tried reading several thousand bytes from the SD card, perhaps thinking the read is taking a while, but nothing, I am only receiving 0xFF bytes with the token nowhere to be found.
Does anyone have any advice on why this could be the case? I have looked over my command syntax and have found it to be correct:
(bits + cmd code) 01010001 (32-bit arguments) 00000000 00000000 00000000 00000000 (CRC value set to 0 due to checking disabled + end bit) 00000001
I have also tried experimenting with a different argument and different clock speeds but to no avail.

M68k - IDA Pro 24-bit addressing?

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.

tcprewrite - truncated packet error

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.

How to encode ASCII text in binary opcode instructions?

I do not need a refresher on anything. I am generally asking how would one encode a data string within the data segment of a binary file for execution on bare metal.
Purpose? Say I am writing a bootloader, and I need to define the static data used in the file to represent the string to move to a memory address, for example, with the Genesis TMSS issue.
I assume that binary encoding of an address is literally-translated-as binary equivalent to its hexadecimal representation in Motorola 68000 memory-mapping, so that's not an issue for now.
The issue is ... how do I encode strings/characters/glyphs in binary code to encode within an M68000k opcode? I read the manual, references, etc., and none quite touch this(from what I read through).
Say I want to encode move.l #'SEGA', $A14000. I would get this resulting opcode (without considering how to encode the ASCII characters):
0010 1101 0100 0010 1000 0000 0000 0000
Nibble 1 = MOVE LONG, Nibble 2 = MEMORY ADDRESSING MODE, Following three bytes equals address.
My question is, do I possibly encode each string in literal ASCII per character as part of the preceeding MAM nibble of the instruction?
I am confused at this point, and was hoping somebody might know how to encode data text within an instruction.
Well I had experienced programming in 4 different assembly languages,and Motorola M68HC11 is one of them.In my experience, ASCII is just for display purposes. The CPU at low level treats everything as binary values, it cannot distinguish between ASCII characters and other characters. Although higher assembly languages like x86 support instructions like AAA(ASCII adjust for addition) which makes sure that after addition of two ASCII numbers the result is still a legal ASCII number.
So mainly it's assembler dependent, if the assembler supports the instruction move.l #'SEGA', $A14000 this might work, but since you are not using an assembler and directly writing op-codes, you have to encode the ascii into binary, example ascii number '1'(0x31) will be encoded as 0000 0000 0011 0001 in 16 bit representation. Also in my experience there's no machine code which can move the whole string. SO in microcode the first character is fetched, then copied to destination address, then second character is fetched and copied it into second location and so on..
Assuming that instruction size is 32 bits long and immediate addressing mode is supported the first two nibbles would suggest the move instruction and the immediate addressing type, next two nibbles would be the binary encoded character and remaining would be the address you want to copy it to. Hope this helps

What's the ANT version in iPhone 3Gs and how can I access it?

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