28

It is assumed here that Linux ELF32 binaries are being analyzed. Code and data such as strings are stored in separate parts of ELF binaries. To disassemble the parts containing code, use objdump -dj .text <binary_name>. To examine hard-coded string data, use readelf -x .rodata <binary_name> Instructions and Data are located in separate areas ...


8

The data at 00401120 is ASCII-encoded text: 3C 2F 66 6F 6E 74 3E 3C 2F 70 3E 00 52 4E 3A 25 </font></p>.RN:% 73 20 52 54 3A 25 73 20 55 3A 25 73 20 50 3A 25 s RT:%s U:%s P:% 77 6C 65 00 3D 22 62 61 63 6B 67 72 6F 75 6E 64 wle.="background 73 0D 00 00 s... You can tell IDA to decode ...


4

It's different, because it isn't just 0x28FA190 + 0x374, but it's *(0x28FA190 + 0x374). 0x28FA190 is a base address, probably of a structure, and 0x374 is an offset, when you sum these values and dereference the result, you get value of a field that's 0x374 bytes away from the beginning of this structure. This field seems to be a pointer, that's why it's ...


4

It appears to be stored in byte-reversed order from what you gave with a standard 5-6-5 bit encoding and then scaled to a maximum of 255 for each. 0xC0CF (0b1100000011001111) R: 24 (0b11000) * 255/31 = 197 G: 6 (0b000110) * 255/63 = 24 B: 15 (0b01111) * 255/31 = 123 0xF0FF (0b1111000011111111) R: 30 (0b11110) * 255/31 = 247 G: 7 (0b000111) * 255/63 = 28 ...


4

Most assemblers require numeric constants to begin with a digit, this is so they can distinguish between them and labels. You can see it in FASM Fundamental syntax rules: Numbers are distinguished from names by the fact that they either begin with a decimal digit, or with the "$" character followed by any hexadecimal digit. This means that a token ...


3

Actually, from the strings, it looks to me like it's using eCos, not Windows CE: $ binwalk FW_ZERO_DES.bin DECIMAL HEXADECIMAL DESCRIPTION -------------------------------------------------------------------------------- 28494 0x6F4E eCos RTOS string reference: "eCos Thread[%.2ld, %s]" 29723 0x741B eCos RTOS string ...


2

Those hex values could represent anything. Look for online converters that convert hexadecimal to text (consider various formats), dec, etc. and see if the results make any sense. If not, then they could just be 100% obfuscated to not recover any sort of meaningful name. Therefore, just make meaningful names yourself where you see repeated occurrences of ...


2

I would hardly call this an answer, but I can't comment yet.. You need additional data. Have you tried opening the outdoor unit and examining the board that you're communicating with? you might find it has some debug interfaces (serial or something else). It might provide additional information - debug prints when a command is received for example. ...


2

just one sample is never sufficient to answer a checksum query you need a bunch of samples to corelate and find patterns so looking at the linked pdf it seems it is clear enough skip the start and sum the data and extract the least two bytes skip sum mask x,x,x,x | y,y,... 0x000000ff = checksum so the sample you posted would be skip ...


2

Strings suggests this is using the UbiFS file system: $ strings HD2-firmware.bin | grep -i ubifs console=tty0 lpj=2334720 ubi.mtd=lnx root=ubi0:linux rootfstype=ubifs LNX_VIF="../../../src/linuxinfo/ubifs.info" CONFIG_BOSS_SECONDARY_CMDLINE="console=tty0 lpj=2334720 ubi.mtd=lnx root=ubi0:linux rootfstype=ubifs" console=tty0 lpj=2334720 ubi.mtd=lnx root=...


2

There will always be false positives with binwalk, especially for lzma and the likes. What you can do is use the -M option to try and binwalk multiple layers deep and also use -r option to remove files that didn't decompress well.


2

I understand your Arduino serves as a relay in the middle between the controller and the LCD. What you could do (not extremely exciting, but you did not mention whether you made similar experiments already, and I hope I understood your situation well): Modification of single bits. If you visually observe the display and connect a switch at your Arduino ...


1

One word, precision By definition, a normal is a vector with a length of 1.0f which means that each component of the vector will always fall between -1.0f and +1.0f, and UV are texture coordinates expressed in a range between 0 and +1.0f. The number of possible states that you can represent with this range of numbers is huge and even exceeds the total ...


1

Yes, it is possible, but by changing instructions, not data. In assembly there is no way to tell that a particular integer variable is signed or unsigned until you interpret it in the one or another way (and you may change this interpretation many times). Knowing this, to interpret some integer value you use instructions like ja, jb or mul in case of ...


1

You can use this tool to partial deobfuscate that code: http://jsnice.org/ In that case I get this: 'use strict'; (function(data, i) { /** * @param {number} isLE * @return {undefined} */ var write = function(isLE) { for (; --isLE;) { data["push"](data["shift"]()); } }; write(++i); })(_0xf75e, 194); /** * @param {string} ...


Only top voted, non community-wiki answers of a minimum length are eligible