I'm just starting to learn assembly language, and we are working with hex addresses. Below is a question of ours. I'm not sure how it adds up though. I know the answer is 0x202C, but how did we get there? Can you help explain the processes step by step, in the most basic way possible to help me understand? Thank you!!
The following data segment starts at memory address 0x2000 (hexadecimal)
.data
printString BYTE "Assembly is fun",0
moreBytes BYTE 24 DUP(0)
dateIssued DWORD ?
dueDate DWORD ?
What is the hexadecimal address of dueDate?
You have three data definitions to add together:
printString is an ASCII text followed by a zero byte. The string part is 15 bytes long, and with the terminal zero byte that makes 16. So the offset of the next data item is 0x2010 (16 decimal is 0x10 hex). printString starts at 0x2000, and the next one starts after the last byte of printString, so you have to add its length to its offset to get to the next offset.
moreBytes is 24 bytes long, because that's how DUP works. BYTE x DUP (y) means "X bytes of value Y". So the offset of the next data item is 0x2028, as 24 decimal is 0x18 hex.
dateIssued is 4 bytes long, because that's the definition of a DWORD. So the next one is at 0x0x2C, since 8+4=12, and that's 0xC in hex notation.
Alternatively, you could add the three lenghts together, getting 44. 44 in hex would be 0x2C.
Related
I am trying to determine what the correct value would be to input a number into an SQli query. I have been able to deduce (I believe) that the database is using little endian by playing with the hex values. For example:
To modify a value to 255, I am having to use 00000000FF000000.
For values 1-255 this has been fine, it has worked every time.
My question is, for the values 265 and 275, which in hex is converted to 109 and 113, how would I position the numbers within this 16 digit series?
0000000010900000 does not work and returns a value of 36880
Likewise, shifting the 109 to the left instead, returns a value of 9
I am using http://www.scadacore.com/field-applications/programming-calculators/online-hex-converter/ to try and determine the correct value, using the little endian boxes.
The value string seem to be a structure or an array consisting of 16-bit values in little-endian format.
You can see this by examining the values this way:
for example:
00000000FF000000
can be broken down into 16-bit values:
0000 0000 FF00 0000
And when byte-order for 0xff00 is swapped we get 0xff, ie. 255.
For this value:
0000000010900000
we get:
0000 0000 1090 0000
When byte-order is swapped to 0x9010 we get 36880, as in the result.
You don't state why there is a 16-char limit that needs to be fulfilled, but in general - this seem to be part of a structure or an 16-bit array rather than a 64-bit value (which is normally represented by 8 bytes, or 16 chars) but since the value then should have been at either end it is likely not a 64-bit value.
This is normally not something one can guess automatically and would require you know the structure or array definition (talking about binary arrays). One can of course use a pattern to find values matching a range using various positions, width and byte-order, but I cannot see you would benefit in this case compared to finding out the structure/array format (above I guess 4x 16-bit values, but it could just as well have been 1x32-bit, 1x16-bit and 2x8-bit etc.).
My question is, for the values 265 and 275, which in hex is converted to 109 and 113, how would I position the numbers within this 16 digit series?
To fill the binary array you would place them at position 4 (0-base) as 16-bit values in little-endian order.
You can use the DataView for this as it has built-in support for endianess.
Example
Converting value 275 and placing it in the array with correct endianess and position:
var arr = new Uint8Array(8);
var view = new DataView(arr.buffer);
// set value in correct byte-order and position
view.setUint16(4, 275, true); // pos, value, little-endian
// show result (convert to hex-string)
for (var str = "", i = 0; i < arr.length; i++) str += pad(arr[i].toString(16));
console.log(str);
function pad(s) {return s.length < 2 ? "0"+s : s}; // helper: pads to format 0x00
This produces the string:
0000000013010000
Which if we use the same method as earlier becomes:
0000 0000 1301 0000
And then byte-order swap 0x1301 it becomes 0x0113, or 275 as expected.
Blobs are just an array of bytes; the database does not modify their contents or their order in any way.
The endianness (or any other way in which the bytes are to be interpreted) is determined only by the application that writes and reads the blob.
I'm trying a few days to get the type of the CRC with the following hex stream (sniffed with wireshark):
The Hex data i sniffed:
0000001ec001075465737431323308557365726e616d650850617373776f7264d224
This should be the DATA in HEX:
0000001ec001075465737431323308557365726e616d650850617373776f7264
So the last 4 digits are the checksum, in this case d224
I used many code snippets (PHP, java), and some online checksum calcuation sites:
e.g.:
http://www.scadacore.com/field-applications/programming-calculators/online-checksum-calculator/
But I don't get the correct CRC value.
Thanks!
Update 1
Here are more hex streams with CRC included (the last 4 digits):
0000001dc001045465737409557365726e616d65310950617373776f726431cc96
0000001dc001045465737409557365726e616d65320950617373776f72643289d9
0000001dc001045465737409557365726e616d65330950617373776f726433b51c
0000001dc001045465737409557365726e616d65340950617373776f7264340347
0000001dc001045465737409557365726e616d65350950617373776f7264353f82
It appears to be the ARC CRC, polynomial 0x8005, reflected, zero initial value and no final xor, if I discard the initial 0000001d on each message, and take the CRC at the end to be put in the stream in little-endian order.
I am writing a computer program which utilizes input from some equipment which I seldom have availible in my office. In order to develop and test this program I am trying to use an Arduino board to simulate the communication from the actual equipment. To this effect I create datapackets on the Arduino and send them to my computeer over the serial port. The packets are formated as a header and a hexidecimal integer, representing some sensor data.
The header is supposed to contain a checksum (2's complement 256-modulo). I am however not sure how to calculate it. In the datasheet of the equipment (which communication I try to simulate), it is stated that I should first compute the sum all bytes in the packet, and then take the 256-modulo of the sum and perform a 8-bit two's complement on the result.
However, as I am a newbie to bits, bytes and serial communication, I do not understand the following:
1) Lets say that I want to send the value 5500 as two bytes (high byte and low byte). Then the high-byte is '15' and the low-byte is '7c' in hexidecimal encoding, which corresponds to 21 and 124 in decimal values. Do I then add the contributions 21 and 124 to the checksum before taking the 256-modulo, or do I have to do some bit-magic beforehand?
2) How do I perform a two's compliment?
Here is a code which should illustrate how I think. The idea is to send a packet with a header containing a byte which states the length of the packet, a byte which states the type of the packet, and a byte for the checksum. Then a two-byte integer value representing some sensor value is devided into a high-byte and a low-byte, and transmitted low-byte first.
int intVal;
byte Len = 5;
byte checksum;
byte Type = 2;
byte intValHi;
byte intValLo;
void setup(){
Serial.begin(9600);
}
void loop(){
intVal = 5500; //assume that this is a sensor value
intValHi = highByte(intVal);
intValLo = lowByte(intVal);
//how to calculate the checksum? I unsuccessfully tried the following
checksum = 0;
checksum = (Len+checksum+Type+intValHi+intValLo) % 256;
//send header
Serial.write(Len);
Serial.write(checksum);
Serial.write(Type);
//send sensor data
Serial.write(intValLo);
Serial.write(intValHi)
}
Thanks!
The first thing you should understand is that mod 256 is the same thing as looking at the bottom log(256) => 8 bits.
To understand this you have to first realize what the 'mod' operation does and how digits are represented in hardware.
Mod is the remainder after an old-school division (ie only with whole numbers).
eg 5%2 = 1
Digits in hardware are stored in 'bits' which can be interpreted as base 2 mathematics.
Thus if you want to take the mod operation of a power of 2 you don't actually have to do any math.
This is just like if you want to have the remainder of the power of 10, you just take the lower digits.
ie. 157 % 100 = 57.
This can be sped up by using the fact that bytes should overflow by themselves. This means that all you have to do to take %256 of a bunch of numbers is to add them to a single byte and the arduino will take care of the rest.
For twos compliment see this question:
What is “2's Complement”?
I understand that there are a few questions already addressing this. However, my question varies in some sort. Suppose I have to get the LSB of a value (hexadecimal) stored in a register; for e.g;
If register $t0 contains the value 0xA4, I need to obtain and store the value 4
If register $t0 contains the value 0xBF, I need to obtain and store the value F
I understand that the bitwise ANDoperation works for decimal values. Could someone please provide some assistance as to how I go about getting the LSB?
Kind regards
You can easily AND the number from which you want to extract the LSB itself like this:
0xA4 AND 0x0F
is same as (in binary)
10100100b AND 00001111
this basically means that only last four digits will be extracted from binary number and that is the LSB you want.
All the binary operations works on general purpose registers along w/ masks which are merely pure numbers (regardless of their underlying basis repr)
Even though x86 isn't MIPS you should have something like this
and EAX, 0xF
I downloaded Hex Workshop, and I was told to read a .dbc file.
It should contain 28,315 if you read
offset 0x04 and 0x05
I am unsure how to do this? What does 0x04 mean?
0x04 is hex for 4 (the 0x is just a common prefix convention for base 16 representation of numbers - since many people think in decimal), and that would be the fourth byte (since they are saying offset, they probably count the first byte as byte 0, so offset 0x04 would be the 5th byte).
I guess they are saying that the 4th and 5th byte together would be 28315, but did they say if this is little-endian or big-endian?
28315 (decimal) is 0x6E9B in hexadecimal notation, probably in the file in order 0x9B 0x6E if it's little-endian.
Note: Little-endian and big-endian refer to the order bytes are written. Humans typical write decimal notation and hexadecimal in a big-endian way, so:
256 would be written as 0x0100 (digits on the left are the biggest scale)
But that takes two bytes and little-endian systems will write the low byte first: 0x00 0x01. Big-endian systems will write the high-byte first: 0x01 0x00.
Typically Intel systems are little-endian and other systems vary.
Think of a binary file as a linear array of bytes.
0x04 would be the 5th (in a 0 based array) element in the array, and 0x05 would be the 6th.
The two values in 0x04 and 0x05 can be OR'ed together to create the number 28,315.
Since the value you are reading is 16 bit, you need to bitshift one value over and then OR them together, ie if you were manipulating the file in c#, you would use something like this:
int value = (ByteArray[4] >> 8) | ByteArray[5]);
Hopefully this helps explain how hex addresses work.
It's the 4th and the 5th XX code your viewing...
1 2 3 4 5 6
01 AB 11 7B FF 5A
So, the 0x04 and 0x05 is "7B" and "FF".
Assuming what you're saying, in your case 7BFF should be equal to your desired value.
HTH
0x04 in hex is 4 in decimal. 0x10 in hex is 16 in decimal. calc.exe can convert between hex and decimal for you.
Offset 4 means 4 bytes from the start of the file. Offset 0 is the first byte in the file.
Look at bytes 4 and five they should have the values 0x6E 0x9B (or 0x9B 0x6E) depending on your endianess.
Start here. Once you learn how to read hexadecimal values, you'll be in much better shape to actually solve your problem.