问:
Invalid Win32 application/Not a valid Exe
I am currently trying to reverse a program that is EXE format, and I believe written and compiled with Microsoft Visual C++ 2010. The end goal is to map the executables functions, and find a method to bypass the file entirely. I have attempted among other things to open the file with ollydbg.

Olly states that it is probably not a win32 application, upon accepting that, olly is unable to start the program. Log says nothing. Yet the program starts perfectly in a normal context. After some reading it seems clear to me that the author must have exploited the PE header in some way to confuse the debugger.

My question is, surely there must be plugins or debuggers out there that can closer mimic the windows loader, and therefore can run these files, if so can you list an example?

I say this because i can open the file in resource hacker,but again PEid does not.

P.S - Starting the program and then attempting to attach does nothing as the process is not listed.

What I've Read:

RESE - Basically messed with PE to the point where windows wouldn't load the exe

RESE - Specific only to Resource Hacker (which funnily enough works)

RESE - Does not seem to give a way to combat

RESE - Explains of methods for other resource editors, is there a method for Olly

Virus Bulletin - Explains PE manipulation, introduces PeSweep

PE Header (Not complete):


问:
Restore function key
I have a simple function which looks like that:

```<code>keyAlphabet = [-1, 16, 32, 127, 61, -32, -31, 43, 0, 88, 2, 5, 7, 112, 64, 69, 96]
key = ??? # only keyAlphabet values
p = 0x1337
for i in key:
...p*=i
...p+=0x31337
</code>```

Finally p should be 0xfd0970e7.

I've tried to subtract 0x31337 from the final result and search dividers of that value from the keyAlphabet (I've done that operation 8 times and after that multiple dividers came out, 0x12ef1e can be divided with 2,7 and 61), but because of negative values (specially -1) I'm not sure where should I change the sign. As a result I'm not able to find the key which will proceed values from 0x1337 into 0xfd0970e7.

ContentLicense: CC BY-SA 3.0

Title: Restore function key


问:
How do I access the TEB in PIN?
In PIN's documentation it says this about PIN_SafeCopy:

PIN_SafeCopy is used to copy the specified number of bytes from a
  source memory region to a destination memory region. This function
  guarantees safe return to the caller even if the source or destination
  regions are inaccessible (entirely or partially). Use of this function
  also guarantees that the tool reads or writes the values used by the
  application. For example, on Windows, Pin replaces certain TEB fields
  when running a tool's analysis code. If the tool accessed these fields
  directly, it would see the modified values rather than the original
  ones. Using PIN_SafeCopy() allows the tool to read or write the
  application's values for these fields.

I'm trying to get the stack base of the current thread. Normally I would get it like this (if going directly through FS): mov eax, FS:[0x04]. Since I'm getting the old stack, and not the "new" one maintained by PIN (if I compare the REG_ESP from PIN with the current ESP they show different stacks) I tried to first get the linear address of the TEB with mov eax, FS:[0x18] and then use PIN_SafeCopy to read from this address + 0x04. However I only get 0x00000000. Any idea how I can do this? Also I suppose this makes it risky to use the Win API if it reads from such stale sources of data?

Title: How do I access the TEB in PIN?


问:
Overwatch Sombra ARG community asking for Cryto/Steg help
We are looking for some crypto / security expertise in solving some difficult puzzles in a ARG campaign for a Blizzard game called Overwatch. The challenges introduced and solved by the community range from cryptographic / stenographic challenges but are well documented on the wiki page: http://wiki.gamedetectives.net/index.php?title=Sombra_ARG. At the current stage of this ARG several clues and riddles have been solved and at this current stage we are have a website advertising a slow transmission: http://amomentincrime.com/
What are asking for your help in solving the two unsolved challenges which can be found on this on the wiki page linked previously, here are the titles for the two challenges:
• Welcome to the Summer Games Video • Image of Reaper</p>


Title: Radio Signal 433.92MHz ASK OOK modulation, encoding?

Body:
Considering a key fob for RKE (remote keyless entry, automotive) its signal has been captured:
It sends at 433,92MHz simple on/off.

Following I regard the deltas (time differences between on-off or off-on). The greatest common divisor of these deltas is 500µs.

The signal is the following (*500µs each, starting LOW):

```<code>50,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,10,
1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,2,1,1,1,1,1,2,
1,1,1,1,1,1,1,1,1,2,1,2,1,1,1,3,1,1,1,1,1,3,
1,2,1,1,1,1,1,2,1,3,1,1,1,1,1,2,1,2,1,3,1,3,
1,2,1,2,1,2,1,1,1,1,1,2,1,3,1,1,1
</code>```

other samples:

```<code>52 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 11
1 1 1 1 1 1 1 1 1 2 1 2 1 1 1 1 1 2 1 2 1 1
1 2 1 2 1 1 1 1 1 2 1 1 1 2 1 3 1 2 1 2 1 1
1 1 1 2 1 1 1 1 1 1 1 2 1 3 1 1 1 1 1 2 1 1
1 2 1 3 1 2 1 1 1 1 1 2 1 1 1 1 1 1 1

52 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 11
1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 2 1 1 1 1
1 1 1 2 1 1 1 2 1 1 1 2 1 1 1 3 1 1 1 1 1 1
1 1 1 1 1 3 1 1 1 2 1 2 1 1 1 1 1 1 1 1 1 3
1 3 1 3 1 1 1 1 1 2 1 1 1 2 1 2 1 2 1 1 1

52 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 11
1 1 1 1 1 1 1 1 1 3 1 3 1 3 1 2 1 2 1 1 1 3
1 1 1 1 1 2 1 2 1 1 1 1 1 3 1 2 1 2 1 2 1 1
1 2 1 2 1 2 1 2 1 1 1 2 1 1 1 1 1 1 1 1 1 3
1 2 1 1 1 1 1 1 1 1 1 2 1 1 1

52 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 11
1 1 1 1 1 1 1 1 1 2 1 2 1 1 1 1 1 1 1 3 1 1
1 1 1 1 1 3 1 1 1 3 1 3 1 1 1 3 1 1 1 1 1 2
1 1 1 1 1 1 1 1 1 2 1 3 1 1 1 1 1 2 1 1 1 1
1 1 1 1 1 2 1 2 1 1 1 1 1 2 1 2 1 2 1
</code>```

(50 might be 50~52, 10 might be 11, however this is not important), the receiver is sensitive enough to seperate 500,1000,1500µs -- these are the important datas.

It does NOT seem to be Manchester because there is only 1 and 2 times the "main delta", not 3*500.
Some sort of PWM? So what is the main width and duty cycle?

I ask for the name of this encoding. 50 and 10 (x500µs) seems special, interesting is the part beginning after the 10*500µs=5000µs.

Update
I did a simple replay attack: Captured a signal like the samples above (enough distance to car, so that it doesn't hear it), then replayed the signal with my 433MHz Transmitter and car opened successfully! That proves data is accurate enough and things are working properly. However now comes the hard part...
Addition: I spotted two things: The duration of every signal is the same, if you want to further analyze it, write it like this (just example, no captured signal):

```<code>1 1 1 2   1 3     1
1 1 1 1 1 1 1 1 1 1
</code>```

In addition: There is always this prefix

```<code>50 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 11 1 1 1 1 1 1 1 1 1
</code>```

Then it is maybe helpful to spot that between two non-1 (2 or 3), there is an odd amount of 1 always. Conclusion: The longer times (2 or 3) are always LOW because first 50*500µs is LOW, short pulses (1*500µs) can be both hi/lo.

I guess no one knows the encryption, but someone knows the encoding?
Some sort of "line code" ?

Update2

Concerning request by @JimmyB I am adding binary representation, whereby a single 0 or 1 represents a 500µs pulse with the corresponding amplitude (0 or 1).

The prefix becomes this:

```<code>000000000000000000000000000000000000000000000000000101010101010101010100000000000101010101
</code>```

Many samples following (sample hereby refers to the data after prefix, so the complete data is simply prefix+data), one sample per line:

```<code>00100101010010010100100101010010100100010010010101001010101001000101010010100100010010101001010101
01010101001010101001010010100101000101010101010001010010010101010100010001000101010010100100100101
00010001000100100101000101010010010101000100100100101001001001001010010101010100010010101010100101
00100101010100010101010001010001000101000101010010101010100100010101001010101010010010101001001001
01010100101010010101010100100101000101010001001010100100010101001001000100010010010010101001000101
01001001010100010001001010010101000101010001010101001001000101000101010100100101010010100101001001
00010101001010100100101001010101000100101010010101000100100101001001010101010010010010100100101001
01000101001010100100101010101010100100101001001010100100010101010001000100100101000100100101001001
01000100101001010101001010010001010101001001010010010100101010010101001001010100100100100100100101
01010010100101010010010100010101001001001001000101001010100101010001001001000100010010101010100101
00100101001010100101000101001001010010100101000100010010100101000100101010010001000100100100100101
01010001010101010100010100101001010001001001001001010100100101001001000100101001010010101010010001
00010100100100101010010100101010101010101010100101001010010010100100100101000100100100101001010101
</code>```

Using this representation, it is clearly visible that all samples have same duration (might or might not be important for further analysis).
Now looking for patterns? This is all I can provide, I guess. Due to the fact that this is in Germany, something like FCC-ID doesn't exist, so there would be chance of getting more information even though the interesting parts normally are non-public...


问:
Reverse Engineering SCE .pkg Files
To elaborate, I need help decompressing SCE (Sony Computer Entertainment) .pkg files. I've found several common patterns between multiple versions of the same file (released over the span of two years by Sony) using 010 Editor, but don't quite know what I'm looking at.

Here are the matches between two versions of 'package_data02.pkg', released two days apart:

The files use little endian and these are using ANSI character sets (I've looked at them using UTF-8 and Unicode as well)

I've discerned that the matches are part of the file structure, as their starting address and depth are shared across all ~300 .pkg files that have been released over the past two years.

My question is this: can I use the information I've gathered so far to find a way to decompress the data in the .pkg? (If it helps, I'm hoping to find either an executable or .c source files)

About the originally posted question:

 I originally was asking for a way to use the hex dumps to exploit my way through AES encryption, and later found out that not only were the .pkgs only compressed, but I also had access to the encryption keys. Oops...

Title: Reverse Engineering SCE .pkg Files


问:
Reverse Engineering a 16-bit CRC algortihm
I have a set of data bytes and their CRC values available to me. I want to know the CRC algorithm used by it.

CRC is 16 bit long.

firstly I tried to find out using CRC RevEng but that is showing "no model found message".

Then I followed CRC Reverse Engineeing paper written by Greg Ewing.

Then I found that my data set is following the superposition principle
so I came to the conclusion that it is using some standard algorithm to calculate CRC.

According to Greg's paper:

two CRC values obtained from two 1-bit messages, where the 1 bits are in adjacent positions, will have thier resulting CRCs differ by just one shift-xor cycle. To be precise, if C1 corresponds to the message with a 1 in position i, and C2 corresponds to the message with a 1 in position i+1, then C1 is derived from applying one shift-xor cycle to C2. (If this seems backwards, it's because the further the 1 bit is from the end of the message, the more shift-xor cycles get applied to the CRC.)

There are two possibilities. If the leading bit of C2 (the one about to be shifted out) is 0, then C1 will be equal to C2 shifted by one place. If it is 1, then C2 will be equal to C1 shifted one place and xored with the polynomial."

In my case polynomial is not coming same every time.

I have printed CRC values for different messages, their LSB and CRC value after right shift operation and polynomial value to be XORed in order to drive C1 from C2

I have observed that I can get C1 from C2 by three polynomial values which are shown in above image 0x9008, 0x8000, 0x1008

I don't know why it is coming different.
I am stuck at this point

I'm hoping that I can get more hints here on Reverse Engineering Stack Exchange.

Roy


问:
Do any known deobfuscateors work on Agile.net 6.4?
As a company we are going to start obfuscating our released binaries, so far the best front runner we have found has been Agile.net 6.4.

I took one of our binaries we obfuscated with the trial version of 6.4 and was not able to re-fill the method bodies using the latest development snapshot (from 9/8/2016) of de4dot. It appears that the highest version it supports is Agile.net 6.3.

Are there any known deobfuscators in the wild that can deobfuscate Agile.net 6.4? Knowing that there are no current deobfucators would put it in the definite lead of going from trial to purchasing a full licence.


问:
Reading SCSI Command Description Block in software
I have made a hardware control interface for my vintage Yamaha CBX-D5 audio recording processor. using MIDI SysEx commands.I managed to find out most of it's inner workings. I programmed SysEx in Arduino to send over the MIDI bus. It works great and now is a stand-alone unit with effects.
You can find a video on youtube if you look for adriaanhendrik and then CBXD5

Now I also own a CBX-D3, which is a basic 4ch audio processor without effect section.
It uses a startup sequence of SCSI commands sent from the host computer, so that RAM is filled with the right code to make it work just like it's bigger brother (CBX-D5). That way I can fill this code in a Chip so it can be used in stand-alone mode
I would like to read from it's SCSI bus in a software solution. I mean there are expensive hardware solutions out there, but these are out of reach for me.. so there must be a way to intercept the startup Command structure being sent over the SCSI bus so I can program it in a ATMEGA328P chip or something.

Anyone out there that knows how to achieve that one? I do have Logic Audio Platinium that sends those SCSI commands, but don't know how to read and interpret SCSI Command Description Blocks. Maybe there is a way to intercept it on the MacBook Bronze that runs it..


问:
Allwinner Camera Reversing: Compiling V4L
I've reverse engineered quite a bit of action cameras based on Allwinner's poorly documented chipset.

It runs firmware closely related to H3, in fact I can compile a kernel that boots with no video from this source: https://github.com/friendlyarm/h3_lichee (using crane-sdv config)

After getting ext2 working I would like to compile v4l utils for this system. This way I can record video with MY parameters using the adb command line.

So my question is how can I do this? I don't have the tiny android source code although it appears based on 4.2.2 sans java. The rootfs is only 20MB but it has the full v4l2 system.

I tried cross compiling with linaro against the /system/lib folder of rootfs but I can't run v4l-ctl, it says file not found.

more info on the fw is here:https://dashcamtalk.com/forum/threads/hacking-q3h-allwinner-v3-camdroid.20507/

What do I try next?

Compiled stuff wasn't running because I had to use the android ndk so it can use the correct linker.

you can proceed to kick the question back out on your technicality boys, thanks for the non-help


问:
Understanding IE11's Ineterprocess Communication via COM
I'm quite new to COM object reversing (Windows Platform). I'm trying to reverse Internet Explorer on Windows 8.1, where child IE process communicates with Parent IE process via com (Due to Protected Mode).

This is an ASM snippet of a virtual function from ieframe.dll ( Part of class CShellUIHelper) which responsible for a COM operation (I've MS public symbol.)

```<code>CShellUIHelper::XX_XX{

..
..
    mov     eax, [ebp+var_2BC]
    lea     edx, [ebp+Filename]
    mov     edi, esp
    push    edx
    push    [ebp+var_2AC]
    mov     esi, [eax]
    push    ecx             ; _DWORD
    push    eax             ; _DWORD
    mov     esi, [esi+25Ch]
    mov     ecx, esi        ; _DWORD
    call    ds:___guard_check_icall_fptr
    call    esi             ; call {combase!ObjectStublessClient30+0x5c0

}
</code>```

Here its calling a COM interface method at last line using call esi instruction which is actually call [esi+025Ch]. Runtime i've found its actually calling combase!ObjectStublessClient30(x,x)

Here I want to find the interface method name its calling using combase!ObjectStublessClient30().

To find the method name I'm follwing this RE.SE Answer, which looks pretty similar.

But the problem is, in this answer the interface name was known which is IShellWindows, but in my case the I dont know the interface name.

I'm stuck at this point. So my questions is what path I should follow to find out the interface name and method name.?


问:
How to use Hopper to debug wine apps
I'm running Linux Mint , and I try to use the linux Hopper to debug a windows exe .
Does anyone knows a way to debug in Hopper the applications that runs uder wine ?

For example like : winedbg --gdb /home/v/Documents/putty.exe

Title: How to use Hopper to debug wine apps


问:
Record-replay tools for Windows?
Are there any user-mode record-replay tools for Windows that can capture native execution of a program so that it can be replayed deterministically later? Instructions, memory accesses, syscalls and so on. I tried PinPlay but the overhead was too much.</p>

Title: Record-replay tools for Windows?


问:
All data in IDA Pro turns into zeros when using QEMU
I'm trying to emulate a snippet of ARM assembly I have in IDA pro using QEMU. However I do not understand the output of the program.

When I start debugging the firmware, windows pop up for QEMU.
However all the data in IDA turns into zeros, as can be seen in the picture below.

Why is this happening?

Is this normal behavior of the program?

Other information:

Windows 8.1

IDA 6.8

QEMU 2.7.0 (32 bit) from http://qemu.weilnetz.de/

the binary I am trying to emulate is for a device with:

armv7-m architecture

the gdb debug configuration command line is:

```<code>"C:\Program Files (x86)\qemu/qemu-system-arm" -S -gdb tcp::%p,ipv4 -kernel "%e" -M versatilepb -cpu cortex-a8
</code>```

The initial SP is 0x20000000
and the memory map looks like this


问:
open a non-standard compression .tar.lzma file extracted from firmware download
We are trying to examine a firmware download for a product we have running on our local network.  Using the command

```<code>binwalk -Me filename
</code>```

we generated a folder that contains the following content:

```<code>184A46C.cramfs
276466C.cramfs
6C.cramfs
C2426C.cramfs
cramfs-root/
cramfs-root-0/
cramfs-root-1/
cramfs-root-2/
</code>```

Binwalk appears to have opened the CramFS just fine.  So navigating into cramfs-root and running the file command, we see the following:

```<code>app.tar.lzma:    data
copy_logo:       data
cramfs.img:      empty
dvrCmd.tar.gz:   data
hicore.tar.lzma: data
hisi.tar.lzma:   data
logo.tar.lzma:   data
misc.tar.lzma:   data
new_10.bin:      data
player.bin:      PE32 executable (GUI) Intel 80386, for MS Windows, UPX compressed
start.sh:        data
uImage:          u-boot legacy uImage, Linux-3.0.8, Linux/ARM, OS Kernel     Image (Not compressed), 2854980 bytes, Tue Apr 14 10:16:02 2015, Load Address: 0x80008000, Entry Point: 0x80008000, Header CRC: 0x6C502F38, Data     CRC: 0xE9307D6E
version:         ASCII text
webs.tar.lzma:   data
</code>```

Other than the uImage file, which apparently contains a linux kernel, most of the files here are apparently .tar.lzma files.  Attempting to open one of them as a normal .tar.lzma is not working for us.

```<code>tar --lzma -xvf logo.tar.lzma
xz: (stdin): File format not recognized
tar: Child returned status 1
tar: Error is not recoverable: exiting now
</code>```

Trying something else:

```<code>unlzma logo.tar.lzma
unlzma: Decoder error
</code>```

lzmainfo seems to think it is valid, however, but it is calculating it as a laughably large, multi-petabyte file.  I am quite sure it is not.

```<code>lzmainfo logo.tar.lzma

logo.tar.lzma
Uncompressed size:             8351652399384 MB (8757342266336797407 bytes)
Dictionary size:               525 MB (2^29 bytes)
Literal context bits (lc):     0
Literal pos bits (lp):         2
Number of pos bits (pb):       4
</code>```

I've uploaded the file here if you care to look at it.


问:
crash using ida 6.8 debugging on android 5.0
I need to debug .so of my.apk, I'm working on a phone with android 5.0, using ida 6.8's android_server. It seems ok for attaching ida to the process, but when clicking something on the apk there is message box that shows an exception(see the image), and breaks at this line:

```<code>system@framework@boot.oat:7314709E DCB    8
</code>```

And the 'call stack' window is empty.

The problem happens with android 5.x + ida 6.8,  or android 7.0 + ida 6.8
but it works fine on android 4.x + ida 6.5

But I tried another apk, there is no such problem.
Any idea?

Update 1
According to comments from @ws, it's something wrong with segment type: ARM(0) and THUMB(1), here's what I tried:

Press Alt+G at that line, a window popups and shows the segment register value is 1, I modified it to 0, run.

Then it breaks at another place with same exception. I did that again.

Then it goes to boot.oat, but this time is different. Even after modified it to 0(ARM), it breaks at this line about 6~7 times

And finally it breaks at some random code with same exception, such as memset in the image below. Then program crashes if continue run.


问:
How can I find loading adress of eCos image
Hey guys Im trying to find loading address (entry point of my program) for this binary, which is part off this firmware. Im trying to load it inside of IDA, how can I correctly load it, how to find entry point address?

Here's binwalk's output:

```$ binwalk 7101C

DECIMAL       HEXADECIMAL     DESCRIPTION
--------------------------------------------------------------------------------
0             0x0             eCos kernel exception handler, architecture: MIPSEL, exception vector table base address: 0x80558540
640           0x280           eCos kernel exception handler, architecture: MIPSEL, exception vector table base address: 0x80558540
4307602       0x41BA92        Unix path: /../../HB/app/tv/appTvVideo_dvb.c
4389070       0x42F8CE        Unix path: /../../HB/app/zapper/appZapper.c
4391820       0x43038C        CRC32 polynomial table, little endian
4392970       0x43080A        Unix path: /../../HB/app/main/appMain.c
4393342       0x43097E        Unix path: /../../HB/app/main/appWDT.c
4393574       0x430A66        Unix path: /../../HB/app/menu/MApp_Menu.c
4393758       0x430B1E        Unix path: /../../HB/app/menu/MApp_MenuChannel.c
4397102       0x43182E        Unix path: /../../HB/app/monitor/appMonitor.c
4398262       0x431CB6        Unix path: /../../HB/platform/api/font/apiVectorFont.c
4398414       0x431D4E        Unix path: /../../HB/platform/api/zui/MApp_ZUI_APIcontrols.c
4398666       0x431E4A        Unix path: /../../HB/platform/api/zui/MApp_ZUI_APIgdi.c
4398882       0x431F22        Unix path: /../../HB/platform/api/zui/MApp_ZUI_APIwindow.c
4399178       0x43204A        Unix path: /../../HB/platform/api/zui/MApp_ZUI_Main.c
4399302       0x4320C6        Unix path: /../../HB/platform/api/zui/apiMvf_base.c
4399654       0x432226        Unix path: /../../HB/platform/api/zui/apiMvf_grays.c
4401186       0x432822        Unix path: /../../HB/platform/api/database/MApp_SaveData.c
4401744       0x432A50        CRC32 polynomial table, little endian
4402906       0x432EDA        Unix path: /../../HB/platform/api/database/apiDTVDataManager.c
4404518       0x433526        Unix path: /../../HB/platform/api/chscan/apiChScan.c
4405394       0x433892        Unix path: /../../HB/platform/api/EPG_Swap_DB/apiEPG_DB.c
4408198       0x434386        Unix path: /../../HB/platform/api/EPG_Swap_DB/apiEPG_EIT_Swap.c
4410158       0x434B2E        Unix path: /../../HB/platform/driver/pq/drvPQ.c
4413646       0x4358CE        Unix path: /../../HB/platform/driver/pq/hal/kriti_mstar/include/QualityMap_BW.c
4414022       0x435A46        Unix path: /../../HB/platform/driver/pq/hal/kriti_mstar/mhal_pq.c
4415066       0x435E5A        Unix path: /../../HB/app/media/appMM_Browser.c
4416158       0x43629E        Unix path: /../../HB/app/media/appPVR_playback.c
4416918       0x436596        Unix path: /../../HB/app/media/MMfilesystem/apiFSUtil.c
4417234       0x4366D2        Unix path: /../../HB/app/media/portinglayer/mm/src/porting_audio.c
4425946       0x4388DA        Unix path: /../../HB/app/media/vdplayerV2/appMM_playback.c
4426570       0x438B4A        Unix path: /../../HB/platform/zui/MApp_ZUI_ACTglobal.c
4427538       0x438F12        Unix path: /../../HB/platform/zui/MApp_ZUI_GDISetup.c
4427974       0x4390C6        Unix path: /../../HB/platform/zui/widgets/MApp_ZUI_CTLsolidprogressbar.c
4428226       0x4391C2        Unix path: /../../HB/platform/zui/pagedoc/MApp_PvrZapper.c
4428446       0x43929E        Unix path: /../../HB/platform/zui/pagedoc/MApp_Pvrv3.c
4438850       0x43BB42        Unix path: /../../HB/platform/zui/pageview/MApp_ZUI_ACTAudioLanguage.c
4439082       0x43BC2A        Unix path: /../../HB/platform/zui/pageview/MApp_ZUI_ACTChannelInfo.c
4440318       0x43C0FE        Unix path: /../../HB/platform/zui/pageview/MApp_ZUI_ACTMediaMoviePlay.c
4441950       0x43C75E        Unix path: /../../HB/platform/zui/pageview/MApp_ZUI_ACTMediaPlay.c
4442178       0x43C842        Unix path: /../../HB/platform/zui/pageview/MApp_ZUI_ACTMediaSimpleStart_PVR.c
4443290       0x43CC9A        Unix path: /../../HB/platform/zui/pageview/MApp_ZUI_ACTMenuPvrDevice.c
4444006       0x43CF66        Unix path: /../../HB/platform/zui/pageview/MApp_ZUI_ACTPvrSubtitleLanguage.c
4444586       0x43D1AA        Unix path: /../../HB/platform/zui/pageview/MApp_ZUI_ACTSubtitle.c
4445218       0x43D422        Unix path: /../../HB/platform/zui/pageview/MApp_ZUI_ACTbookmanage.c
4445966       0x43D70E        Unix path: /../../HB/platform/zui/pageview/MApp_ZUI_ACTprogedit.c
4447410       0x43DCB2        Unix path: /../../HB/platform/zui/pageview/MApp_ZUI_ACTtvbanner.c
4448530       0x43E112        Unix path: /../../HB/platform/zui/pageview/MApp_ZUI_ACTtvfavoritelist.c
4448774       0x43E206        Unix path: /../../HB/platform/zui/pageview/MApp_ZUI_Utility.c
5003844       0x4C5A44        Unix path: /ecos-y/PERFORCE/THEALE/Uranus/eCospro/Kappa/LIB_eCos_fileio_posix_fat_ntfs_jffs2_v3_c++_kappa_34kf_install/include/cyg/kernel/s
5003845       0x4C5A45        eCos RTOS string reference: "ecos-y/PERFORCE/THEALE/Uranus/eCospro/Kappa/LIB_eCos_fileio_posix_fat_ntfs_jffs2_v3_c++_kappa_34kf_install/include/cyg/kernel/sm"
5003875       0x4C5A63        eCos RTOS string reference: "eCospro/Kappa/LIB_eCos_fileio_posix_fat_ntfs_jffs2_v3_c++_kappa_34kf_install/include/cyg/kernel/smp.hxx"
5003893       0x4C5A75        eCos RTOS string reference: "eCos_fileio_posix_fat_ntfs_jffs2_v3_c++_kappa_34kf_install/include/cyg/kernel/smp.hxx"
5003981       0x4C5ACD        eCos RTOS string reference: "ecos-y/PERFORCE/THEALE/Uranus/eCospro/Kappa/LIB_eCos_fileio_posix_fat_ntfs_jffs2_v3_c++_kappa_34kf_install/include/cyg/memalloc/"
5004011       0x4C5AEB        eCos RTOS string reference: "eCospro/Kappa/LIB_eCos_fileio_posix_fat_ntfs_jffs2_v3_c++_kappa_34kf_install/include/cyg/memalloc/mempolt2.inl"
5004029       0x4C5AFD        eCos RTOS string reference: "eCos_fileio_posix_fat_ntfs_jffs2_v3_c++_kappa_34kf_install/include/cyg/memalloc/mempolt2.inl"
5004125       0x4C5B5D        eCos RTOS string reference: "ecos-y/PERFORCE/THEALE/Uranus/eCospro/packages/services/memalloc/common/v2_0_60/src/malloc.cxx"
5004155       0x4C5B7B        eCos RTOS string reference: "eCospro/packages/services/memalloc/common/v2_0_60/src/malloc.cxx"
5004221       0x4C5BBD        eCos RTOS string reference: "ecos-y/PERFORCE/THEALE/Uranus/eCospro/packages/io/fileio/v2_0_60/src/misc.cxx"
5004251       0x4C5BDB        eCos RTOS string reference: "eCospro/packages/io/fileio/v2_0_60/src/misc.cxx"
5004333       0x4C5C2D        eCos RTOS string reference: "ecos-y/PERFORCE/THEALE/Uranus/eCospro/packages/fs/fat/v2_0_60/src/fatfs_supp.c"
5004363       0x4C5C4B        eCos RTOS string reference: "eCospro/packages/fs/fat/v2_0_60/src/fatfs_supp.c"
5005580       0x4C610C        Unix path: /ecos-y/PERFORCE/THEALE/Uranus/eCospro/packages/fs/fat/v2_0_60/src/fatfs_ncache.c
5005581       0x4C610D        eCos RTOS string reference: "ecos-y/PERFORCE/THEALE/Uranus/eCospro/packages/fs/fat/v2_0_60/src/fatfs_ncache.c"
5005611       0x4C612B        eCos RTOS string reference: "eCospro/packages/fs/fat/v2_0_60/src/fatfs_ncache.c"
5005940       0x4C6274        Unix path: /ecos-y/PERFORCE/THEALE/Uranus/eCospro/packages/fs/fat/v2_0_60/src/fatfs_blib.c
5005941       0x4C6275        eCos RTOS string reference: "ecos-y/PERFORCE/THEALE/Uranus/eCospro/packages/fs/fat/v2_0_60/src/fatfs_blib.c"
5005971       0x4C6293        eCos RTOS string reference: "eCospro/packages/fs/fat/v2_0_60/src/fatfs_blib.c"
5006676       0x4C6554        Unix path: /ecos-y/PERFORCE/THEALE/Uranus/eCospro/packages/io/disk/v2_0_60/src/disk.c
5006677       0x4C6555        eCos RTOS string reference: "ecos-y/PERFORCE/THEALE/Uranus/eCospro/packages/io/disk/v2_0_60/src/disk.c"
5006707       0x4C6573        eCos RTOS string reference: "eCospro/packages/io/disk/v2_0_60/src/disk.c"
5008348       0x4C6BDC        Unix path: /ecos-y/PERFORCE/THEALE/Uranus/eCospro/packages/hal/common/v2_0_60/src/hal_misc.c
5008349       0x4C6BDD        eCos RTOS string reference: "ecos-y/PERFORCE/THEALE/Uranus/eCospro/packages/hal/common/v2_0_60/src/hal_misc.c"
5008379       0x4C6BFB        eCos RTOS string reference: "eCospro/packages/hal/common/v2_0_60/src/hal_misc.c"
5008609       0x4C6CE1        eCos RTOS string reference: "eCos][CPU INFO] : CPU Clock = %d : RTC Period = %d"
5009060       0x4C6EA4        Unix path: /ecos-y/PERFORCE/THEALE/Uranus/eCospro/packages/kernel/v2_0_60/src/common/clock.cxx
5009061       0x4C6EA5        eCos RTOS string reference: "ecos-y/PERFORCE/THEALE/Uranus/eCospro/packages/kernel/v2_0_60/src/common/clock.cxx"
5009091       0x4C6EC3        eCos RTOS string reference: "eCospro/packages/kernel/v2_0_60/src/common/clock.cxx"
5009409       0x4C7001        eCos RTOS string reference: "ecos-y/PERFORCE/THEALE/Uranus/eCospro/packages/kernel/v2_0_60/src/common/kapi.cxx"
5009439       0x4C701F        eCos RTOS string reference: "eCospro/packages/kernel/v2_0_60/src/common/kapi.cxx"
5009493       0x4C7055        eCos RTOS string reference: "ecos-y/PERFORCE/THEALE/Uranus/eCospro/Kappa/LIB_eCos_fileio_posix_fat_ntfs_jffs2_v3_c++_kappa_34kf_install/include/cyg/kernel/th"
5009523       0x4C7073        eCos RTOS string reference: "eCospro/Kappa/LIB_eCos_fileio_posix_fat_ntfs_jffs2_v3_c++_kappa_34kf_install/include/cyg/kernel/thread.inl"
5009541       0x4C7085        eCos RTOS string reference: "eCos_fileio_posix_fat_ntfs_jffs2_v3_c++_kappa_34kf_install/include/cyg/kernel/thread.inl"
5010176       0x4C7300        Unix path: /ecos-y/PERFORCE/THEALE/Uranus/eCospro/packages/kernel/v2_0_60/src/common/thread.cxx
5010177       0x4C7301        eCos RTOS string reference: "ecos-y/PERFORCE/THEALE/Uranus/eCospro/packages/kernel/v2_0_60/src/common/thread.cxx"
5010207       0x4C731F        eCos RTOS string reference: "eCospro/packages/kernel/v2_0_60/src/common/thread.cxx"
5010465       0x4C7421        eCos RTOS string reference: "ecos-y/PERFORCE/THEALE/Uranus/eCospro/packages/kernel/v2_0_60/src/common/except.cxx"
5010495       0x4C743F        eCos RTOS string reference: "eCospro/packages/kernel/v2_0_60/src/common/except.cxx"
5010684       0x4C74FC        Unix path: /ecos-y/PERFORCE/THEALE/Uranus/eCospro/packages/kernel/v2_0_60/src/intr/intr.cxx
5010685       0x4C74FD        eCos RTOS string reference: "ecos-y/PERFORCE/THEALE/Uranus/eCospro/packages/kernel/v2_0_60/src/intr/intr.cxx"
5010715       0x4C751B        eCos RTOS string reference: "eCospro/packages/kernel/v2_0_60/src/intr/intr.cxx"
5011337       0x4C7789        eCos RTOS string reference: "ecos-y/PERFORCE/THEALE/Uranus/eCospro/packages/kernel/v2_0_60/src/sched/mlqueue.cxx"
5011367       0x4C77A7        eCos RTOS string reference: "eCospro/packages/kernel/v2_0_60/src/sched/mlqueue.cxx"
5011925       0x4C79D5        eCos RTOS string reference: "ecos-y/PERFORCE/THEALE/Uranus/eCospro/packages/kernel/v2_0_60/src/sched/sched.cxx"
5011955       0x4C79F3        eCos RTOS string reference: "eCospro/packages/kernel/v2_0_60/src/sched/sched.cxx"
5012620       0x4C7C8C        Unix path: /ecos-y/PERFORCE/THEALE/Uranus/eCospro/packages/kernel/v2_0_60/src/sync/cnt_sem.cxx
5012621       0x4C7C8D        eCos RTOS string reference: "ecos-y/PERFORCE/THEALE/Uranus/eCospro/packages/kernel/v2_0_60/src/sync/cnt_sem.cxx"
5012651       0x4C7CAB        eCos RTOS string reference: "eCospro/packages/kernel/v2_0_60/src/sync/cnt_sem.cxx"
5012833       0x4C7D61        eCos RTOS string reference: "ecos-y/PERFORCE/THEALE/Uranus/eCospro/packages/kernel/v2_0_60/src/sync/flag.cxx"
5012863       0x4C7D7F        eCos RTOS string reference: "eCospro/packages/kernel/v2_0_60/src/sync/flag.cxx"
5013293       0x4C7F2D        eCos RTOS string reference: "ecos-y/PERFORCE/THEALE/Uranus/eCospro/Kappa/LIB_eCos_fileio_posix_fat_ntfs_jffs2_v3_c++_kappa_34kf_install/include/cyg/kernel/mb"
5013323       0x4C7F4B        eCos RTOS string reference: "eCospro/Kappa/LIB_eCos_fileio_posix_fat_ntfs_jffs2_v3_c++_kappa_34kf_install/include/cyg/kernel/mboxt2.inl"
5013341       0x4C7F5D        eCos RTOS string reference: "eCos_fileio_posix_fat_ntfs_jffs2_v3_c++_kappa_34kf_install/include/cyg/kernel/mboxt2.inl"
5014181       0x4C82A5        eCos RTOS string reference: "ecos-y/PERFORCE/THEALE/Uranus/eCospro/packages/kernel/v2_0_60/src/sync/mutex.cxx"
5014211       0x4C82C3        eCos RTOS string reference: "eCospro/packages/kernel/v2_0_60/src/sync/mutex.cxx"
5014897       0x4C8571        eCos RTOS string reference: "ecos-y/PERFORCE/THEALE/Uranus/eCospro/packages/services/memalloc/common/v2_0_60/src/dlmalloc.cxx"
5014927       0x4C858F        eCos RTOS string reference: "eCospro/packages/services/memalloc/common/v2_0_60/src/dlmalloc.cxx"
5015649       0x4C8861        eCos RTOS string reference: "ecos-y/PERFORCE/THEALE/Uranus/eCospro/packages/language/c/libc/setjmp/v2_0_60/src/longjmp.cxx"
5015679       0x4C887F        eCos RTOS string reference: "eCospro/packages/language/c/libc/setjmp/v2_0_60/src/longjmp.cxx"
5015829       0x4C8915        eCos RTOS string reference: "ecos-y/PERFORCE/THEALE/Uranus/eCospro/Kappa/LIB_eCos_fileio_posix_fat_ntfs_jffs2_v3_c++_kappa_34kf_install/include/cyg/libc/stdi"
5015859       0x4C8933        eCos RTOS string reference: "eCospro/Kappa/LIB_eCos_fileio_posix_fat_ntfs_jffs2_v3_c++_kappa_34kf_install/include/cyg/libc/stdio/stream.inl"
5015877       0x4C8945        eCos RTOS string reference: "eCos_fileio_posix_fat_ntfs_jffs2_v3_c++_kappa_34kf_install/include/cyg/libc/stdio/stream.inl"
5016101       0x4C8A25        eCos RTOS string reference: "ecos-y/PERFORCE/THEALE/Uranus/eCospro/packages/language/c/libc/stdio/v2_0_60/src/common/stream.cxx"
5016131       0x4C8A43        eCos RTOS string reference: "eCospro/packages/language/c/libc/stdio/v2_0_60/src/common/stream.cxx"
5016201       0x4C8A89        eCos RTOS string reference: "ecos-y/PERFORCE/THEALE/Uranus/eCospro/Kappa/LIB_eCos_fileio_posix_fat_ntfs_jffs2_v3_c++_kappa_34kf_install/include/cyg/libc/stdi"
5016231       0x4C8AA7        eCos RTOS string reference: "eCospro/Kappa/LIB_eCos_fileio_posix_fat_ntfs_jffs2_v3_c++_kappa_34kf_install/include/cyg/libc/stdio/streambuf.inl"
5016249       0x4C8AB9        eCos RTOS string reference: "eCos_fileio_posix_fat_ntfs_jffs2_v3_c++_kappa_34kf_install/include/cyg/libc/stdio/streambuf.inl"
5017624       0x4C9018        Unix path: /ecos-y/PERFORCE/THEALE/Uranus/eCospro/packages/language/c/libc/string/v2_0_60/src/strtok.cxx
5017625       0x4C9019        eCos RTOS string reference: "ecos-y/PERFORCE/THEALE/Uranus/eCospro/packages/language/c/libc/string/v2_0_60/src/strtok.cxx"
5017655       0x4C9037        eCos RTOS string reference: "eCospro/packages/language/c/libc/string/v2_0_60/src/strtok.cxx"
5018041       0x4C91B9        eCos RTOS string reference: "ecos-y/PERFORCE/THEALE/Uranus/eCospro/packages/io/fileio/v2_0_60/src/fd.cxx"
5018071       0x4C91D7        eCos RTOS string reference: "eCospro/packages/io/fileio/v2_0_60/src/fd.cxx"
5018177       0x4C9241        eCos RTOS string reference: "ecos-y/PERFORCE/THEALE/Uranus/eCospro/packages/io/fileio/v2_0_60/src/file.cxx"
5018207       0x4C925F        eCos RTOS string reference: "eCospro/packages/io/fileio/v2_0_60/src/file.cxx"
5018605       0x4C93ED        eCos RTOS string reference: "ecos-y/PERFORCE/THEALE/Uranus/eCospro/packages/io/fileio/v2_0_60/src/dir.cxx"
5018635       0x4C940B        eCos RTOS string reference: "eCospro/packages/io/fileio/v2_0_60/src/dir.cxx"
5018749       0x4C947D        eCos RTOS string reference: "ecos-y/PERFORCE/THEALE/Uranus/eCospro/packages/io/fileio/v2_0_60/src/select.cxx"
5018779       0x4C949B        eCos RTOS string reference: "eCospro/packages/io/fileio/v2_0_60/src/select.cxx"
5018857       0x4C94E9        eCos RTOS string reference: "ecos-y/PERFORCE/THEALE/Uranus/eCospro/packages/language/c/libc/startup/v2_0_60/src/main.cxx"
5018887       0x4C9507        eCos RTOS string reference: "eCospro/packages/language/c/libc/startup/v2_0_60/src/main.cxx"
5019141       0x4C9605        eCos RTOS string reference: "ecos-y/PERFORCE/THEALE/Uranus/eCospro/Kappa/LIB_eCos_fileio_posix_fat_ntfs_jffs2_v3_c++_kappa_34kf_install/include/cyg/libc/stdi"
5019171       0x4C9623        eCos RTOS string reference: "eCospro/Kappa/LIB_eCos_fileio_posix_fat_ntfs_jffs2_v3_c++_kappa_34kf_install/include/cyg/libc/stdio/stdiofiles.inl"
5019189       0x4C9635        eCos RTOS string reference: "eCos_fileio_posix_fat_ntfs_jffs2_v3_c++_kappa_34kf_install/include/cyg/libc/stdio/stdiofiles.inl"
5020472       0x4C9B38        Unix path: /ecos-y/PERFORCE/THEALE/Uranus/eCospro/packages/language/c/libc/startup/v2_0_60/src/_exit.cxx
5020473       0x4C9B39        eCos RTOS string reference: "ecos-y/PERFORCE/THEALE/Uranus/eCospro/packages/language/c/libc/startup/v2_0_60/src/_exit.cxx"
5020503       0x4C9B57        eCos RTOS string reference: "eCospro/packages/language/c/libc/startup/v2_0_60/src/_exit.cxx"
5020609       0x4C9BC1        eCos RTOS string reference: "ecos-y/PERFORCE/THEALE/Uranus/eCospro/packages/language/c/libc/startup/v2_0_60/src/atexit.cxx"
5020639       0x4C9BDF        eCos RTOS string reference: "eCospro/packages/language/c/libc/startup/v2_0_60/src/atexit.cxx"
5021120       0x4C9DC0        Unix path: /ecos-y/PERFORCE/THEALE/Uranus/eCospro/packages/fs/ntfs/v2_0_60/src/attrib.c
5021121       0x4C9DC1        eCos RTOS string reference: "ecos-y/PERFORCE/THEALE/Uranus/eCospro/packages/fs/ntfs/v2_0_60/src/attrib.c"
5021151       0x4C9DDF        eCos RTOS string reference: "eCospro/packages/fs/ntfs/v2_0_60/src/attrib.c"
5021876       0x4CA0B4        Unix path: /ecos-y/PERFORCE/THEALE/Uranus/eCospro/packages/fs/ntfs/v2_0_60/src/ntfs_blib.c
5021877       0x4CA0B5        eCos RTOS string reference: "ecos-y/PERFORCE/THEALE/Uranus/eCospro/packages/fs/ntfs/v2_0_60/src/ntfs_blib.c"
5021907       0x4CA0D3        eCos RTOS string reference: "eCospro/packages/fs/ntfs/v2_0_60/src/ntfs_blib.c"
5033632       0x4CCEA0        Unix path: /home/mstar/PERFORCE/THEALE/utopia_release/UTPA-24.0.x_Kriti/project/kriti_ecos/../../mxlib/hal/kriti/audio/halAUDIO.c
5033707       0x4CCEEB        eCos RTOS string reference: "ecos/../../mxlib/hal/kriti/audio/halAUDIO.c"
5038144       0x4CE040        Unix path: /home/stb/PERFORCE/THEALE/utopia_release/UTPA-24.0.x_Kriti/project/kriti_ecos/../../mxlib/hal/kriti/dac/halDAC.c
5038217       0x4CE089        eCos RTOS string reference: "ecos/../../mxlib/hal/kriti/dac/halDAC.c"
5066028       0x4D4D2C        Unix path: /home/mstar/PERFORCE/THEALE/utopia_release/UTPA-24.0.x_Kriti/project/kriti_ecos/../../mxlib/hal/kriti/mvd/halMVD.c
5066103       0x4D4D77        eCos RTOS string reference: "ecos/../../mxlib/hal/kriti/mvd/halMVD.c"
5091476       0x4DB094        eCos RTOS string reference: "eCos Newhost"
5108812       0x4DF44C        Unix path: /home/stb/PERFORCE/THEALE/utopia_release/UTPA-24.0.x_Kriti/project/kriti_ecos/../../mxlib/hal/kriti/ve/mhal_tvencoder.c
5108885       0x4DF495        eCos RTOS string reference: "ecos/../../mxlib/hal/kriti/ve/mhal_tvencoder.c"
5109464       0x4DF6D8        Unix path: /home/franke.wu/workspace/THEALE/utopia_release/UTPA-24.0.x_Kriti/project/kriti_ecos/../../mxlib/msos/ecos/MsOS_ecos.c
5109544       0x4DF728        eCos RTOS string reference: "ecos/../../mxlib/msos/ecos/MsOS_ecos.c"
5109566       0x4DF73E        eCos RTOS string reference: "ecos/MsOS_ecos.c"
5109576       0x4DF748        eCos RTOS string reference: "ecos.c"
5110012       0x4DF8FC        Unix path: /home/franke.wu/workspace/THEALE/utopia_release/UTPA-24.0.x_Kriti/project/kriti_ecos/../../mxlib/drv/miu/drvMIU.c
5110092       0x4DF94C        eCos RTOS string reference: "ecos/../../mxlib/drv/miu/drvMIU.c"
5110300       0x4DFA1C        eCos RTOS string reference: "ecos/../../mxlib/drv/sys/drvDMD_VD_MBX.c"
5304106       0x50EF2A        Unix path: /../src/si_v2/apiSI.c
5307730       0x50FD52        Unix path: /../src/dvb_subtitle/apiSubtitle_DC2_Decoder.c
5308386       0x50FFE2        Unix path: /../src/dvb_subtitle/apiSubtitle_Decoder.c
5403172       0x527224        CRC32 polynomial table, little endian
5407268       0x528224        CRC32 polynomial table, big endian
5428390       0x52D4A6        Unix path: /../src/mm/mapp_music.c
5431970       0x52E2A2        Unix path: /../src/espvr/apiEsPVR.cpp
5433930       0x52EA4A        Unix path: /../src/espvr/core/src/api/mapi_pvr_browser.cpp
5434774       0x52ED96        Unix path: /../src/espvr/core/src/api/mapi_pvr.cpp
5438298       0x52FB5A        Unix path: /../src/espvr/core/src/utility/PVR_File_Operand.cpp
5438798       0x52FD4E        Unix path: /../src/espvr/core/src/context/PVR_File_Root.cpp
5439894       0x530196        Unix path: /../src/espvr/core/src/context/PVR_Metadata.cpp
5441758       0x5308DE        Unix path: /../src/espvr/core/src/path/PVR_Path_Download.cpp
5443490       0x530FA2        Unix path: /../src/espvr/core/src/path/PVR_Path_DualDownload.cpp
5445230       0x53166E        Unix path: /../src/espvr/core/src/path/PVR_Path_ESPlayer.cpp
5445914       0x53191A        Unix path: /../src/espvr/core/src/path/PVR_Path_Manager.cpp
5447010       0x531D62        Unix path: /../src/espvr/core/src/path/PVR_Path_TSPlayer.cpp
5448770       0x532442        Unix path: /../src/espvr/core/src/context/PVR_Splitted_File.cpp
5449582       0x53276E        Unix path: /../src/espvr/core/src/context/PVR_Sys.cpp
5450354       0x532A72        Unix path: /../src/espvr/core/src/path/PVR_Thread.cpp
5452094       0x53313E        Unix path: /../src/espvr/core/src/path/PVR_Upload_State_Scan.cpp
5452634       0x53335A        Unix path: /../src/espvr/core/src/context/PVR_VideoParser.cpp
5453802       0x5337EA        Unix path: /../src/espvr/core/src/data_manager/PVR_Data_RingBuffer.cpp
5454258       0x5339B2        Unix path: /../src/espvr/core/src/context/PVR_File_IO_Read.cpp
5456690       0x534332        Unix path: /../src/espvr/core/src/context/PVR_File_IO_Write.cpp
5457670       0x534706        Unix path: /../src/espvr/core/src/path/PVR_Upload_State_188Normal.cpp
5458488       0x534A38        Unix path: /ecos-y/PERFORCE/THEALE/Uranus/eCospro/packages/infra/v2_0_60/src/pure.cxx
5458489       0x534A39        eCos RTOS string reference: "ecos-y/PERFORCE/THEALE/Uranus/eCospro/packages/infra/v2_0_60/src/pure.cxx"
5458519       0x534A57        eCos RTOS string reference: "eCospro/packages/infra/v2_0_60/src/pure.cxx"
5458613       0x534AB5        eCos RTOS string reference: "ecos-y/PERFORCE/THEALE/Uranus/eCospro/packages/services/memalloc/common/v2_0_60/src/kapi.cxx"
5458643       0x534AD3        eCos RTOS string reference: "eCospro/packages/services/memalloc/common/v2_0_60/src/kapi.cxx"
5460693       0x5352D5        eCos RTOS string reference: "ecos-y/PERFORCE/THEALE/Uranus/eCospro/Kappa/LIB_eCos_fileio_posix_fat_ntfs_jffs2_v3_c++_kappa_34kf_install/include/cyg/memalloc/"
5460723       0x5352F3        eCos RTOS string reference: "eCospro/Kappa/LIB_eCos_fileio_posix_fat_ntfs_jffs2_v3_c++_kappa_34kf_install/include/cyg/memalloc/mfiximpl.inl"
5460741       0x535305        eCos RTOS string reference: "eCos_fileio_posix_fat_ntfs_jffs2_v3_c++_kappa_34kf_install/include/cyg/memalloc/mfiximpl.inl"
5461473       0x5355E1        eCos RTOS string reference: "ecos-y/PERFORCE/THEALE/Uranus/eCospro/Kappa/LIB_eCos_fileio_posix_fat_ntfs_jffs2_v3_c++_kappa_34kf_install/include/cyg/memalloc/"
5461503       0x5355FF        eCos RTOS string reference: "eCospro/Kappa/LIB_eCos_fileio_posix_fat_ntfs_jffs2_v3_c++_kappa_34kf_install/include/cyg/memalloc/mvarimpl.inl"
5461521       0x535611        eCos RTOS string reference: "eCos_fileio_posix_fat_ntfs_jffs2_v3_c++_kappa_34kf_install/include/cyg/memalloc/mvarimpl.inl"
5462269       0x5358FD        eCos RTOS string reference: "ecos-y/PERFORCE/THEALE/Uranus/eCospro/packages/language/c/libc/stdio/v2_0_60/src/common/setvbuf.cxx"
5462299       0x53591B        eCos RTOS string reference: "eCospro/packages/language/c/libc/stdio/v2_0_60/src/common/setvbuf.cxx"
5522696       0x544508        Unix path: /ecos-y/PERFORCE/THEALE/Uranus/eCospro/packages/language/c/libc/i18n/v2_0_60/src/locale.cxx
5522697       0x544509        eCos RTOS string reference: "ecos-y/PERFORCE/THEALE/Uranus/eCospro/packages/language/c/libc/i18n/v2_0_60/src/locale.cxx"
5522727       0x544527        eCos RTOS string reference: "eCospro/packages/language/c/libc/i18n/v2_0_60/src/locale.cxx"
5523265       0x544741        eCos RTOS string reference: "ecos-y/PERFORCE/THEALE/Uranus/eCospro/packages/language/c/libc/stdio/v2_0_60/src/input/fgetc.cxx"
5523295       0x54475F        eCos RTOS string reference: "eCospro/packages/language/c/libc/stdio/v2_0_60/src/input/fgetc.cxx"
5524333       0x544B6D        eCos RTOS string reference: "ecos-y/PERFORCE/THEALE/Uranus/eCospro/packages/language/c/libc/time/v2_0_60/src/strftime.cxx"
5524363       0x544B8B        eCos RTOS string reference: "eCospro/packages/language/c/libc/time/v2_0_60/src/strftime.cxx"
6055568       0x5C6690        LZMA compressed data, properties: 0x5A, dictionary size: 4194304 bytes, uncompressed size: 16384 bytes
7114983       0x6C90E7        Boot section Start 0x7040000 End 0x-FFF9
7564060       0x736B1C        YAFFS filesystem
```

Here is boot log


问:
How to get a job in the Reverse Engineering community?
Just curious if there are any resources for finding a job being a Reverse Engineering specialist.  I have done some RE work in the past, and I find that I enjoy the work, but haven't really been able to find any job boards, or rather the typical job boards seldom mention "Information Security" positions let alone people who specialize in Reverse Engineering.</p>


问:
Add debugging symbols to objdump -d
I have a shared object (from a Debian package) and its debug library (from the associated debug package). If I disassemble the SO with objdump -d I only see (what I believe to be) the exported symbols. I would like to be able to see also the other symbols that are described in the debug library. Is there any way to do that?

(in a sense I would like to "merge back" the data that was stripped during compilation)

Title: Add debugging symbols to objdump -d


问:
Checksum reverse engineering help
I'm a newbie here, and I don't have a lot of experience with reverse engineering, so I'm asking for your help.

I have dumped a Mifare Classic card several times, because I wanted to try understand the data that was written on it. I compared the dumps and succeeded in understanding where the data was and in which format.

The data is stored in 8 bytes split into two groups. At the end of each group there is another byte which I suspect is some sort of checksum. Here is the data I got until now:

```<code>00 BB and 01 0B have a checksum byte of 45
01 6F and 01 0B have a checksum byte of B5
01 90 and 02 58 have a checksum byte of BC
01 90 and 00 C8 have a checksum byte of 56
00 00 and 00 00 have a checksum byte of 64
</code>```

Can you help me find out how the checksum byte is calculated? Thanks.

Title: Checksum reverse engineering help


问:
What does the number after '@' symbol mean in IDA disassembly?

As you can see, IDA disassembly shows r0@1, r5@5, [sp+0h] [bp-18h]@7 etc. Presuming r0, r5 to be registers and [sp+0h] [bp-18h] to be a memory location, what does the number at the end signify?


问:
Do any of these details contradict the idea that theory that this file is encrypted with Blowfish?
I have a file which has been encrypted with some unknown algorithm. Doing research on the file format, I stumbled across a website that claimed (without explaining why) that these files were encrypted with 32bit Blowfish. This website also speculates that the magic smoke is contained in a .iff file with a specific name.

It turns out that the .iff file is embedded in a plaintext portion of the encrypted file. I have clawed this out, and it hints at it being Blowfish.

The 4 byte header is "BLFS". The next int32 after that is 0x80. Then follows 16 bytes of random binary string (128 bits). Then, two more int32s... 0x75 and 0x01. Following that, 120 bytes of binary string (not 117?), and 4 nulls. The last bit I think is safe to assume as padding, as the parent file requires some weird byte-alignment scheme.

I have many examples of these encrypted files. The 128bit string changes, file to file. The 120byte string changes, file to file. BLFS, 0x80, 0x75, and 0x01 all remain constant.

I am a cryptography noob. The 120byte string is far too long to be a Blowfish key, which maxes out at 56 bytes. The 128bit string is a better bet (it has that nice round power-of-two number that the original implementor would have liked). I know that an algorithm like this would also require an iv, but aren't those short? In some cases, just a byte?

Is this iff file I've extracted the magic sauce, and is it the sort that I think it is? I'm not able to make sense of what I'm seeing, and I'm not sure what research I need to do next to accomplish that.

Apologies if this question isn't a fit for this SE, please comment and let me know that before closing.


问:
Calculating branch in arm64
I stumbled across this question here Offset calculation for branch instruction in ARM

After understanding all of that, i'm interested in knowing how i can do the same for ARM64/ARMv8 architecture?

Title: Calculating branch in arm64


问:
Analyzing Game Map/Terrain Format
I'm trying to understand how this game builds the map and terrain. Specially if it uses a heightmap. So I can write an app that can view the map and move around (camera) freely.

First, I'm not entirely sure if the game actually uses height maps. But it was made in 2000/2001, so it makes sense if it did.

The following files are loaded each time a map is loaded. I'll use map 4 as an example from here on:

```<code>/map/map4.spt
/map/map4.inf
/map/map4.obj
/terrain/chunk4.dat
/terrain/addterrain4.ctr
/terrain/addterrain4.obj
/terrain/addterrain4.inf
/terrain/addterrain4.t16
/terrain/terrain4.obj
/terrain/terrain4.t16
</code>```

*.T16

I know these are textures.

Here is terrain4.t16 unpacked (terrain):

And here is addterrain4.t16 unpacked (building):

*.SPT

I know this is an encrypted script. It contains things like ambient light color, sky color and other configurations for the map.

*.CTR

I'm not sure about this yet but I don't think this is the heightmap.

*.INF

I'm not sure about this yet but I don't think this is the heightmap. But it looks like positions for buildings/objects on the map.

*.OBJ

Although this sounds like a 3D object file, it isn't. So far I was able to parse this file with this script:

```<code>with open("map4.obj", "rb") as bin:
    bin.seek(0, 2)
    file_size = bin.tell()

    bin.seek(0)

    unk1 = struct.unpack("<h", bin.read(2))[0]

    width  = struct.unpack("<h", bin.read(2))[0]
    height = struct.unpack("<h", bin.read(2))[0]

    c_width = struct.unpack("<h", bin.read(2))[0]
    c_heigth = struct.unpack("<h", bin.read(2))[0]

    size1 = struct.unpack("<I", bin.read(4))[0]
    size2 = struct.unpack("<I", bin.read(4))[0]

    bin.seek(50)

    # (1, 76, 76, 304, 304, 5776, 92416)
    print(unk1, width, height, c_width, c_heigth, size1, size2)

    for x in range(size1):
        unk2 = struct.unpack("<BBBB", bin.read(4))

    for y in range(size2):
        unk3 = struct.unpack("<BB", bin.read(2))
</code>```

The script reads the file till the end so I think I got the parsing right. But I still don't understand what those bytes (unk2, unk3) mean.

Here are the first few bytes: (1, 76, 76, 304, 304, 5776, 92416).

76x76 seems to me like an image widthxheight. This is the part where I start to suspect that this must be the heightmaps.

304x304 is the size of the map coordinates, if I go to the bottom right part of the map, the coords show me x304 y304. (0,0) (304,304)

5776 is 76*76.

92416 is 304*304.

I'm guessing the cellspacing is 4, because 304/76 = 4.

Hmmm... Maybe I should be reading terrain4.obj instead of map4.obj ???

Checking terrain4.obj (filesize: 2,194,888)

```<code>with open("terrain4.obj", "rb") as bin:
    bin.seek(0, 2)
    file_size = bin.tell()

    bin.seek(0)

    width  = struct.unpack("<I", bin.read(4))[0]
    height = struct.unpack("<I", bin.read(4))[0]

    print(width, height)

    for x in range(width*height):
        unk1 = struct.unpack("<fffHH", bin.read(16))
        print(unk1)

        for y in range(10):
            unk2 = struct.unpack("<ffffffBBBBff", bin.read(36))
            print(unk2)

        unk3 = struct.unpack("<HH", bin.read(4))
        print(unk3)

    print((bin.tell()-file_size) == 0)
</code>```

results of prints (last few lines):

```<code>(64656, 900)
(9536.0, 0.0, -9664.0, 8, 60)
(9536.0, 367.3583679199219, -9664.0, 0.6106882691383362, 0.7202576398849487, -0.3290725350379944, 125, 125, 125, 255, 0.5, 0.5)
(9472.0, 439.9534912109375, -9664.0, 0.6727219820022583, 0.5930730104446411, -0.4423908591270447, 72, 72, 72, 255, 0.0, 0.5)
(9472.0, 529.98291015625, -9600.0, 0.5103294849395752, 0.5574429631233215, -0.6548444032669067, 91, 91, 91, 255, 0.0, 0.0)
(9536.0, 428.7572021484375, -9600.0, 0.5774530172348022, 0.5274922251701355, -0.6231372356414795, 83, 83, 83, 255, 0.5, 0.0)
(9600.0, 382.6859436035156, -9600.0, 0.32311421632766724, 0.6967470049858093, -0.6404222846031189, 110, 110, 110, 255, 1.0, 0.0)
(9600.0, 331.24566650390625, -9664.0, 0.4635116457939148, 0.8214490413665771, -0.3322325348854065, 149, 149, 149, 255, 1.0, 0.5)
(9600.0, 326.34356689453125, -9728.0, 0.5303630828857422, 0.847672700881958, -0.012873286381363869, 122, 122, 122, 255, 1.0, 1.0)
(9536.0, 370.5403747558594, -9728.0, 0.603411078453064, 0.7964465618133545, 0.039598409086465836, 107, 107, 107, 255, 0.5, 1.0)
(9472.0, 423.61572265625, -9728.0, 0.6945193409919739, 0.7165639996528625, -0.06464438885450363, 97, 97, 97, 255, 0.0, 1.0)
(9472.0, 439.9534912109375, -9664.0, 0.6727219820022583, 0.5930730104446411, -0.4423908591270447, 72, 72, 72, 255, 0.0, 0.5)
(64656, 900)
(9664.0, 0.0, -9664.0, 8, 60)
(9664.0, 323.531005859375, -9664.0, -0.16421209275722504, 0.9194830656051636, -0.3571907877922058, 202, 202, 202, 255, 0.5, 0.5)
(9600.0, 331.24566650390625, -9664.0, 0.11137175559997559, 0.9239282011985779, -0.3659959137439728, 199, 199, 199, 255, 0.0, 0.5)
(9600.0, 382.6859436035156, -9600.0, 0.32311421632766724, 0.6967470049858093, -0.6404222846031189, 110, 110, 110, 255, 0.0, 0.0)
(9664.0, 370.8617248535156, -9600.0, -0.030711062252521515, 0.8036384582519531, -0.5943247675895691, 202, 202, 202, 255, 0.5, 0.0)
(9728.0, 387.73626708984375, -9600.0, -0.3357184827327728, 0.8114649057388306, -0.478348970413208, 202, 202, 202, 255, 1.0, 0.0)
(9728.0, 359.2901306152344, -9664.0, -0.4858676493167877, 0.869583010673523, -0.0880785584449768, 202, 202, 202, 255, 1.0, 0.5)
(9728.0, 373.6744079589844, -9728.0, -0.6241185665130615, 0.7812370657920837, -0.012026631273329258, 202, 202, 202, 255, 1.0, 1.0)
(9664.0, 302.3572998046875, -9728.0, -0.23366673290729523, 0.9231089949607849, -0.3054006099700928, 202, 202, 202, 255, 0.5, 1.0)
(9600.0, 326.34356689453125, -9728.0, 0.23029862344264984, 0.9547197222709656, -0.18834225833415985, 177, 177, 177, 255, 0.0, 1.0)
(9600.0, 331.24566650390625, -9664.0, 0.11137175559997559, 0.9239282011985779, -0.3659959137439728, 199, 199, 199, 255, 0.0, 0.5)
(64656, 900)
True
</code>```

*.DAT

First few bytes of 2,127,308 total:

```<code>00000000 19 00 00 00 00 01 00 00 23 00 00 00 00 00 80 42 ........#......B
00000016 00 00 FF 43 00 00 80 C2 00 00 00 00 FF FF 7F 3F ...C...........?
00000032 00 00 00 00 7A 7A 7A FF 00 00 00 3F 00 00 00 3F ....zzz....?...?
00000048 00 00 00 00 00 00 FF 43 00 00 80 C2 00 00 00 00 .......C........
00000064 FF FF 7F 3F 00 00 00 00 7A 7A 7A FF 00 00 00 00 ...?....zzz.....
00000080 00 00 00 3F 00 00 00 00 00 00 FF 43 00 00 00 80 ...?.......C....
00000096 00 00 00 00 FF FF 7F 3F 00 00 00 00 7A 7A 7A FF .......?....zzz.
00000112 00 00 00 00 00 00 00 00 00 00 80 42 00 00 FF 43 ...........B...C
</code>```

I'm not sure about this one though.

My Questions:

Could the .obj file possibly be the heightmap, if not, what is it?

Any idea what the .CTR and .INF files are? (guesses?)

Additional Information:

The map 4 is called Lava Canyon. It features paths surrounded by canyons of lava.

Minimap Texture:

Related files: Download From Mediafire

Title: Analyzing Game Map/Terrain Format


问:
Find memory mapped file with x64dbg
I have 64 bit process I want to debug with x64dbg. There is memory mapped file, I found with help of Process Explorer. Properties windows says:

```<code>Type: Section
Description: A memory mapped file or paging-file...
Address: 0xFFFFF8A002D8A080
</code>```

But when I look into x64dbg Memory Map tab, there is no such addresses. I see only range 0000000000010000-000007FFFFFE0000. How I can find memory mapped file? I want to place memory breakpoint on it.

Title: Find memory mapped file with x64dbg


问:
Reverse Engineering Wifi Chip-set Firmware
I have Sparrow Wireless Adapter which from Qualcomm originally Wilocity that supports Wifi over 60 GHz (802.11ad or WiGiG). I have the firmware files of the wireless chipset (wil6210.fw and wil6210.brd). I would like to know the following:

Did anyone manage to reverse engineer the firmware and and get an insight regarding the implementation?

How would it be possible to know if the firmware is protected/encrypted or not?

What is the best tool to dissemble the firmware file and extract useful information out of it and allow to build new firmware?


问:
How can I send a "Break" to the WinDbg backend when using IDA as a frontend?
When I use WinDbg and there's some long operation, I can press CtrlBreak to cancel the current operation (for instance, but not limited to, cancel PDB loading). Or use this:

However, whenever I use WinDbg as a backend to IDA, it simply hangs until the current operation has finished. Is there any shortcut for sending a CtrlBreak to the WinDbg backend or I just have to wait for it to complete?


问:
Am I seeing this dll's innards correctly?
The dll in question is custom, from a retail/consumer software package that was first offered for sale in 2006/2007. I am fairly confident that it was compiled with Visual Studio .NET (2003).

My initial attempts to understand the dll had me test-driving various proxy dll code generators. I was able to extract the exported functions (nearly 800 of them), and the code would build. Unfortunately the retail software would reject this dll because of some mismatched signature that I was eventually able to ascertain with the corflags.exe VS utility. Eventually it became clear that my version of Visual Studio was too modern to ever match this, and after some hair-pulling I acquired VS2003. Finding that it can never install properly on modern windows, I dug Windows XP out of a closet, and I now have a VM with which to build the proxy dll... signature matches, new errors are showing.

It's complaining that it can't load a type, which it names. I was under the impression that the proxy dll generator was taking care of this. Spent some time making sure it wasn't missing anything, and it doesn't appear to be.

But the dll is built with CLR/.NET 1.1, which is slightly strange. So I downloaded IntelliJ's dotpeek decompiler. Sure enough, this brings up a relatively small handful of classes and structs that I haven't seen before. It even shows me the c# sharp code for this (variable names don't look like decompiled/disassembled stuff... does dotnet not strip these during compilation?).

So now I have a dll that looks as if it has both cpp and cs code in it both. Is that a valid/viable dll build result? I have yet to find any instructions, tutorials, or documentation that suggests this is now possible or ever was. But quite a few microsoft.com and msdn forum links are dead, so this is difficult to research. I feel as if I must be misinterpreting what I'm seeing, and that my amateurish attempts are just confusing me.

If this was ever a thing, can someone tell me what buzzwords it was called by? My Microsoft jargon is pretty limited, and I'm finding a whole bunch of nothing.


问:
Error: the file can't be loaded by debugger plupin IDA PRO 64 bit
I use IDA PRO 64bits on windows 10 64 bit, I want use it remote debug a file 64bit by linux. When I run linux_serverx64 in linux and connect then i error:  the file can't be loaded by debugger plupin IDA PRO 64 bit, Please verify that the parameters are valid, and in linux error: execvp(flag): 2: No such file or directory but file flag exist
. I try debug with file 32 bit, it is ok. Who can guide me how to fix it.</p>


问:
Reverse Engineering Legacy iPod Click Wheel Games
I have recently found a bunch of old iPod (pre-touch) games.  These ipg files (similar to modern iOS ipa files).  Are application bundles which contain resources (images, music files, textures), sometimes a localized strings file, and executables.

Each bundle contains a Manifest.plist file, with executable information.  Below is the manifest for Bomberman 1.0:

```<code><?xml version="1.0" encoding="UTF-8"?>
<!DOCTYPE plist PUBLIC "-//Apple Computer//DTD PLIST 1.0//EN" "http://www.apple.com/DTDs/PropertyList-1.0.dtd">
<plist version="1.0">
<dict>
    <key>BuildIdentifier</key>
    <string>1465338237-ae7bdef1533
</string>
    <key>Files</key>
    <array>
        <dict>
            <key>Digest</key>
            <string>D576EBCA193EA6C08060394435497CBE52288730</string>
            <key>Path</key>
            <string>bombLaunchm25.raw.lcd5</string>
            <key>Size</key>
            <integer>138256</integer>
        </dict>
        <dict>
            <key>DRM</key>
            <true/>
            <key>Digest</key>
            <string>10A5CD8E82B692D4A3136753639FFE9EC96F9E72</string>
            <key>Path</key>
            <string>Executables/iPodBomberman_7052137.bin</string>
            <key>Size</key>
            <integer>425664</integer>
            <key>Verify</key>
            <true/>
        </dict>
        <dict>
            <key>Digest</key>
            <string>3DBFC1556706CF12555448CC5103FCCB59E6E773</string>
            <key>Path</key>
            <string>bombLaunchm1a.raw.lcd5</string>
            <key>Size</key>
            <integer>6176</integer>
        </dict>
        <dict>
            <key>DRM</key>
            <true/>
            <key>Digest</key>
            <string>99B99192D77939DAB9A7E05AEB9ED564D33ECFDB</string>
            <key>Path</key>
            <string>Executables/iPodBomberman_7052208.bin</string>
            <key>Size</key>
            <integer>633344</integer>
            <key>Verify</key>
            <true/>
        </dict>
    </array>
    <key>GUID</key>
    <string>20000</string>
    <key>Name</key>
    <string>Bomberman</string>
    <key>Platforms</key>
    <array>
        <dict>
            <key>BuildID</key>
            <integer>7052137</integer>
            <key>ExecutablePath</key>
            <string>Executables/iPodBomberman_7052137.bin</string>
            <key>LaunchingArtwork</key>
            <string>bombLaunchm25.raw.lcd5</string>
            <key>PlatformID</key>
            <integer>1</integer>
            <key>PlatformVersion</key>
            <integer>1</integer>
            <key>Size</key>
            <integer>425664</integer>
        </dict>
        <dict>
            <key>BuildID</key>
            <integer>7052208</integer>
            <key>ExecutablePath</key>
            <string>Executables/iPodBomberman_7052208.bin</string>
            <key>LaunchingArtwork</key>
            <string>bombLaunchm1a.raw.lcd5</string>
            <key>PlatformID</key>
            <integer>2</integer>
            <key>PlatformVersion</key>
            <integer>1</integer>
            <key>Size</key>
            <integer>633344</integer>
        </dict>
        <dict>
            <key>BuildID</key>
            <integer>7052208</integer>
            <key>ExecutablePath</key>
            <string>Executables/iPodBomberman_7052208.bin</string>
            <key>LaunchingArtwork</key>
            <string>bombLaunchm1a.raw.lcd5</string>
            <key>PlatformID</key>
            <integer>3</integer>
            <key>PlatformVersion</key>
            <integer>1</integer>
            <key>Size</key>
            <integer>633344</integer>
        </dict>
    </array>
    <key>Version</key>
    <string>1.0</string>
</dict>
</plist>
</code>```

The Manifest appears to contain two different builds (one is listed twice), presumably for two different iPod architectures (?).  For each executable there also appears to be an accompanying .bin.sinf file, which I believe contains purchaser information used by Apple's FairPlay DRM.

Here's where I get stuck:

Running strings on either of the executables, .bin.sinf files, or the .raw.lcd5 files prints garbage.

Running nm gives me an error that the files are not object files.

file just tells me that the files are binary data.

I cannot use otool because the files are not Mach-O binaries.

According to Wikipedia, all iPods before the 6th gen classic used an ARM processor (one or more 7TDMI-derived CPUs).

What are my options for dissembling or reading any of the information (strings, etc) of these executables and binary files?


问:
Comparing two UEFI applications?
I have two x86-64 UEFI applications original.efi and patched.efi. I want to find out what have been changed in patched.efi and what these changes do.

I have tried to use the Radare2 framework to solve this task:

$ radiff2 original.efi patched.efi

```<code>Buffer truncated to 283136 bytes (1024 not compared)
0x000000d8 e129 => d52e 0x000000d8
0x000099d0 35 => 00 0x000099d0
0x0000eefb 3637 => 3730 0x0000eefb
0x0000ef03 3031323538 => 3330353136 0x0000ef03
</code>```

I have then opened two windows side by side and run radare2 on each file:

$ radare2 original.efi

```<code>[0x0000a66c] aaa
[0x0000a66c] s 0x000000d8
[0x000000d8] pd 10
</code>```

$ radare2 patched.efi

```<code>[0x0000a66c] aaa
[0x0000a66c] s 0x000000d8
[0x000000d8] pd 10
</code>```

In this case there is a difference at the address, but it looks like there is something wrong:

```<code>0x000000d8    d5           invalid            |     0x000000d8    e129         loope 0x103
0x000000d9    2e05000a0000 add eax, 0xa00     |     0x000000da    05000a0000   add eax, 0xa00
</code>```

However, in many cases I have found that even though radiff2 reports a difference at a memory location, when I try to compare like described above, no differences are found and the lines are identical.

Can anyone explain if I'm doing anything wrong or maybe a better way to do this?

Unfortunately, I do not have access to a Windows system, so I can only use tools available for Linux.

Title: Comparing two UEFI applications?


问:
Am I interpreting the instructions correctly or not. (ollydbg + executable)
I'm fairly new in reverse engineering, but I do comprehend assembly code. However, I'm facing a problem.

It is about an old Rockstar game, "Bully: The scholarship edition" (released 2007 - aka "Canis Canem Edit"). It however has issues to perform on Windows 10 anniversary edition OS that I have at this moment. That is expected since it's an old software. To resolve that, I tried many online solutions (compat mode, setting CPU affinity, ect), which didn't helped much.

So I decided to look into the code by using OllyDbg. The cause of the crash is pretty constant; an access violation. However, it is purely random. I am able to play a hour without problems, or experiencing a crash within 10 minutes. The program apparently tries to move data from address 0 to a register, which isn't allowed. The exception is always thrown at the same place, where the pointer call occurs.

Here is a screenshot from OllyDbg when debugging the program. (Sorry for small resolution, it's an old game, hence the resolution is set at 1280x960)

The exception is thrown at address 0088729D which has this instruction

```<code>MOV ECX, DWORD PTR DS:[EAX]
</code>```

The EAX register is apparently empty (you can see that in the image). So I checked when information is moved to that register. It happens at the address (I've selected the line and added comment "moves empty address") 00887281. It contains the following instruction:

```<code>MOV EAX, DWORD PTR SS:[ESP+8]
</code>```

As far I know, SS is the stack segment register and ESP extended stack pointer. The ESP register contains address 0019F3A0. With offset 8, the address is now 0019F3A8 (see selection in the right bottom box). It contains 00002000.

I'm now clueless after this point. I don't understand why the address during the call is zero and not that value. I expect that the EAX register would contain 00002000 after the instruction. However, this is not the case this time. The EAX register contains 00000000.

I believe that I'm interpreting this incorrectly. Can someone point me where my misinterpretation occurs or inform me how to check this problem more correctly?

Thank you.

PS: the reason for this is because I've played bully in my childhood and want to play again. Apparently, there are other users with the same problem, even after attempting the known solutions on the web. Perhaps if I find a solid solution for this, that I would be able to help others too.


问:
What encryption/compression is this, and how to encode/decode from it?
I've been trying to reverse engineer an Android app's communication protocol using a combination of Xposed and Packet sniffing.
Most of the packets the app sends have this header set:

```<code>Content-Type: application/octet-stream
</code>```

which leads me to beleive it is some sort of byte array. The sniffed packet body is encoded in something I do not recognize, but thanks to Xposed, I can get the decoded version. This is what I receive from the server: http://i.imgur.com/lIV6BiQ.png (raw data is at http://bit.ly/2g5JKgH ). I've tried various ways of decoding it to no avail. After hooking some methods in Xposed which receive the final, decoded data, I found that the decoded version of the data I was sniffing is this:

```<code>{"miis":[{"owner_player_id":"12bea2c3d7654b66","position":"12bea2c3d7654b66"}],"SAKASHO_CURRENT_ASSET_REVISION":"","SAKASHO_CURRENT_MASTER_REVISION":"b324a24d2cf7cd0effb2941e9f5e515456e9e82d","SAKASHO_CURRENT_DATE_TIME":1480231467}
</code>```

I'm not sure how it got decoded, but I have some clues.
First, the encoded packet has a size of 183 bytes, while the decoded version has a size of 231 bytes. This leads me to believe it's using some sort of compression. The client also sends an Accept-Encoding: gzip to the server which supports this, but after decoding it using gzip, I still get unreadable data, which I think means there is some sort of encryption going on. Looking at the app's code, translated from smali into a rough java equivalent, this is the method that supposedly takes in a byte array and spits out a String

```<code>public static String a(byte[] bArr) {
        if (bArr == null) {
            return null;
        }
        try {
            return new String(bArr, "UTF-8");
        } catch (Throwable e) {
            throw new RuntimeException("Can't happen!", e);
        }
    }
</code>```

however, while trying to replicate this in my own Java program, I always get the original strange character representation of the data.

What I'm wondering is, how does the original packet data get to the final, uncompressed json structure, and if it's a general encoding method, or one the app developers made themselves.

Thanks in advance.


问:
Reverse Engineer an iOS MP4 Bug
Recently I came across and malformed mp4 that when played on the iPhone would crash the device.  I am trying to figure out which bits are specifically responsible for the crash.  I am wondering if there is any software out there that can help me inspect the different mp4 meta fields and find out where the problem is so that I can write detection logic to block files like it.

I don't want to directly link the mp4, but some google searches should be able to bring it up easily.

Title: Reverse Engineer an iOS MP4 Bug


问:
Symbols could not be loaded for win32k drivers
I'm doing a kernel debugging on a VmWare installed Windows 10 corporate edition (x64 version 1607 build 14393.447). I use Ida Pro 6.6 with the WinDbg plugin. On my host i have the same OS , with Debugging Tools For WIndows 10 installed. When i connect to the target machine, all the symbols are loaded correctly except for the win32 system ( win32k.sys/win32kbase.sys/win32kfull.sys ). I have the symbols defined in my user-environment variable like so :

```<code>_NT_SYMBOL_PATH=srv*c:\symbols*https://msdl.microsoft.com/download/symbols
</code>```

When i choose load symbols in Ida modules menu i get the following output:

```<code>WINDBG>!sym noisy
noisy mode - symbol prompts on

Trying loadDataForExe with 14000000
loadDataForExe: 806d0012
Trying loadDataForExe with ffffffff
loadDataForExe: 806d0005
PDB: could not process file \SystemRoot\System32\win32kbase.sys with DIA: Failed to open the file, or the file has an invalid format (E_PDB_NOT_FOUND)

Trying loadDataForExe with 13dd0000
loadDataForExe: 806d0012
Trying loadDataForExe with ffffffff
loadDataForExe: 806d0005
PDB: could not process file \SystemRoot\System32\win32k.sys with DIA: Failed to open the file, or the file has an invalid format (E_PDB_NOT_FOUND)

Trying loadDataForExe with 14960000
loadDataForExe: 806d0012
Trying loadDataForExe with ffffffff
loadDataForExe: 806d0005
PDB: could not process file \SystemRoot\System32\win32kfull.sys with DIA: Failed to open the file, or the file has an invalid format (E_PDB_NOT_FOUND)
</code>```

lmi output:

```<code>WINDBG>!lmi win32kbase
Loaded Module Info: [win32kbase]
Cannot read Image header @ ffff81ce14000000
Load Report: export symbols

WINDBG>!lmi win32k
Loaded Module Info: [win32k]
Cannot read Image header @ ffff81ce13dd0000
Load Report: public symbols , not source indexed
                     c:\symbols\win32k.pdb\0383A6141581403B9E8426F05328D45F1\win32k.pdb

WINDBG>!lmi win32kfull
Loaded Module Info: [win32kfull]
Cannot read Image header @ ffff81ce14960000
    Load Report: public symbols , not source indexed
                 c:\symbols\win32kfull.pdb\A792B492035540D397D66128F30037B01\win32kfull.pdb
</code>```

This is all really annoying, because sometimes the symbols just loads correctly, i do not know on what this depends, i found a similar topics in google here they had the same problem, but with the dumps.
This is really annoying problem, maybe someone had the same problem, trying to do some reverse-engineering the win32k subsystem, and can help me.


问:
Recognize this encoding (in a serialization context)?
I am currently trying to reverse engineer a proprietary serialization format. In some of the sections the encoding is unknown to me. What I was able to figure out:

1 byte 0b00?????? "6bit signed int" (0x00 = 0, 0x3F = 63, 0x40 = -64, 0x7F = -1)

2 byte 0xC? 0x?? "12 bit signed int" (0xC0 0x40 = 64, 0xC7 0xFF = 2047, 0xC8 0x00 = -2048, 0xCF 0xBF = -65)

3 byte 0xD? 0x?? 0x?? "20bit signed int"

4 byte 0xE? 0x?? 0x?? 0x?? "28bit signed int"

Everything big endian, btw.

Strings seem to be 0xF3 ... 0x00

Does somebody know/recognize this encoding?


问:
When to use qemu user mode versus system mode?
This seems to be a pretty basic question but I can't seem to find a good answer.

I am currently just following https://w00tsec.blogspot.ca/2013/09/analyzing-and-running-binaries-from.html to learn more about emulating with qemu.

Whats the advantages and disadvantages between:

```<code>sudo chroot . ./qemu-mips-static bin/busybox (example)
</code>```

compared to following the instructions found here: https://people.debian.org/~aurel32/qemu/mips/

```<code>qemu-system-mips -M malta kernel
</code>```

Thanks in advance!


问:
OllyDbg: break on memory allocation?
In OllyDbg, is there a way to break when memory is allocated?

Normally, I would just find a malloc call and set the break there, but that's not always available in the case of packed/encrypted/obfuscated code.

The memory map seems to only allow breaks on already allocated memory.

If not Ollydbg, is there another tool that can do this?

Thanks,

Geoff

I've got my GREM, but I'm still pretty new to reversing.

Title: OllyDbg: break on memory allocation?


Title: Decrypting/Decoding encrypted/encoded data

Body:
I'm trying to increase the interoperability of some database software. The database can write and read "stored SQL queries". I wanted to figure out the format of these SQL queries so I can build them outside the application.

I started out with some data gathering:

```<code>"A"      ff aa 01 01 50 00 00 00 78 01 63 64 40 05 ff ff fd e7 4c 64 c8 01 c2 78 20 ce 64 c8 63 c8 66 28 66 00 8a 32 3a c2 15 02 79 20 11 38 1f c6 60 04 32 00 99 3a 0f f7
"B"      ff aa 01 01 50 00 00 00 78 01 63 64 40 05 ff ff fd e7 4c 64 c8 01 c2 78 20 ce 64 c8 63 c8 66 28 66 00 8a 32 3a c1 15 02 79 20 11 38 1f c6 60 04 32 00 99 60 0f f8
"C"      ff aa 01 01 50 00 00 00 78 01 63 64 40 05 ff ff fd e7 4c 64 c8 01 c2 78 20 ce 64 c8 63 c8 66 28 66 00 8a 32 3a c3 15 02 79 20 11 38 1f c6 60 04 32 00 99 86 0f f9
"D"      ff aa 01 01 50 00 00 00 78 01 63 64 40 05 ff ff fd e7 4c 64 c8 01 c2 78 20 ce 64 c8 63 c8 66 28 66 00 8a 32 ba c0 15 02 79 20 11 38 1f c6 60 04 32 00 99 ac 0f fa
"E"      ff aa 01 01 50 00 00 00 78 01 63 64 40 05 ff ff fd e7 4c 64 c8 01 c2 78 20 ce 64 c8 63 c8 66 28 66 00 8a 32 ba c2 15 02 79 20 11 38 1f c6 60 04 32 00 99 d2 0f fb
"F"      ff aa 01 01 50 00 00 00 78 01 63 64 40 05 ff ff fd e7 4c 64 c8 01 c2 78 20 ce 64 c8 63 c8 66 28 66 00 8a 32 ba c1 15 02 79 20 11 38 1f c6 60 04 32 00 99 f8 0f fc
"G"      ff aa 01 01 50 00 00 00 78 01 63 64 40 05 ff ff fd e7 4c 64 c8 01 c2 78 20 ce 64 c8 63 c8 66 28 66 00 8a 32 ba c3 15 02 79 20 11 38 1f c6 60 04 32 00 9a 1e 0f fd
"H"      ff aa 01 01 50 00 00 00 78 01 63 64 40 05 ff ff fd e7 4c 64 c8 01 c2 78 20 ce 64 c8 63 c8 66 28 66 00 8a 32 7a c0 15 02 79 20 11 38 1f c6 60 04 32 00 9a 44 0f fe
"I"      ff aa 01 01 50 00 00 00 78 01 63 64 40 05 ff ff fd e7 4c 64 c8 01 c2 78 20 ce 64 c8 63 c8 66 28 66 00 8a 32 7a c2 15 02 79 20 11 38 1f c6 60 04 32 00 9a 6a 0f ff
"J"      ff aa 01 01 50 00 00 00 78 01 63 64 40 05 ff ff fd e7 4c 64 c8 01 c2 78 20 ce 64 c8 63 c8 66 28 66 00 8a 32 7a c1 15 02 79 20 11 38 1f c6 60 04 32 00 9a 90 10 00
"K"      ff aa 01 01 50 00 00 00 78 01 63 64 40 05 ff ff fd e7 4c 64 c8 01 c2 78 20 ce 64 c8 63 c8 66 28 66 00 8a 32 7a c3 15 02 79 20 11 38 1f c6 60 04 32 00 9a b6 10 01
"L"      ff aa 01 01 50 00 00 00 78 01 63 64 40 05 ff ff fd e7 4c 64 c8 01 c2 78 20 ce 64 c8 63 c8 66 28 66 00 8a 32 fa c0 15 02 79 20 11 38 1f c6 60 04 32 00 9a dc 10 02
"M"      ff aa 01 01 50 00 00 00 78 01 63 64 40 05 ff ff fd e7 4c 64 c8 01 c2 78 20 ce 64 c8 63 c8 66 28 66 00 8a 32 fa c2 15 02 79 20 11 38 1f c6 60 04 32 00 9b 02 10 03
"N"      ff aa 01 01 50 00 00 00 78 01 63 64 40 05 ff ff fd e7 4c 64 c8 01 c2 78 20 ce 64 c8 63 c8 66 28 66 00 8a 32 fa c1 15 02 79 20 11 38 1f c6 60 04 32 00 9b 28 10 04
"O"      ff aa 01 01 50 00 00 00 78 01 63 64 40 05 ff ff fd e7 4c 64 c8 01 c2 78 20 ce 64 c8 63 c8 66 28 66 00 8a 32 fa c3 15 02 79 20 11 38 1f c6 60 04 32 00 9b 4e 10 05
"P"      ff aa 01 01 50 00 00 00 78 01 63 64 40 05 ff ff fd e7 4c 64 c8 01 c2 78 20 ce 64 c8 63 c8 66 28 66 00 8a 32 06 c0 15 02 79 20 11 38 1f c6 60 04 32 00 9b 74 10 06
"Q"      ff aa 01 01 50 00 00 00 78 01 63 64 40 05 ff ff fd e7 4c 64 c8 01 c2 78 20 ce 64 c8 63 c8 66 28 66 00 8a 32 06 c2 15 02 79 20 11 38 1f c6 60 04 32 00 9b 9a 10 07
"R"      ff aa 01 01 50 00 00 00 78 01 63 64 40 05 ff ff fd e7 4c 64 c8 01 c2 78 20 ce 64 c8 63 c8 66 28 66 00 8a 32 06 c1 15 02 79 20 11 38 1f c6 60 04 32 00 9b c0 10 08
"S"      ff aa 01 01 50 00 00 00 78 01 63 64 40 05 ff ff fd e7 4c 64 c8 01 c2 78 20 ce 64 c8 63 c8 66 28 66 00 8a 32 06 c3 15 02 79 20 11 38 1f c6 60 04 32 00 9b e6 10 09
"T"      ff aa 01 01 50 00 00 00 78 01 63 64 40 05 ff ff fd e7 4c 64 c8 01 c2 78 20 ce 64 c8 63 c8 66 28 66 00 8a 32 86 c0 15 02 79 20 11 38 1f c6 60 04 32 00 9c 0c 10 0a
"U"      ff aa 01 01 50 00 00 00 78 01 63 64 40 05 ff ff fd e7 4c 64 c8 01 c2 78 20 ce 64 c8 63 c8 66 28 66 00 8a 32 86 c2 15 02 79 20 11 38 1f c6 60 04 32 00 9c 32 10 0b
"V"      ff aa 01 01 50 00 00 00 78 01 63 64 40 05 ff ff fd e7 4c 64 c8 01 c2 78 20 ce 64 c8 63 c8 66 28 66 00 8a 32 86 c1 15 02 79 20 11 38 1f c6 60 04 32 00 9c 58 10 0c
"W"      ff aa 01 01 50 00 00 00 78 01 63 64 40 05 ff ff fd e7 4c 64 c8 01 c2 78 20 ce 64 c8 63 c8 66 28 66 00 8a 32 86 c3 15 02 79 20 11 38 1f c6 60 04 32 00 9c 7e 10 0d
"X"      ff aa 01 01 50 00 00 00 78 01 63 64 40 05 ff ff fd e7 4c 64 c8 01 c2 78 20 ce 64 c8 63 c8 66 28 66 00 8a 32 46 c0 15 02 79 20 11 38 1f c6 60 04 32 00 9c a4 10 0e
"Y"      ff aa 01 01 50 00 00 00 78 01 63 64 40 05 ff ff fd e7 4c 64 c8 01 c2 78 20 ce 64 c8 63 c8 66 28 66 00 8a 32 46 c2 15 02 79 20 11 38 1f c6 60 04 32 00 9c ca 10 0f
"Z"      ff aa 01 01 50 00 00 00 78 01 63 64 40 05 ff ff fd e7 4c 64 c8 01 c2 78 20 ce 64 c8 63 c8 66 28 66 00 8a 32 46 c1 15 02 79 20 11 38 1f c6 60 04 32 00 9c f0 10 10
"a"      ff aa 01 01 50 00 00 00 78 01 63 64 40 05 ff ff fd e7 4c 64 c8 01 c2 78 20 ce 64 c8 63 c8 66 28 66 00 8a 32 26 c2 15 02 79 20 11 38 1f c6 60 04 32 00 9d fa 10 17
"b"      ff aa 01 01 50 00 00 00 78 01 63 64 40 05 ff ff fd e7 4c 64 c8 01 c2 78 20 ce 64 c8 63 c8 66 28 66 00 8a 32 26 c1 15 02 79 20 11 38 1f c6 60 04 32 00 9e 20 10 18
"c"      ff aa 01 01 50 00 00 00 78 01 63 64 40 05 ff ff fd e7 4c 64 c8 01 c2 78 20 ce 64 c8 63 c8 66 28 66 00 8a 32 26 c3 15 02 79 20 11 38 1f c6 60 04 32 00 9e 46 10 19
"d"      ff aa 01 01 50 00 00 00 78 01 63 64 40 05 ff ff fd e7 4c 64 c8 01 c2 78 20 ce 64 c8 63 c8 66 28 66 00 8a 32 a6 c0 15 02 79 20 11 38 1f c6 60 04 32 00 9e 6c 10 1a
"e"      ff aa 01 01 50 00 00 00 78 01 63 64 40 05 ff ff fd e7 4c 64 c8 01 c2 78 20 ce 64 c8 63 c8 66 28 66 00 8a 32 a6 c2 15 02 79 20 11 38 1f c6 60 04 32 00 9e 92 10 1b
"f"      ff aa 01 01 50 00 00 00 78 01 63 64 40 05 ff ff fd e7 4c 64 c8 01 c2 78 20 ce 64 c8 63 c8 66 28 66 00 8a 32 a6 c1 15 02 79 20 11 38 1f c6 60 04 32 00 9e b8 10 1c
"g"      ff aa 01 01 50 00 00 00 78 01 63 64 40 05 ff ff fd e7 4c 64 c8 01 c2 78 20 ce 64 c8 63 c8 66 28 66 00 8a 32 a6 c3 15 02 79 20 11 38 1f c6 60 04 32 00 9e de 10 1d
"h"      ff aa 01 01 50 00 00 00 78 01 63 64 40 05 ff ff fd e7 4c 64 c8 01 c2 78 20 ce 64 c8 63 c8 66 28 66 00 8a 32 66 c0 15 02 79 20 11 38 1f c6 60 04 32 00 9f 04 10 1e
"i"      ff aa 01 01 50 00 00 00 78 01 63 64 40 05 ff ff fd e7 4c 64 c8 01 c2 78 20 ce 64 c8 63 c8 66 28 66 00 8a 32 66 c2 15 02 79 20 11 38 1f c6 60 04 32 00 9f 2a 10 1f
"j"      ff aa 01 01 50 00 00 00 78 01 63 64 40 05 ff ff fd e7 4c 64 c8 01 c2 78 20 ce 64 c8 63 c8 66 28 66 00 8a 32 66 c1 15 02 79 20 11 38 1f c6 60 04 32 00 9f 50 10 20
"k"      ff aa 01 01 50 00 00 00 78 01 63 64 40 05 ff ff fd e7 4c 64 c8 01 c2 78 20 ce 64 c8 63 c8 66 28 66 00 8a 32 66 c3 15 02 79 20 11 38 1f c6 60 04 32 00 9f 76 10 21
"l"      ff aa 01 01 50 00 00 00 78 01 63 64 40 05 ff ff fd e7 4c 64 c8 01 c2 78 20 ce 64 c8 63 c8 66 28 66 00 8a 32 e6 c0 15 02 79 20 11 38 1f c6 60 04 32 00 9f 9c 10 22
"m"      ff aa 01 01 50 00 00 00 78 01 63 64 40 05 ff ff fd e7 4c 64 c8 01 c2 78 20 ce 64 c8 63 c8 66 28 66 00 8a 32 e6 c2 15 02 79 20 11 38 1f c6 60 04 32 00 9f c2 10 23
"n"      ff aa 01 01 50 00 00 00 78 01 63 64 40 05 ff ff fd e7 4c 64 c8 01 c2 78 20 ce 64 c8 63 c8 66 28 66 00 8a 32 e6 c1 15 02 79 20 11 38 1f c6 60 04 32 00 9f e8 10 24
"o"      ff aa 01 01 50 00 00 00 78 01 63 64 40 05 ff ff fd e7 4c 64 c8 01 c2 78 20 ce 64 c8 63 c8 66 28 66 00 8a 32 e6 c3 15 02 79 20 11 38 1f c6 60 04 32 00 a0 0e 10 25
"p"      ff aa 01 01 50 00 00 00 78 01 63 64 40 05 ff ff fd e7 4c 64 c8 01 c2 78 20 ce 64 c8 63 c8 66 28 66 00 8a 32 16 c0 15 02 79 20 11 38 1f c6 60 04 32 00 a0 34 10 26
"q"      ff aa 01 01 50 00 00 00 78 01 63 64 40 05 ff ff fd e7 4c 64 c8 01 c2 78 20 ce 64 c8 63 c8 66 28 66 00 8a 32 16 c2 15 02 79 20 11 38 1f c6 60 04 32 00 a0 5a 10 27
"r"      ff aa 01 01 50 00 00 00 78 01 63 64 40 05 ff ff fd e7 4c 64 c8 01 c2 78 20 ce 64 c8 63 c8 66 28 66 00 8a 32 16 c1 15 02 79 20 11 38 1f c6 60 04 32 00 a0 80 10 28
"s"      ff aa 01 01 50 00 00 00 78 01 63 64 40 05 ff ff fd e7 4c 64 c8 01 c2 78 20 ce 64 c8 63 c8 66 28 66 00 8a 32 16 c3 15 02 79 20 11 38 1f c6 60 04 32 00 a0 a6 10 29
"t"      ff aa 01 01 50 00 00 00 78 01 63 64 40 05 ff ff fd e7 4c 64 c8 01 c2 78 20 ce 64 c8 63 c8 66 28 66 00 8a 32 96 c0 15 02 79 20 11 38 1f c6 60 04 32 00 a0 cc 10 2a
"u"      ff aa 01 01 50 00 00 00 78 01 63 64 40 05 ff ff fd e7 4c 64 c8 01 c2 78 20 ce 64 c8 63 c8 66 28 66 00 8a 32 96 c2 15 02 79 20 11 38 1f c6 60 04 32 00 a0 f2 10 2b
"v"      ff aa 01 01 50 00 00 00 78 01 63 64 40 05 ff ff fd e7 4c 64 c8 01 c2 78 20 ce 64 c8 63 c8 66 28 66 00 8a 32 96 c1 15 02 79 20 11 38 1f c6 60 04 32 00 a1 18 10 2c
"w"      ff aa 01 01 50 00 00 00 78 01 63 64 40 05 ff ff fd e7 4c 64 c8 01 c2 78 20 ce 64 c8 63 c8 66 28 66 00 8a 32 96 c3 15 02 79 20 11 38 1f c6 60 04 32 00 a1 3e 10 2d
"x"      ff aa 01 01 50 00 00 00 78 01 63 64 40 05 ff ff fd e7 4c 64 c8 01 c2 78 20 ce 64 c8 63 c8 66 28 66 00 8a 32 56 c0 15 02 79 20 11 38 1f c6 60 04 32 00 a1 64 10 2e
"y"      ff aa 01 01 50 00 00 00 78 01 63 64 40 05 ff ff fd e7 4c 64 c8 01 c2 78 20 ce 64 c8 63 c8 66 28 66 00 8a 32 56 c2 15 02 79 20 11 38 1f c6 60 04 32 00 a1 8a 10 2f
"z"      ff aa 01 01 50 00 00 00 78 01 63 64 40 05 ff ff fd e7 4c 64 c8 01 c2 78 20 ce 64 c8 63 c8 66 28 66 00 8a 32 56 c1 15 02 79 20 11 38 1f c6 60 04 32 00 a1 b0 10 30
</code>```

Above we have the quoted-contents of the stored query (left) and the BLOB data converted to hex (right).

Most of the contents is unaltered, so let's start by trimming the strings down to strictly the bytes that change:

```<code>"A"     ...   3a c2   ...   99 3a 0f f7
"B"     ...   3a c1   ...   99 60 0f f8
"C"     ...   3a c3   ...   99 86 0f f9
"D"     ...   ba c0   ...   99 ac 0f fa
"E"     ...   ba c2   ...   99 d2 0f fb
"F"     ...   ba c1   ...   99 f8 0f fc
"G"     ...   ba c3   ...   9a 1e 0f fd
"H"     ...   7a c0   ...   9a 44 0f fe
"I"     ...   7a c2   ...   9a 6a 0f ff
"J"     ...   7a c1   ...   9a 90 10 00
"K"     ...   7a c3   ...   9a b6 10 01
"L"     ...   fa c0   ...   9a dc 10 02
"M"     ...   fa c2   ...   9b 02 10 03
"N"     ...   fa c1   ...   9b 28 10 04
"O"     ...   fa c3   ...   9b 4e 10 05
"P"     ...   06 c0   ...   9b 74 10 06
"Q"     ...   06 c2   ...   9b 9a 10 07
"R"     ...   06 c1   ...   9b c0 10 08
"S"     ...   06 c3   ...   9b e6 10 09
"T"     ...   86 c0   ...   9c 0c 10 0a
"U"     ...   86 c2   ...   9c 32 10 0b
"V"     ...   86 c1   ...   9c 58 10 0c
"W"     ...   86 c3   ...   9c 7e 10 0d
"X"     ...   46 c0   ...   9c a4 10 0e
"Y"     ...   46 c2   ...   9c ca 10 0f
"Z"     ...   46 c1   ...   9c f0 10 10
"a"     ...   26 c2   ...   9d fa 10 17
"b"     ...   26 c1   ...   9e 20 10 18
"c"     ...   26 c3   ...   9e 46 10 19
"d"     ...   a6 c0   ...   9e 6c 10 1a
"e"     ...   a6 c2   ...   9e 92 10 1b
"f"     ...   a6 c1   ...   9e b8 10 1c
"g"     ...   a6 c3   ...   9e de 10 1d
"h"     ...   66 c0   ...   9f 04 10 1e
"i"     ...   66 c2   ...   9f 2a 10 1f
"j"     ...   66 c1   ...   9f 50 10 20
"k"     ...   66 c3   ...   9f 76 10 21
"l"     ...   e6 c0   ...   9f 9c 10 22
"m"     ...   e6 c2   ...   9f c2 10 23
"n"     ...   e6 c1   ...   9f e8 10 24
"o"     ...   e6 c3   ...   a0 0e 10 25
"p"     ...   16 c0   ...   a0 34 10 26
"q"     ...   16 c2   ...   a0 5a 10 27
"r"     ...   16 c1   ...   a0 80 10 28
"s"     ...   16 c3   ...   a0 a6 10 29
"t"     ...   96 c0   ...   a0 cc 10 2a
"u"     ...   96 c2   ...   a0 f2 10 2b
"v"     ...   96 c1   ...   a1 18 10 2c
"w"     ...   96 c3   ...   a1 3e 10 2d
"x"     ...   56 c0   ...   a1 64 10 2e
"y"     ...   56 c2   ...   a1 8a 10 2f
"z"     ...   56 c1   ...   a1 b0 10 30
</code>```

Even though this is a fairly large sample of characters (though of course not all 256 ASCII characters) I can't really see a pattern between any of the rows.

Another way to look at the data:

```<code>"A"     ...   3a c2   ...   99 3a 0f f7    |    "a"     ...   26 c2   ...   9d fa 10 17
"B"     ...   3a c1   ...   99 60 0f f8    |    "b"     ...   26 c1   ...   9e 20 10 18
"C"     ...   3a c3   ...   99 86 0f f9    |    "c"     ...   26 c3   ...   9e 46 10 19
"D"     ...   ba c0   ...   99 ac 0f fa    |    "d"     ...   a6 c0   ...   9e 6c 10 1a
"E"     ...   ba c2   ...   99 d2 0f fb    |    "e"     ...   a6 c2   ...   9e 92 10 1b
"F"     ...   ba c1   ...   99 f8 0f fc    |    "f"     ...   a6 c1   ...   9e b8 10 1c
"G"     ...   ba c3   ...   9a 1e 0f fd    |    "g"     ...   a6 c3   ...   9e de 10 1d
"H"     ...   7a c0   ...   9a 44 0f fe    |    "h"     ...   66 c0   ...   9f 04 10 1e
"I"     ...   7a c2   ...   9a 6a 0f ff    |    "i"     ...   66 c2   ...   9f 2a 10 1f
"J"     ...   7a c1   ...   9a 90 10 00    |    "j"     ...   66 c1   ...   9f 50 10 20
"K"     ...   7a c3   ...   9a b6 10 01    |    "k"     ...   66 c3   ...   9f 76 10 21
"L"     ...   fa c0   ...   9a dc 10 02    |    "l"     ...   e6 c0   ...   9f 9c 10 22
"M"     ...   fa c2   ...   9b 02 10 03    |    "m"     ...   e6 c2   ...   9f c2 10 23
"N"     ...   fa c1   ...   9b 28 10 04    |    "n"     ...   e6 c1   ...   9f e8 10 24
"O"     ...   fa c3   ...   9b 4e 10 05    |    "o"     ...   e6 c3   ...   a0 0e 10 25
"P"     ...   06 c0   ...   9b 74 10 06    |    "p"     ...   16 c0   ...   a0 34 10 26
"Q"     ...   06 c2   ...   9b 9a 10 07    |    "q"     ...   16 c2   ...   a0 5a 10 27
"R"     ...   06 c1   ...   9b c0 10 08    |    "r"     ...   16 c1   ...   a0 80 10 28
"S"     ...   06 c3   ...   9b e6 10 09    |    "s"     ...   16 c3   ...   a0 a6 10 29
"T"     ...   86 c0   ...   9c 0c 10 0a    |    "t"     ...   96 c0   ...   a0 cc 10 2a
"U"     ...   86 c2   ...   9c 32 10 0b    |    "u"     ...   96 c2   ...   a0 f2 10 2b
"V"     ...   86 c1   ...   9c 58 10 0c    |    "v"     ...   96 c1   ...   a1 18 10 2c
"W"     ...   86 c3   ...   9c 7e 10 0d    |    "w"     ...   96 c3   ...   a1 3e 10 2d
"X"     ...   46 c0   ...   9c a4 10 0e    |    "x"     ...   56 c0   ...   a1 64 10 2e
"Y"     ...   46 c2   ...   9c ca 10 0f    |    "y"     ...   56 c2   ...   a1 8a 10 2f
"Z"     ...   46 c1   ...   9c f0 10 10    |    "z"     ...   56 c1   ...   a1 b0 10 30
</code>```

Interestingly the 2nd byte of the first altering section appears to be consistent across all A-Z and a-z. The 1st byte however only shares a moderate pattern though P-Z and p-z.

The final altering sections seem almost like completely arbitrary characters. Perhaps one part is a key and the other part is an encoded/encrypted character?

I also briefly took a look at the following:

```<code>"a"     ...   26 c2 15 02 79 20 11         ...   9d fa 10 17
"aa"    ...   25 32 24 c2 95 02 f9 20 31   ...   c0 c5 10 79
</code>```

And that's where I stopped researching... I am yet to spot the pattern which links all this data together. I can't help but feel there is an easier way to solve this mystery but I currently just lack the knowledge to obtain the answer.

Can anyone suggest a better method of cracking this code?

What data will I need to crack the code? Fortunately I can just mass produce this data...


问:
IDA does not follow relative jump, executable patching
I created small C program (x86) with this asm code inside main:

```<code>__asm
{
    jmp label       // EB 02
    nop             // 90
    nop             // 90
}
label:
</code>```

Loaded it in IDA (in static mode, so it will use preferred base address), looked for address of jmp label and subtracted virtual address of code section (can be quickly seen in PE explorer). Then I found file offset in executable and patched it, so EB 02 90 90 code sequence became relative unconditional jump 66 E9 <16bit offset to program entry point>.

Note that I am not trying to do something, I just wanted to see how IDA will respond. IDA recognizes the address:

```<code>jmp short start
</code>```

I put breakpoint on first instruction from entry point, once it got hit I resume. To my surprise IDA seems to loose track of instruction pointer (or jumps to different location) and some weird things happen.

At first I tried relative jump outside code section, IDA behaved the same way and I thought it might be something about checking boundaries of code section. But technically we can execute code outside of code section, all we need to do is just put code bytes in global array, manually mark section that contains initialized data as executable and use relative jumps.

I read that IDA does not handle obfuscated binaries. Has it something to do with it? Can someone explain why IDA refuses to follow control flow in this case? Thanks.


问:
Problems calculating checksum for AirConditioner
I am trying to reverse engineer an AC Indoor unit <-> thermostat communication. So far I've succeeded in parsing the bits and bytes.

I discovered that the upper and lower nibbles need to be reversed to get consecutive values for temperature values, for example, so I assume that part is correct.

Also, the unit sends the payload twice, so I assume the values are correct.

Finally, I am trying to calculate the checksum of the received values, but I cannot find a pattern that results in a matching checksum.

I did notice that value change of 0x01 raises the checksum by 0x10, so I tried reversing each value and sum them up, but that did not provide the expected result. On the other hand, changing 0x10 to 0x30 does not affect the checksum at all.

Here some of the received bytes (received twice like this):

```<code>vent hex: 09 da d1 04 01 00 44 13 a4 09 00 40 10 04 01 1d

cool hex: 09 d8 d1 04 01 00 40 17 a4 09 00 40 10 04 01 6a

ai   hex: 09 de d1 04 01 01 40 17 a4 09 00 40 10 04 01 7c

dehumhex: 09 dc d1 04 01 00 40 15 24 09 00 40 10 04 01 5a

heat hex: 09 d9 d1 04 01 01 40 17 a4 f1 00 40 10 04 01 4c

hex: 2a d7 10 04 01 00 40 10 04 01 00 48 14 7c 09 78 1=0001

hex: 2a d7 30 04 01 00 40 10 04 01 00 48 14 7c 09 78 3=0011

hex: 2a d7 50 04 01 00 40 10 04 01 00 48 14 7c 09 79 5=0101

hex: 2a d7 70 04 01 00 40 10 04 01 00 48 14 7c 09 79 7=0111

hex: 2a d7 90 04 01 00 40 10 04 01 00 48 14 7c 09 7a 9=1001

hex: 2a d7 b0 04 01 00 40 10 04 01 00 48 14 7c 09 7a B=1011

hex: 2a d7 d0 04 01 00 40 10 04 01 00 48 14 7c 09 7b D=1101

hex: 2a d7 f0 04 01 00 40 10 04 01 00 48 14 7c 09 7b F=1111

hex: 2a d6 10 04 01 00 40 10 04 01 00 48 14 7c 09 7c

hex: 2a d6 30 04 01 00 40 10 04 01 00 48 14 7c 09 7c

hex: 2a d6 70 04 01 00 40 10 04 01 00 48 14 7c 09 7d

hex: 2a d6 50 04 01 00 40 10 04 01 00 48 14 7c 09 7d

hex: 2a d6 b0 04 01 00 40 10 04 01 00 48 14 7c 09 7e

hex: 2a d6 d0 04 01 00 40 10 04 01 00 48 14 7c 09 7f

hex: 2a d6 f0 04 01 00 40 10 04 01 00 48 14 7c 09 7f
</code>```

Here is some parsed output of a temperature decrease with the reversed payload(rhex):

```<code>source: 09  head 110 mode 38 modeb 11001 fan 0 bfan: 000 unkownb: 1000

swing: 4 bswing 00000100

plasma 1 tempStart: 0001 temp: 90 tempStop: 010 airclean 1

unkown: 01 01 44  splayload: e9  rest: 00 40 10 04 01  chksum: 2a

hex: 09 d9 11 04 01 01 44 15 a5 e9 00 40 10 04 01 2a

rhex 90 9b 88 20 80 80 22 a8 a5 97 00 02 08 20 80 54

source: 09  head 110 mode 38 modeb 11001 fan 0 bfan: 000 unkownb: 1000

swing: 4 bswing 00000100

plasma 1 tempStart: 0001 temp: 88 tempStop: 010 airclean 1

unkown: 01 01 44  splayload: e9  rest: 00 40 10 04 01  chksum: 6a

hex: 09 d9 11 04 01 01 44 11 a5 e9 00 40 10 04 01 6a

rhex 90 9b 88 20 80 80 22 88 a5 97 00 02 08 20 80 56
</code>```

Maybe somebody can give me a hint in the right direction.

The test setup is running in Python on a Raspberry Pi.

ContentLicense: CC BY-SA 4.0