lldb read memory pointer - memory

It is possible to easily read a memory at a location pointed to by a another address.
For example, $r0 = 0x15942600 at this memory address there is AC B8 EC 14
Now to read the memory at 0x14ecb8ac, I will have to do:
mem read $r0
mem read 0x14ecb8ac
Any way to easily do a mem read ($r0) such that I can read the memory easily?
I have tried this:
(lldb) mem re $r1
0x007db594: 7c d5 e7 15 00 00 00 00 e4 b5 7d 00 70 f6 9a 36
(lldb) mem read 0x15e7d57c
0x15e7d57c: 74 69 63 72 63 74 37 35 00 00 63 61 00 00 49 39
(lldb) mem read '*(char **)$r1'
error: invalid start address expression.
error: address expression "*(char **)$r1" evaluation failed

Thanks to #MarkPlotnick this works,
mem read '*(int **)$r1'
If you need to read a mem address at a certain offset, the following can be done,
mem read '*(int **)($r1+4)'
Tried and tested against Xcode debugging against ARMv7 and ARM64

Related

Unable to get the correct CRC16 with a given Polynomial

I'm struggling with an old radiation sensor and his communication protocol.
The sensor is event driven, the master starts the communication with a data transmission or a data request.
Each data telegram uses a CRC16 to check only the variable data block and a CRC8 to check all the telegram.
My main problem is the crc16, According to the datasheet the poly used to check the data block is: CRC16 = X^14 + X^12 + X^5 + 1 --> 0x5021 ??
I captured some data with a valid CRC16 and tried to replicate the expected value in order to send my own data transmission, but I can't get the same value.
I'm using the sunshine CRC calculator trying any possible combination with that poly.
I also try CRC Reveng but no results.
Here are a few data with the correct CRC16:.
Data | CRC16 (MSB LSB)
14 00 00 0A | 1B 84
15 00 00 0C | 15 88
16 00 00 18 | 08 1D
00 00 00 00 | 00 00
00 00 00 01 | 19 D8
00 00 00 02 | 33 B0
01 00 00 00 | 5A DC
08 00 00 00 | c6 c2
10 00 00 00 | 85 95
80 00 00 00 | 0C EC
ff ff ff ff | f3 99
If I send an invalid CRC16 in the telegram, the sensor send a negative acknowledge with the expected value, so I can try any data in order to test or get more examples if needed.
if useful, the sensor uses a 8bit 8051 microprocessor, and this is an example of a valid CRC8 checked with sunshine CRC:
CRC8 = X^8 + X^6 + X^3 + 1 --> 0x49
Input reflected Result reflected
control byte | Data |CRC16 | CRC8
01 0E 01 00 24 2A 06 ff ff ff ff f3 99 |-> 0F
Any help is appreciated !
Looks like a typo on the polynomial. An n-bit CRC polynomial always starts with xn. Like your correct 8-bit polynomial. The 16-bit polynomial should read X16 + X12 + X5 + 1, which in fact is a very common 16-bit CRC polynomial.
To preserve the note in the comment, the four data bytes in the examples are swapped in each pair of bytes, which needs to be undone to get the correct CRC. (The control bytes in the CRC8 example are not swapped.)
So 14 00 00 0a becomes 00 14 0a 00, for which the above-described CRC gives the expected 0x1b84.
I would guess that the CRC is stored in the stream also swapped, so the message as bytes would be 00 14 0a 00 84 1b. That results in a sequence whose total CRC is 0.

What is the Delphi unit hashcode used for?

Portable executables compiled using Delphi have a PACKAGEINFO resource that lists the units the program requires & contains.
Documentation of the structure can be found in this version of SysUtils.pas, which shows each TUnitName entry is:
One byte containing flags.
One byte which is a hash code.
The name of the unit, as a null terminated string.
An example can be seen in the PACKAGEINFO structure below:
00000000 00 00 10 cc 00 00 00 00 81 00 00 00 01 59 46 6f |...Ì.........YFo|
00000010 72 6d 31 33 00 10 6d 62 73 55 74 69 6c 73 00 10 |rm13..mbsUtils..|
00000020 55 54 79 70 65 73 00 00 81 53 79 73 49 6e 69 74 |UTypes...SysInit|
The first unit defined (after the header) is named YForm13 with a hash code of 0x59. The second is bsUtils with a hash code of 0x6D.
A comparison between different Delphi compiled executables shows that units like SysInit and System seem to have the same hash code across two files, but this is not a large study.
What is this hash code used for? Can it be correlated to other parts of the compiled executable?
The hash code is used to check whether or not the units are good and can be loaded. Inspecting the code, it is used at runtime and not at compile time.
The part is not documented, however you may inspect the VCL Source code (which cannot be posted here): unit System.SysUtils, look for InternalUnitCheck.
The module name will is used as a part of the hash, and the unit name is used as the last part.

I9300 sboot.bin 256-Byte signatures, or checksum?

Some time ago I started trying to mod my Samsung Galaxy S3 (International edition (I9300)), and I ended up with the Bootlogo, this is the FIRST image that you see when you turn on the Galaxy S3. I wanted to change it, as it is quite easy on other devices.
This is where I ran into troubles, I asked around on XDA-developes [link 1] (http://forum.xda-developers.com/galaxy-s3/help/removal-bootlogo-t2662444) and [link 2] (http://forum.xda-developers.com/showthread.php?t=2317694) but most of the answers led me nowhere. I ended up with the sboot.bin which is the secondary boot program (I guess this is how you can call it). To open it was quite difficult for a noob like me, but with hexadecimal editor HxD I opened it and actually found the bootlogo! (I copied the bytes into a jpg and it showed up normally.) I changed the bytes with another jpg image I made myself, and tried to flash it to the phone, but it failed. everything I tried afterwards failed, and I wondered why.
I downloaded a couple of sboot.bin for the i9300, but different countries, and I compared the hex code. There seemed to be subtle changes: one was in the compile date and serie nr. And there rest was a jumble of random character 256 bytes long.
I found that there are 4 sequences of 256 bytes long throughout the sboot.bin. An example of one:
EA E9 0C 62 B0 E0 68 86 5A 7B BD CA 50 3D 21 02
17 2C AC 10 09 49 62 E1 DA EB F4 94 B6 74 68 15
E6 90 2F CA 2F 75 67 C6 34 AE A3 A0 8F BC 60 62
63 87 8C C4 6C 8A 39 AA 7C 8A C7 E1 14 A3 C1 37
51 43 85 C0 09 97 05 AF 32 86 32 8C 58 7D C1 8F
91 A1 5E F1 9F D7 24 DF 08 82 1B AD FA C7 72 24
BC 35 34 6F 0F 42 C9 4E 7F AB FC 72 BC 64 71 84
DC 30 BB D5 AD D4 DE 01 9A E9 FB AA 1F 69 6F 52
3D E9 2A 52 6B 7E 9B 79 DE BD 7C 55 31 51 D6 99
BE 74 4F 22 6F 23 2F BF 7A 81 EF 5B 20 BF 75 03
D3 84 61 37 81 50 ED 71 66 4F 3D 34 0E 5A 33 4D
86 E2 E7 D0 8F 2B 48 5E 85 B5 E6 3F 56 51 70 74
CE 87 52 2D 47 D0 39 F6 CD 50 EE 76 F4 8E 79 7C
90 CF 4C 07 D5 47 AF 86 3D 33 3B A1 2A 70 74 4F
D1 60 9F 9E 28 96 C9 6E 9D DA 12 CB E1 8C 5B A5
CA AC 84 E2 26 1E 6F FD 4E EE B8 53 6E 7B 30 19
Maybe because it is helpful: one block is somewhat in the beginning, one is almost in the end, and the last two are at the real end of the file. So maybe the last two blocks are actually one big 512 byte block...
So I have come as far as to think that it might be a checksum or signature. But I am not sure how to find out what kind it is and how to generate one my self. searching for it hasn't helped me, because I cannot seem to find anything this long (256 bytes) only 256 bits long...
I was wondering if maybe someone could see what kind of siganture/checksum this is (Is this possible?) or how I can find out myself. or what I should do next...
[Edit on 25-08]
Alright, Since nobody has been able to answer the question yet, I was thinking of offering an incentive. I am willing to pay 1000 USD to whoever can help me alter the BOOTLOGO of the I9300!!!
Frank
Bootlogo is in the tar package /PARAMS and is called as logo.jpg, it should be writable via adb shell in twrp with this command:
cat /dev/block/platform/sdio_mmc/by-name/PARAMS > /sdcard/PARAMS.tar
Please note that PARAMS partition has stored SBOOT params at the end of the file. Just count 512 bytes from the last one, this is the last param, 512 bytes above is the next, until end of tar package.
Seems to be a checksum, though I cant be sure. One thing is certain, you've gone extremely deep in stuff. It could help to ask the guys at samsung, or somebody with great knowledge of kernels.
The first and second bootloader are signed.
A first bootloader that don't check the signatures of the second bootloader exist, so if you install that, you can then use u-boot as second bootloader.
See https://blog.forkwhiletrue.me/posts/an-almost-fully-libre-galaxy-s3/ for more details.

Delphi 7 turn off creation of DDP files

How do you turn off the feature or stop the creation of all the .ddp files for your Delphi 7 forms? I read something about removing the designdgm60.bpl, but is that the only way? It seems that there was another way I can't remember any longer.
Update: I tried renaming the designdgm70.bpl and that just creates a ton of program errors.
Also, I'm using Delphi 7.2 on one computer and there is no design tab I can see unless its covered by something in CnWizards. 7.2 definitely creates the ddp files though.
DDP files are for Delphi diagrams (DDP stands for Delphi Diagram Portfolio) in Delphi 6-7. Delphi 5 used the DTI extension for this.
DDP files can have meaningful information. They don't get compiled into .DCU/.EXE./... as they are for documentation purposes only.
Did you create diagrams of components on your form/datamodule? I used to do that (to explain structure to co-workers) so I was actually really happy with the DDP files.
Before deleting them, inspect them to see if they contain documentation you want to keep.
You can safely delete them if they are 51 bytes long and the TDUMP of it looks like this:
000000: 07 18 44 45 4C 50 48 49 2E 44 49 41 47 52 41 4D ..DELPHI.DIAGRAM
000010: 2E 50 4F 52 54 46 4F 4C 49 4F 0F 00 00 E0 40 02 .PORTFOLIO....#.
000020: 01 09 06 09 55 6E 74 69 74 6C 65 64 31 06 00 02 ....Untitled1...
000030: 00 02 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................
I suppose that it's impossible to turn off .ddp creation in IDE by built-in methods, but DDevExtensions tool includes this option (File Cleaner)
You can install DDevExtensions which is free.
There is an option which you can check that automatically deletes .ddp files.

Invalid pointer exception when closing app after upgrade from Delphi 2006 to Delphi XE

I've just upgraded a project from Delphi 2006 to Delphi XE. Everything is working as expected except I get an exception when I close my app.
It's not breaking on a code line. It breaks to the CPU window on a LEAVE command.
I've attached a Eureka log if that is any help.
EurekaLog 6.0.25
Application:
------------------------------------------------------
1.1 Start Date : Fri, 3 Dec 2010 10:44:17 +0100
1.2 Name/Description: LogoTid.exe
1.3 Version Number :
1.4 Parameters :
1.5 Compilation Date: Fri, 3 Dec 2010 10:44:15 +0100
1.6 Up Time : 5 seconds
Exception:
----------------------------------------------------
2.1 Date : Fri, 3 Dec 2010 10:44:22 +0100
2.2 Address : 004062A0
2.3 Module Name : LogoTid.exe
2.4 Module Version:
2.5 Type : EInvalidPointer
2.6 Message : Invalid pointer operation.
2.7 ID : 5E21
2.8 Count : 1
2.9 Status : New
2.10 Note :
User:
-------------------------------------------------------
3.1 ID : oda
3.2 Name :
3.3 Email :
3.4 Company :
3.5 Privileges: SeIncreaseQuotaPrivilege - OFF
SeSecurityPrivilege - OFF
SeTakeOwnershipPrivilege - OFF
SeLoadDriverPrivilege - OFF
SeSystemProfilePrivilege - OFF
SeSystemtimePrivilege - OFF
SeProfileSingleProcessPrivilege - OFF
SeIncreaseBasePriorityPrivilege - OFF
SeCreatePagefilePrivilege - OFF
SeBackupPrivilege - OFF
SeRestorePrivilege - OFF
SeShutdownPrivilege - OFF
SeDebugPrivilege - ON
SeSystemEnvironmentPrivilege - OFF
SeChangeNotifyPrivilege - ON
SeRemoteShutdownPrivilege - OFF
SeUndockPrivilege - OFF
SeManageVolumePrivilege - OFF
SeImpersonatePrivilege - ON
SeCreateGlobalPrivilege - ON
SeIncreaseWorkingSetPrivilege - OFF
SeTimeZonePrivilege - OFF
SeCreateSymbolicLinkPrivilege - OFF
Active Controls:
------------------------------------------------------------------
4.1 Form Class : TAppBuilder
4.2 Form Text : LogoTid - Delphi XE - uMain [Running] [Built]
4.3 Control Class:
4.4 Control Text :
Computer:
------------------------------------------------------------------------------------------------
5.1 Name : OLE-LAPTOP
5.2 Total Memory : 3891 Mb
5.3 Free Memory : 778 Mb
5.4 Total Disk : 120 Gb
5.5 Free Disk : 57,93 Gb
5.6 System Up Time: 1 day, 23 hours, 16 minutes, 56 seconds
5.7 Processor : Intel(R) Core(TM) i5 CPU M 520 # 2.40GHz
5.8 Display Mode : 1920 x 1200, 32 bit
5.9 Display DPI : 96
5.10 Video Card : Intel(R) Graphics Media Accelerator HD (driver 8.15.10.2025 - RAM 1721 MB)
5.11 Printer : RICOH Aficio 2232C RPCS (driver 1.0.0)
Operating System:
--------------------------------------------
6.1 Type : Microsoft Windows 7 (64 bit)
6.2 Build # : 7600
6.3 Update :
6.4 Language: Danish
6.5 Charset : 0
Call Stack Information:
-------------------------------------------------------------------
|Address |Module |Unit |Class|Procedure/Method |Line |
-------------------------------------------------------------------
|Running Thread: ID=5632; Priority=0; Class=; [Main] |
|-----------------------------------------------------------------|
|00D171A1|LogoTid.exe |LogoTid.dpr| | |32[5]|
|76A73675|kernel32.dll| | |BaseThreadInitThunk| |
-------------------------------------------------------------------
Assembler Information:
-----------------------------------------------------------------
; System.TObject.FreeInstance
; ----------------------------
00406294 push ebx
00406295 mov ebx, eax
00406297 mov eax, ebx
00406299 call System.TObject.CleanupInstance
0040629E mov eax, ebx
004062A0 call System._FreeMem ; <-- EXCEPTION
004062A5 pop ebx
004062A6 ret
Registers:
-----------------------------
EAX: 02AF8058 EDI: 00000001
EBX: 004062A5 ESI: 004062A5
ECX: 0041D700 ESP: 0018FE98
EDX: 004062A5 EIP: 004062A0
Stack: Memory Dump:
------------------ ---------------------------------------------------------------------------
0018FE98: FFFFFF02 004062A0: E8 3B E7 FF FF 5B C3 90 83 C0 CC 8B 00 C3 8B C0 .;...[..........
0018FE9C: 00404B78 004062B0: 84 D2 74 08 83 C4 F0 E8 54 05 00 00 84 D2 74 0F ..t.....T.....t.
0018FEA0: 02B1CEC0 004062C0: E8 A3 05 00 00 64 8F 05 00 00 00 00 83 C4 0C C3 .....d..........
0018FEA4: 02B1CEC0 004062D0: E8 E3 05 00 00 84 D2 7E 05 E8 82 05 00 00 C3 90 .......~........
0018FEA8: 00404BC2 004062E0: 85 C0 74 07 B2 01 8B 08 FF 51 FC C3 53 56 57 89 ..t......Q..SVW.
0018FEAC: 02B1CEC0 004062F0: C3 89 D7 AB 8B 4B CC 31 C0 51 C1 E9 02 49 F3 AB .....K.1.Q...I..
0018FEB0: 0018FEE8 00406300: 59 83 E1 03 F3 AA 89 D0 89 E2 8B 4B AC 85 C9 74 Y..........K...t
0018FEB4: 004062A5 00406310: 01 51 8B 5B D0 85 DB 74 04 8B 1B EB ED 39 D4 74 .Q.[...t.....9.t
0018FEB8: 03A02F01 00406320: 1D 5B 8B 0B 83 C3 04 8B 73 10 85 F6 74 06 8B 7B .[......s...t..{
0018FEBC: 00406865 00406330: 14 89 34 07 83 C3 1C 49 75 ED 39 D4 75 E3 5F 5E ..4....Iu.9.u._^
0018FEC0: 0045B949 00406340: 5B C3 8B C0 53 56 89 C3 89 C6 8B 36 8B 56 B4 8B [...SV.....6.V..
0018FEC4: 03A02FA0 00406350: 76 D0 85 D2 74 07 E8 85 36 00 00 89 D8 85 F6 75 v...t...6......u
0018FEC8: 03A02F01 00406360: E9 89 D8 E8 78 06 00 00 5E 5B C3 90 87 D1 81 F9 ....x...^[......
0018FECC: 004062EB 00406370: 00 00 00 FF 73 11 81 F9 00 00 00 FE 72 07 0F BF ....s.......r...
0018FED0: 00912606 00406380: C9 03 08 FF 21 FF E1 81 E1 FF FF FF 00 01 C1 89 ....!...........
0018FED4: 00000000 00406390: D0 8B 11 E9 A8 59 00 00 C3 8D 40 00 3B C2 0F 94 .....Y....#.;...
--- Edit
Ok, tried turning of parts of my program until the error went away, and found the troublemaker.
It's my webservice WSDL generated proxy. If I create the proxy object without calling any functions on the service, it throws the error.
I've created a test project without any other code than the proxy object creation and it also throws the error. I've also tried with another webservice, same error. Both webservices was created with Delphi 2006 (.net 1.1).
Lastly I tried with a .net 4.0 webservice created in VS2010. No problems. So either Delphi XE is projects is not compatible with .net 1.1 webservices or Delphi 2006 webservices. Either way it's a mess.
Any thouhts on how to solve this, maybe a workaround?
The log won't help here. It looks like a memory corruption issue, which can happen if your code performs indexed operations on strings (writing to string's character position, for example) and you have not fixed all code where string is casted to PChar or similar code.
In other words, you have to perform careful analysis of your code. Start with turning off some modules and code blocks completely until the exception disappears. Then start adding them one by one.
Likely related to the fact that the string is now a Unicode string (2 bytes per char), and not an AnsiString (1 byte per char). If you play with the raw bytes of strings, this is a major problem. To solve it, simply replace all string to AnsiString and all char to AnsiChar. Of course, you will lose Unicode support by doing this. A better fix is to rework your string handling routines. Often, what is necessary is only to add some multiplicative factors sizeof(char) (=2) every here and there.
Example (old code):
byteSize = length(str);
Example (new code):
byteSize = length(str) * sizeof(char);
Found a solution / workaround.
The error occurs if you use a Webservice directly in a form.
Create an empty vcl forms project, use the wsdl generator to generate a webservice proxy. Include proxy class in uses section. Declare a private object of the proxy, and then in the form create use the proxy class getXXXXXXX function to initiate your object. Run the project.
When you close the form, you get an exception.
The solution / workaround is to create your own class, and talk to the webservice proxy through this class.

Resources