how to you know what code format is..?
Is this below code is Binary or bit? and how to convert in any other format or number decimal format
01 00 00 00 04 00 00 00 00 00 00 00 00 00 80 3F 00 00 80 3F 00 00 80 3F 00 00 80 3F 00 00 80 3F 00 00 80 3F 00 00 80 3F 00 00 80 3F 00 00 80 3F 00 00 80 3F 00 00 80 3F
Binary means that you have two possible states (base 2). 1 and 0.
Something that bears that atomic information is usually referred to as a bit.
What you see there are hexadecimal numbers. (base 16)
This notation is often used to display binary data in a more compact form.
The decimal number 255 can be written as 11111111 (binary) or FF (hex)
So each pair is one byte. What they mean depends on where you got those numbers from.
Related
I am using the blob data type to store the blog data in MySql in node.js. It stores the data when I get the data from the database it returns the blob data. now I want to convert the blob data to actual string or text. I am unable to solve this small problem. KIndly tell me the easiest way to do this task.
Supposing you are receiving a Buffer from Database, you just need to use the global Buffer module to convert it to a string:
From database (store it in any type variable):
<Buffer 89 50 4e 47 0d 0a 1a 0a 00 00 00 0d 49 48 44 52 00 00 02 58 00 00 00 e8 08 06 00 00 00 33 33 9a 80 00 00 00 09 70 48 59 73 00 00 16 25 00 00 16 25 01 ... 9679 more bytes>
Convert it to base64 (or whatever format you need):
Buffer.from(storedBlob).toString('base64')
I have to find out how to reproduce the CRC32 algorithm used on a proprietary database file, the file consists of many "chunks" of 128 bytes, each being a record. I know that for each record, bytes 1-4 are the CRC32 Checksum, and the next 35 bytes don't seem to matter, as I can change them easily without the application telling me the CRC Check has failed. Therefore, I am looking to find out what polynomial and other parameters are being used to calculate the latter. Below is an example.
Text version:
00 27 AE 3B 9F 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 41 08 41 41 41 41 41 41 41 41
19 42 42 42 42 42 42 42 42 42 42 42 42 42 42 42 42 42 42 42 42 42 42 42 42
42 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
00 00 00
If we take just the bytes we can't change, breaking the record, we get this:
41 08 41 41 41 41 41 41 41 41 19 42 42 42 42 42 42 42 42 42 42 42 42 42 42
42 42 42 42 42 42 42 42 42 42 42 00 00 00 00 00 00 00 00 00 00 00 00 00 00
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
00 00 00 00 00 00 00 00 00 00 00 00 00
the CRC32 for the above is 27 AE 3B 9F
Real Record Example 1.1, differing only by one byte from the above (CRC is BC D4 84 FB):
41 08 41 41 41 41 41 41 41 41 19 42 42 42 42 42 42 42 42 42 42 42 42 42 42 42
42 42 42 42 42 42 42 42 42 43 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
00 00 00 00 00 00 00 00 00 00
Real Record Example 2 (Output CRC is 3B 6A D1 AF):
41 07 41 41 41 41 41 41 41 00 19 42 42 42 42 42 42 42 42 42 42 42 42 42 42 42
42 42 42 42 42 42 42 42 42 42 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
00 00 00 00 00 00 00 00 00 00
Real Record Example 3 (Output CRC is 0B 54 CC 09):
41 01 31 00 00 00 00 00 00 00 03 41 73 61 00 00 00 00 00 00 00 00 00 00 00 00
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
00 00 00 00 00 00 00 00 00 00
Real Record Example 4 (Output CRC is 12 91 EA 8E):
41 B4 A8 D0 02 46 00 B4 A8 00 03 52 4D 31 03 53 54 50 00 00 00 00 00 00 00 00
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 FF 00 00 00 00 00 00 00 00 00 00
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 25 00 00 00 00 00 00 00
00 00 A3 05 00 00 00 64 00 64 00 64 00 64 00 64 00 64 00 64 00 64 00 64 00 64
00 64 00 64 00 64 00 64 00 64 00 64 00 64 00 64 00 64 00 64 00 00 00 00 00 00
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
Real Record Example 5 (Output CRC is 8A 68 00 3B):
41 B4 A8 D0 02 46 00 B4 A8 01 03 52 4D 31 03 53 54 50 00 00 00 00 00 00 00 00
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 FF 00 00 00 00 00 00 00 00 00 00
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 25 00 00 00 00 00 00 00
00 00 A3 05 00 00 00 64 00 64 00 64 00 64 00 64 00 64 00 64 00 64 00 64 00 64
00 64 00 64 00 64 00 64 00 64 00 64 00 64 00 64 00 64 00 64 00 00 00 00 00 00
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
The two last records differ on only one byte. By using the approach #rcgldr specified, I was able to get a final Xor value of 0x9902539d and I could successfully change data without the application complaining. I ran some code to find these final xor values for every entitity/file on the application and was successful on all of them, but being able to find a single crc parameter set would be a great addition.
EDIT: Added two more example records
EDIT 2: Added one more example that only differs from one byte comparing to the first one
EDIT 3: Added two more examples, with a different size, as their from another type of record within the application. Also deleted part of the question as it became irrelevant
xor'ing 1.0 and 1.1 results in:
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
00 00 00 00 00 00 00 00 00 01 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
00 00 00 00 00 00 00 00 00 00
xor'ing the two crcs results in
9b 7a bf 64
Assuming "little endian" for the stored crc, the calculated crc is
0x64bf7a9b
By xor'ing two records, the initial value and final xor value are canceled out due to the xor, which allows the crc polynomial to be determined based on the data alone, assuming that initial value = 0 and that final xor value = 0. Taking advantage of this, I tried some common crc polynomials and determined that the crc polynomial is
0x104C11DB7 or ignoring the msb: 0x04C11DB7
Using this web site that you linked to in your comment:
http://www.sunshine2k.de/coding/javascript/crc/crc_js.html
The parameters are:
crc32
custom
input: not reflected
result: not reflected
polynomial: 0x04C11DB7
initial value: 0x0
final xor value: 0x0
If the data is always the same size, then either the initial value or the final xor value or a combination of both can be used to adjust the crc so that it matches the actual crc's shown in the examples, but it is simplest to use the final xor to match the examples, since it just requires calculating a crc with one of the examples, assuming initial value = 0 and final xor value = 0, then xor'ing the calculated crc with the actual crc from the example crc to calculate a final xor value for a specific length of data.
So for the data size in the first examples, a final xor value of 0x189B52BC will produce crc's that match the examples. These are the parameters for the crc calculator.
crc32
custom
input: not reflected
result: not reflected
polynomial: 0x04C11DB7
initial value: 0x0
final xor value: 0x189B52BC
These parameters match all of the first examples you posted. Again, note that the crc's are stored "little endian", most significant byte first.
If the data size is variable, then an initial value is needed (and it's possible both an initial value and final xor value are used). Once the polynomial is known, it's possible to do a "reverse" CRC to find the initial value, or a brute force search can be used. I did a brute force search for an initial value using a fast crc calculator (since I don't have a "reverse" CRC program yet), and it appears that it will work for any data size, at least based on the new examples you added. These parameters work with all of the examples above, include the new ones you added:
crc32
custom
input: not reflected
result: not reflected
polynomial: 0x04C11DB7
initial value: 0xc704dd7b
final xor value: 0x0
The initial value of 0xc704dd7b is the crc that is generated with a data pattern of {ff ff ff ff}, with initial value = 0 and final xor value = 0. It's the same as prefixing the data with {ff ff ff ff}.
I want to change many of parts of a unicode string in ollydbg.
Is there any plugin or trick that can be used to replace bulky of unicode string at once?
For example, if 100 unicode 'test' words exist in the string reference then I want to change all 'test' to 'test2'
00459FD0 5C 00 55 00 6C 00 74 00 72 00 61 00 4D 00 61 00 \test\.J.
00459FF0 5C 00 4D 00 69 00 63 00 72 00 6F 00 73 00 6F 00 \Microso
0045A000 66 00 74 00 20 00 53 00 68 00 61 00 72 00 65 00 ft Share
0045A010 64 00 5C 00 54 00 72 00 69 00 45 00 64 00 69 00 d\TriEdi
0045A020 74 00 5C 00 44 00 68 00 74 00 6D 00 6C 00 45 00 t\DhtmlE
0045A030 64 00 2E 00 6F 00 63 00 78 00 00 00 0C 00 00 00 d.ocx...
0045A040 3F 00 6C 00 61 00 6E 00 67 00 3D 00 00 00 00 00 ?lang=..
0045A050 22 00 00 00 5C 00 55 00 6C 00 74 00 72 00 61 00 ".\test.︁ൃᇏ
0045A080 89 40 00 A0 C9 05 42 28 10 9D 0B 2A 87 4B D3 11 䂉ꀀ⡂鴐⨋䮇ᇓ
Until now I was trying to find a trick or plugin but I have been unsuccessful.
How can I accomplish this task?
Thank you.
I struggled few hours to figure this, so here is the way I replaced all my strings with Olly (it was ascii, but no difference).
First we can't do hardcoding, except if the string are at the same size. So go find a free space in your executable, and paste it your string (you have to put a zero byte right after).
Keep your string offset in mind, and in your CPU view, search for all referenced text strings.
Then select the string you want to replace, press enter then space to open the assemble window, then replace your offset with the one of your new string.
Cheerz! :)
Suppose I wanted to write a program to display "hello world", and I wanted to write it in binary. How could I do this?
I have some idea that:
I'd need to determine what chip architecture I'm using
I'd need to find out what kind of binary it uses
I'd need some reference for that flavor of binary
I might need to change a setting in my editor (Vim)
Can anybody walk me through this?
It's bit more complicated, because actually printing "Hello, world!" to stdout is a system call, thus you need to know the correct kernel syscall number. Which of course varies by operating system. Also you need to know the binary format, which also tend to vary, although ELF (Executable and Linkable Format) is universal across few flavors of Unix and Linux.
See Hello, world! in assembler.
This is Linux assembler code:
section .text
global _start ;must be declared for linker (ld)
_start: ;tell linker entry point
mov edx,len ;message length
mov ecx,msg ;message to write
mov ebx,1 ;file descriptor (stdout)
mov eax,4 ;system call number (sys_write)
int 0x80 ;call kernel
mov eax,1 ;system call number (sys_exit)
int 0x80 ;call kernel
section .data
msg db 'Hello, world!',0xa ;our dear string
len equ $ - msg ;length of our dear string
... which on 32-bit Linux, compilation results in binary of 360 bytes, although it's mostly zeros:
00000000 7f 45 4c 46 01 01 01 00 00 00 00 00 00 00 00 00 |.ELF............|
00000010 02 00 03 00 01 00 00 00 80 80 04 08 34 00 00 00 |............4...|
00000020 c8 00 00 00 00 00 00 00 34 00 20 00 02 00 28 00 |........4. ...(.|
00000030 04 00 03 00 01 00 00 00 00 00 00 00 00 80 04 08 |................|
00000040 00 80 04 08 9d 00 00 00 9d 00 00 00 05 00 00 00 |................|
00000050 00 10 00 00 01 00 00 00 a0 00 00 00 a0 90 04 08 |................|
00000060 a0 90 04 08 0e 00 00 00 0e 00 00 00 06 00 00 00 |................|
00000070 00 10 00 00 00 00 00 00 00 00 00 00 00 00 00 00 |................|
00000080 ba 0e 00 00 00 b9 a0 90 04 08 bb 01 00 00 00 b8 |................|
00000090 04 00 00 00 cd 80 b8 01 00 00 00 cd 80 00 00 00 |................|
000000a0 48 65 6c 6c 6f 2c 20 77 6f 72 6c 64 21 0a 00 2e |Hello, world!...|
000000b0 73 68 73 74 72 74 61 62 00 2e 74 65 78 74 00 2e |shstrtab..text..|
000000c0 64 61 74 61 00 00 00 00 00 00 00 00 00 00 00 00 |data............|
000000d0 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 |................|
*
000000f0 0b 00 00 00 01 00 00 00 06 00 00 00 80 80 04 08 |................|
00000100 80 00 00 00 1d 00 00 00 00 00 00 00 00 00 00 00 |................|
00000110 10 00 00 00 00 00 00 00 11 00 00 00 01 00 00 00 |................|
00000120 03 00 00 00 a0 90 04 08 a0 00 00 00 0e 00 00 00 |................|
00000130 00 00 00 00 00 00 00 00 04 00 00 00 00 00 00 00 |................|
00000140 01 00 00 00 03 00 00 00 00 00 00 00 00 00 00 00 |................|
00000150 ae 00 00 00 17 00 00 00 00 00 00 00 00 00 00 00 |................|
00000160 01 00 00 00 00 00 00 00 |........|
Since you want to "compile by hand", this basically means translating assembler mnemonics above to their opcodes, and then wrapping the result in correct binary format (ELF in the example above)
UPDATE: As this answer shows by #adam-rosenfield, the ELF binary for "Hello, world!" can be handcrafted down to 116 bytes. Original answer is now deleted, but still visible to moderators, so here's a copy:
Here's a 32-byte version using Linux system calls:
.globl _start
_start:
movb $4, %al
xor %ebx, %ebx
inc %ebx
movl $hello, %ecx
xor %edx, %edx
movb $11, %dl
int $0x80 ;;; sys_write(1, $hello, 11)
xor %eax, %eax
inc %eax
int $0x80 ;;; sys_exit(something) hello:
.ascii "Hello world"
When compiled into a minimal ELF file, the full executable is 116
bytes:
00000000 7f 45 4c 46 01 01 01 00 00 00 00 00 00 00 00 00 |.ELF............|
00000010 02 00 03 00 01 00 00 00 54 80 04 08 34 00 00 00 |........T...4...|
00000020 00 00 00 00 00 00 00 00 34 00 20 00 01 00 00 00 |........4. .....|
00000030 00 00 00 00 01 00 00 00 00 00 00 00 00 80 04 08 |................|
00000040 00 80 04 08 74 00 00 00 74 00 00 00 05 00 00 00 |....t...t.......|
00000050 00 10 00 00 b0 04 31 db 43 b9 69 80 04 08 31 d2 |......1.C.i...1.|
00000060 b2 0b cd 80 31 c0 40 cd 80 48 65 6c 6c 6f 20 77 |....1.#..Hello w|
00000070 6f 72 6c 64 |orld|
00000074
Normally, you'd use a hex editor for this. Figure out the assembly code, hand-assemble it, use the hex editor to enter the binary values, then save them to a file. Once you have your file, drop into your machine monitor and load the file at an available address, then jump to the first instruction. This was pretty common practice on single-board computers and is still done on microcontrollers today, but it's not something you're going to do on a contemporary OS. If you really want to do this, I'd recommend running a low-level emulator (SIMH will work) or working with a microcontroller (you can pick up a TI MSP430 development kit for less than five bucks).
00000010- 00 11 50 44 00 00 00 00 00 00 00 00 00 11 58 44 [..PD..........XD]
00000011- 00 00 00 00 00 00 00 00 00 11 80 44 00 00 00 00 [...........D....]
00000012- 00 00 00 00 00 11 88 44 00 00 00 00 00 00 00 00 [.......D........]
00000013- 00 11 90 44 00 00 00 00 00 00 00 00 00 11 98 44 [...D...........D]
00000014- 00 00 00 00 00 00 00 00 00 11 C0 44 00 00 00 00 [...........D....]
Need to extract the hex values mentioned below and copy it to a new file -
00 11 50 44 00 00 00 00 00 00 00 00 00 11 58 44 00 00 00 00 00 00 00 00 00 11 80 44 00 00 00 00 00 00 00 00 00 11 88 44 00 00 00 00 00 00 00 00 00 11 90 44 00 00 00 00 00 00 00 00 00 11 98 44 00 00 00 00 00 00 00 00 00 11 C0 44 00 00 00 00
Assuming you've got all your hex data in a variable called $input, you can get a list of hex digits like this:
foreach line [split $input \n] {
foreach c [scan $line %*x-%x%x%x%x%x%x%x%x%x%x%x%x%x%x%x%x] {
if {$c ne ""} {
lappend out [format %x $c]
}
}
}
After that, $out contains a list of hex digits. Use it wisely.
Here is another approach, which makes the following assumptions:
Each line starts with an offset, which we can discard
Also, each line ends with an ASCII presentation, which we also discard
That means, for each line, we only take items 1 .. end-1
That the variable $input holds many lines of hex dump
Without further ado:
set hexList {}
foreach line [split $input "\n"] {
set hexList [concat $hexList [lrange $line 1 16]]
}
puts $hexList; # hexList now contains all the hex digits
My TCL is a bit rusty but a very naive approach would be:
# Parse all hex numbers from your input variable into hexList
set hexList [regexp -all -inline -- {\d{2}(?:\s{1,2})} $input]
# Replace some spaces to get the expected output and store it into hexData
regsub -all -- {\s{3}} [join $hexList] { } hexData
# Write hexData into your file..