What is the usage of MBR hex dump and what kind of think can be do using it? - operating-system

I take copy bytes dump using my Ubuntu os(MBR sector) following command.
dc3dd if=/dev/sda of=x cnt=1 ssz=512 hash=sha256 mlog=hashes
And I convert it to hexdump using following command.
hexdump x > hex_x
I receive out put like this .
I have some experts hep to analysis this hex_dump. I need to know what are the benefit of getting MBR hex dump and what kind of thing can be do using it ? (Eg: can I tell my system os like information analyzing this ? )
Need to know ,are there any commands or tools to more deep analyzing and convert this hexdump to human readable way ?

Q. what are the benefit of getting MBR hex dump and what kind of thing can be done using it?
A. Microsoft says:
The MBR contains a small amount of executable code called the master boot code, the disk signature, and the partition table for the disk.
The master boot code and disk signatures aren't very useful for someone (investigator). However the partition table gives a lot of information, and it can be used to extract information, in scenarios, where OS is corrupted or not booting and MBR can be used to investigate disk drive and operating system.
Sample Partition Table Record: (taken from an MBR, using HEX editor)
80 20 21 00 07 7E 25 19 00 08 00 00 00 38 06 00
Each hexadecimal value has some specific meaning, for instance:
80 => Partition type, Active
20 21 00 => Partition’s starting sector, Cylinder-Head-Sector (CHS)
07 => File System, NTFS
7E 25 19 => Partition’s ending sector, CHS
00 08 00 00 => Starting sector
00 38 06 00 => Size of the partition, 199 MiB
You can read them in detail in Table 1.2 Partition Table Fields, at official site.
Q. are there any commands or tools to more deep analyzing and convert this hexdump to human readable way?
A. You can use any HEX editor, like Hex Editor Neo or Active Disk Editor. These editors will help you in understanding MBR, but there is no magic tool available to to convert hexdump into human readable format (based on my knowledge).
PS: The question is pretty old, I wasn't available earlier so please accept late answer... :)

Related

trying to read and write to a specific register of ethernet switch using uboot

I am a new to linux/u-boot and just generally reading and writing to specific registers.
I have a KSZ9897 Ethernet switch, and my goal is to use u-boot i2c commands to set bits [15:13] to 001 to put the switch in the proper test mode.
The following screenshot is of the register that I am trying to read/write to:
KSZ9897 datasheet
The slave address of this part is 1011_111 = 0x5F
The address of the 16 bit register I am trying to read/write from is [0xN112-0xN113]
The PHY register is 0x09 (I am not sure how this fits in to the picture, but that may be the reason I am having issues)
using u-boot, I am sending the following command:
#i2c md 0x5F 0xN112.2 0x10
It reads back the following:
0000: 00 98 97 00 00 00 00 00 00 00 00 00 00 00 00 4c ...............L
My suspicion is that this is just reading the first 16 addr values starting at 0x0000. I know this because the 98 and 97 values match up with the default values that should be at address 0x0001 and 0x0002.
Can anyone tell me what I am doing wrong here and how I can access register 0x09? I think i am using the proper u-boot syntax, but clearly something is not right here. any help would be much appreciated.
The i2c command is wrong, because the third parameter must be a hexadecimal number and N is not hexa, the switch datasheet tells that:
Address field “N” specifies the portnumber. Valid values for “N” are 1 to 7 for some registers, 6 to 7 for MAC port specific registers, and 0 to 5 for PHYspecific registers.
You should be writing something like this: i2c md 0x5f 0x1112 1 , the last parameter is the number of bytes you read.

Why is TeraTerm not putting out the same bytes that are in the send call?

Using TeraTerm and a Serial port adapter I ran a Macro with this line on it:
send $55 $0B $00 $00 $00 $BB $42 $AA
The $BB was sent out as two different bytes instead of just one. I forget which ones they were specifically but the result on the O-scope looked like this:
55 0B 00 00 00 C8 E9 42 AA
Does anyone know why this is?
I looked in the Manual and verified that Send8Ctrl is set to off and so is the Debug option.
Did the research, tested and verified that the answer to the question is that TeraTerm is using UTF-8 instead of English under the general settings menu. There are two options present that may be confusing so the two options are 'English' and 'Default'.

How to Reset java card using APDU command

I am new to java card development.so far i have developed java card applet which can encrypt data using RSA algorithm. So basically i followed Application selection and send data.But now i want to reset java card before selecting the java card.Can anyone give me some brief idea how to do that??thanks Sajith.
There is no such thing as a RESET APDU command. Generally speaking, you can reset using a lower level API (which may not be available to you) or by disconnecting the card entirely. Or you can of course remove the power supply entirely by removing the card from the reader.
There may be reader specific commands (also called proprietary commands) that can be accessed through a CLA=FF escape. For instance the ACR122U ACR reader specifies:
The antenna can be switched off in order to save the power.
• Turn off the antenna power: FF 00 00 00 04 D4 32 01 00h
• Turn on the antenna power: FF 00 00 00 04 D4 32 01 01h
Here FF 00 00 00 is the escape header, 04 is the length byte Lc and D4 32 01 00 or D4 32 01 01 is the proprietary command.
This is just a some reader I found using an internet search.
Notes
using getATR() in the Java javax.smartcardio libraries does not reset the card - it just returns the previously received ATR if the card is already powered on;
there is no method to reset the card in the Java Card API either.

Postgres upper function on turkish character does not return expected result

It looks like postgres upper/lower function does not handle select characters in Turkish character set.
select upper('Aaı'), lower('Aaİ') from mytable;
returns :
AAı, aaİ
instead of :
AAI, aai
Note that normal english characters are converted correctly, but not the Turkish I (lower or upper)
Postgres version: 9.2 32 bit
Database encoding (Same result in any of these): UTF-8, WIN1254, C
Client encoding:
UTF-8, WIN1254, C
OS: Windows 7 enterprise edition 64bit
SQL functions lower and upper return the following same bytes for ı and İ on UTF-8 encoded database
\xc4b1
\xc4b0
And the following on WIN1254 (Turkish) encoded database
\xfd
\xdd
I hope my investigation is wrong, and there is something I missed.
Your problem is 100% Windows. (Or rather Microsoft Visual Studio, which PostgreSQL was built with, to be more precise.)
For the record, SQL UPPER ends up calling Windows' LCMapStringW (via towupper via str_toupper) with almost all the right parameters (locale 1055 Turkish for a UTF-8-encoded, Turkish_Turkey database),
but
the Visual Studio Runtime (towupper) does not set the LCMAP_LINGUISTIC_CASING bit in LCMapStringW's dwMapFlags. (I can confirm that setting it does the trick.) This is not considered a bug at Microsoft; it is by design, and will probably not ever be "fixed" (oh the joys of legacy.)
You have three ways out of this:
implement #Sorrow's wrapper solution (or write your own native function replacement (DLL).)
run your PostgreSQL instance on e.g. Ubuntu which exhibits the right behaviour for Turkic locales (#Sorrow confirmed that it works for him); this is probably the simplest and cleanest way out.
drop in a patched 32-bit MSVCR100.DLL in your PostgreSQL bin directory (but although UPPER and LOWER would work, other things such as collation may continue to fail -- again, at the Windows level. YMMV.)
For completeness (and nostalgic fun) ONLY, here is the procedure to patch a Windows system (but remember, unless you'll be managing this PostgreSQL instance from cradle to grave you may cause a lot of grief to your successor(s); whenever deploying a new test or backup system from scratch you or your successor(s) would have to remember to apply the patch again -- and if let's say you one day upgrade to PostgreSQL 10, which say uses MSVCR120.DLL instead of MSVCR100.DLL, then you'll have to try your luck with patching the new DLL, too.) On a test system
use HxD to open C:\WINDOWS\SYSTEM32\MSVCR100.DLL
save the DLL right away with the same name under you PostgreSQL bin directory (do not attempt to copy the file using Explorer or the command line, they might copy the 64bit version)
with the file still open in HxD, go to Search > Replace, pick Datatype: Hexvalues, then
search for...... 4E 14 33 DB 3B CB 0F 84 41 12 00 00 B8 00 01 00 00
replace with... 4E 14 33 DB 3B CB 0F 84 41 12 00 00 B8 00 01 00 01
...then once more...
search for...... FC 51 6A 01 8D 4D 08 51 68 00 02 00 00 50 E8 E2
replace with... FC 51 6A 01 8D 4D 08 51 68 00 02 00 01 50 E8 E2
...and re-save under the PostgreSQL bin directory, then restart PostgreSQL and re-run your query.
if your query still does not work (make sure your database is UTF-8 encoded with Turkish_Turkey for both LC_CTYPE and LC_COLLATE) open postgres.exe in 32-bit Dependency Walker and make sure it indicates it loads MSVCR100.DLL from the PostgreSQL bin directory.
if all functions well copy the patched DLL to the production PostgreSQL bin directory and restart.
BUT REMEMBER, the moment you move the data off the Ubuntu system or off the patched Windows system to an unpatched Windows system you will have the problem again, and you may be unable to import this data back on Ubuntu if the Windows instance introduced duplicates in a citext field or in a UPPER/LOWER-based function index.
It seems to me that your problem is related to Windows. This is how it looks on Ubuntu (Postgres 8.4.14), database encoding UTF-8:
test=# select upper('Aaı'), lower('Aaİ');
upper | lower
-------+-------
AAI | aai
(1 row)
My recommendation would be - if you have to use Windows - to write a stored procedure that will do the conversion for you. Use built-in replace: replace('abcdefabcdef', 'cd', 'XX') returns abXXefabXXef. There might be a more optimal solution, I do not claim that this approach is the correct one.
This is indeed bug in PostgreSQL (still not fixed, even in current git tree).
Proof: https://github.com/postgres/postgres/blob/master/src/port/pgstrcasecmp.c
PostgreSQL developers even mention specifically those Turkish characters there:
SQL99 specifies Unicode-aware case normalization, which we don't yet
have the infrastructure for. Instead we use tolower() to provide a
locale-aware translation.
However, there are some locales where this is not right either (eg, Turkish may do strange things with 'i' and 'I').
Our current compromise is to use tolower() for characters with
the high bit set, and use an ASCII-only downcasing for 7-bit
characters.
pg_upper() implemented in this file is extremely simplistic (as its companion pg_tolower()):
unsigned char
pg_toupper(unsigned char ch)
{
if (ch >= 'a' && ch <= 'z')
ch += 'A' - 'a';
else if (IS_HIGHBIT_SET(ch) && islower(ch))
ch = toupper(ch);
return ch;
}
As you can see, this code does not treat its parameter as Unicode code point, and cannot possibly work 100% correctly, unless currently selected locale happens to be the one that we care for (like Turkish non-unicode locale) and OS-provided non-unicode toupper() is working correctly.
This is really sad, I just hope that this will be solved in upcoming PostgreSQL releases...
The source of the problem explained above. It seems the problem only occurs with the conversion of 'I' to 'ı' and 'i' to 'İ'. As a workaround just replace those characters directly as below before calling lower or upper functions:
SELECT lower(replace('IİĞ', 'I', 'ı')) -> ıiğ
SELECT upper(replace('ıiğ', 'i', 'İ')) -> IİĞ

iPhone Mach-O binaries, string storage, __TEXT/__DATA

I am attempting to read constant (or initilization) strings from an iPhone Mach-O binary file. I understand that the 3 relevant segment.sections are _TEXT._cstring _TEXT._ustring and _DATA._cfstring. Howver, even though I know the string information is stored in these three blocks of data, which I have extracted, I can not make any sense of it, and it all looks like garbage - I do not see any recognizable character strings. Can anyone shed some light on this and give me an idea of what steps need to be take to read the string data?
I have looked at some code (GetAddrOfConstantCFString() from http://llvm.org/svn/llvm-project/cfe/trunk/lib/CodeGen/CodeGenModule.cpp), but again, couldn't quite relate it to what I see in the binaries.
In my case the sizes of the sections in question are:
__TEXT.__cstring (99 K-bytes)
__TEXT.__ustring (<200 bytes)
__DATA.__cfstring (29 K-bytes)
To give you an idea, the first 32 bytes of the __cfstring section, which I though would contain the actual strings looks like this:
Dump _DATA._cfstring
00 00 00 00 c8 07 00 00 74 02 0d 00 15 00 00 00
00 00 00 00 c8 07 00 00 8c 02 0d 00 01 00 00 00
...
Thanks a lot for your help!
Well, I've found the answer.
1) the files are generally encrypted (this can be tested with otool -l prog_file|grep -i crypt ). Not all sections are encrypted but usually the first block including _TEXT._text (prog code) and _TEXT._cstring are. The _DATA._cfstring section was not encrypted in my case.
2) as expected __cfstring consists of 16-byte structures (NSConstantString), where the 3rd word is a pointer to memory where _TEXT._cstring is loaded. The 4th word is the length.
So in real life the trick is to decrypt the file first, and then all is visible and accessible. I still didn't get around doing it properly, but dumped a piece of memory in gdb, which then replaced the relevant section in the file.