I'm trying to read the LoginItems preferences file to change a Network Volume a user has in their login items. Which mounts when they log in.
I can read the login items using NSUserDefaults and getting it as an NSDictionary. The problem is that the volume mount details are stored as binary data. The data appears to be an Alias file format except it's missing the header: 62 6F 6F 6B 00 00 00 00 6D 61 72 6B 00 00 00 00
I've tried using the current NSURL resourceValuesForKeys:fromBookmarkData: but it did not return the remote share. I realised that the machine they were created on is a 10.6 machine and these calls were only made available in 10.11.
So I tried using the old deprecated Core Carbon libraries PTRToHand and FSCopyAliasInfo to get information out of this file but all it says is that it is an Alias pointing to /Volumes/ShareMount and makes no mention of which server it is trying to connect to.
The binary data does show the string smb mount for the server.
0000000: 0000 0000 00a0 0003 0001 0000 0000 0000 ................
0000010: 0000 4244 6375 0001 ffff ffff ffff ffff ..BDcu..........
0000020: 0000 0000 0000 0000 0000 1201 fffe 0000 ................
0000030: 0000 0000 0000 ffff ffff 000e 000a 0004 ................
0000040: 006d 0061 0072 006b 000f 000a 0004 006d .m.a.r.k.......m
0000050: 0061 0072 006b 0012 0000 0013 000d 2f56 .a.r.k......../V
0000060: 6f6c 756d 6573 2f6d 6172 6b00 0009 002b olumes/mark....+
0000070: 002b 6369 6673 0000 0100 0000 736d 623a .+cifs......smb:
0000080: 2f2f 6d61 726b 4031 302e 3130 312e 3232 //mark#10.101.22
0000090: 322e 3138 352f 6d61 726b 0000 ffff 0000 2.185/mark......
I've compared this data with the wikipedia article on Macos Aliases and a python module that reads aliases both of them spcify the version number should be 2, however the byte in this position (byte 6) is 3, after this byte the binary compatibility between the two no longer match.
Does anyone know about this Version 3 Alias format?
I've found two web pages that seem to document the exact same problem I'm having;
One only available via wayback: Reversing Mac Alias v3 Data Objects He has only parsed 1 file here and an SMB mount one is slightly different.
Apple's Bookmark Data Exposed Pretty much describes the steps that I have followed myself to end up asking this question.
Thanks
Related
Newb-question here. I have searched a couple days for the solution but dont't get anywhere. Using windbg preview.
There's a process that loads a dll and I want to see the disassembly of the addresses that are called from inside the dll. No symbols available because it is third party. I can find the entry point and break on it but after that I cannot step into the dll. I know I need to load the dll into windbg but I can't put it in the arguments when I start the exe because I only know the entry point after the module is loaded.
If I use .load on my dll and set a breakpoint on entry it doesn't work either.
Anyone done this before and can tell me what I need to do to step into the dll's assembly?
edit:
In windbg I launched the executable (.exe) and want to see the addresses and operations inside a .dll that are called during a specific operation in the program.
Simple things first: .load is for loading WinDbg Plugins into the WinDbg process. That's not what you want.
I'm assuming that you want to do more a reverse engineering than debugging. WinDbg is not ideal for this task. There are certainly better tools like IDA.
Analyzing without executing
But anyway, let's get into it. I'll choose an arbitrary DLL for this example. It is a DLL provided with the AMD display driver, C:\AMD\PSP Driver\WTx64\amdtee_api32.dll and I have no clue about it.
Open WinDbg Preview
Go to "Open dump file" (this is not really intuitive, but it will work)
In the file open dialog, enter *, so DLLs will be displayed (by default it's limited to DMP files)
Choose the DLL to be loaded
At this point, it will say
Microsoft (R) Windows Debugger Version 10.0.21349.1004 AMD64
Copyright (c) Microsoft Corporation. All rights reserved.
Loading Dump File [C:\AMD\PSP Driver\WTx64\amdtee_api32.dll]
You can now operate on the DLL with the same commands as during a live debugging session.
0:000> lm
start end module name
10000000 10055000 amdtee_api32 (export symbols) amdtee_api32.dll
So I have no PDB file available, just export symbols, as there are:
0:000> x *!*
7ffe0300 SharedUserData!SystemCallStub = <no type information>
10001050 amdtee_api32!TEEC_InitializeContext (<no parameter info>)
[...]
And we can disassemble a function:
0:000> uf amdtee_api32!TEEC_InitializeContext
amdtee_api32!TEEC_InitializeContext:
10001050 55 push ebp
10001051 8bec mov ebp,esp
10001053 83ec08 sub esp,8
10001056 c745f801000000 mov dword ptr [ebp-8],1
1000105d 837d0c00 cmp dword ptr [ebp+0Ch],0
10001061 750a jne amdtee_api32!TEEC_InitializeContext+0x1d (1000106d) Branch
[...]
You can even access the memory where the DLL is loaded to
0:000> db amdtee_api32
10000000 4d 5a 90 00 03 00 00 00-04 00 00 00 ff ff 00 00 MZ..............
10000010 b8 00 00 00 00 00 00 00-40 00 00 00 00 00 00 00 ........#.......
10000020 00 00 00 00 00 00 00 00-00 00 00 00 00 00 00 00 ................
10000030 00 00 00 00 00 00 00 00-00 00 00 00 10 01 00 00 ................
10000040 0e 1f ba 0e 00 b4 09 cd-21 b8 01 4c cd 21 54 68 ........!..L.!Th
10000050 69 73 20 70 72 6f 67 72-61 6d 20 63 61 6e 6e 6f is program canno
10000060 74 20 62 65 20 72 75 6e-20 69 6e 20 44 4f 53 20 t be run in DOS
10000070 6d 6f 64 65 2e 0d 0d 0a-24 00 00 00 00 00 00 00 mode....$.......
I'd like to replace the first stage bootloader in the nand flash on a sama5d36 based system running 4.1.0-linux4sam_5.1 and buildroot-2016.02.
I can replace the kernel image with flashcp just fine, but when I try it with the bootloader, flashcp runs without errors, but the system doesn't boot afterwards, stays at the ROMBOOT prompt.
buildroot:~# flashcp -v at91bootstrap.bin /dev/mtd0
Erasing block: 1/1 (100%)
Writing kb: 14/14 (100%)
Verifying kb: 14/14 (100%)
buildroot:~# reboot
[...]
Sent SIGKILL to all processes
Requesting system reboot
�RomBOOTRestarting system
Then I can write the same bootloader image with sam-ba, and it will boot, so the image is good. How can it be flashed in Linux, without user intervention?
There should be a 208 byte header preceding the actual boot code at the beginning of the flash.
From the SAMA5D3 Datasheet (that I should have read before posting the question)
After Initialization and Reset command, the Boot Program reads the first page without an ECC check, to determine if the NAND parameter header is present. The header is made of 52 times the same 32-bit word (for redundancy reasons) which must contain NAND and
PMECC parameters used to correctly perform the read of the rest of the data in the NAND.
The header is of course there when I dump the contents of the boot sector
buildroot:~# hd < /dev/mtd0 | head -4
00000000 05 24 90 c0 05 24 90 c0 05 24 90 c0 05 24 90 c0 |.$...$...$...$..|
*
000000d0 0e 00 00 ea 05 00 00 ea 05 00 00 ea 05 00 00 ea |................|
000000e0 05 00 00 ea cc 3b 00 00 06 00 00 ea 06 00 00 ea |.....;..........|
the first four bytes are repeated over and over, and the ARM jump table begins at offset 0xD0 (=208=52 * 4)
sam-ba takes care of this header when it writes the boot sector, but the Linux mtd driver and flashcp treats it as ordinary data, so I should supply it.
I am extracting macOS sierra update package - macOSUpd10.12.1.pkg using following command to /tmp/macosupd directory.
pkgutil --expand /Volumes/macOS\ Sierra\ Update/macOSUpd10.12.1.pkg /tmp/macosupd
I can see following packages are bundled inside the metapackage.
-rwxr-xr-x 1 Distribution
drwxr-xr-x 6 FirmwareUpdate.pkg
drwxr-xr-x 5 FullBundleUpdate.pkg
drwxr-xr-x 36 Resources
drwxr-xr-x 6 macOSUpd10.12.1.pkg
I am not able to extract contents of Payload file. For example when i try to extract the Payload of macOSUpd10.12.1.pkg, i get following error message:
with tar:
tar -xvf macOSUpd10.12.1.pkg/Payload
tar: Unrecognized archive format
tar: Error exit delayed from previous errors.
with xar:
xar -xvf macOSUpd10.12.1.pkg/Payload
Error opening xar archive: macOSUpd10.12.1.pkg/Payload
When I run file command on the payload file, i get a message as:
file macOSUpd10.12.1.pkg/Payload
macOSUpd10.12.1.pkg/Payload: data
By seeing initial bits of Payload file using xxd command , i can see file type looks like pbzx
xxd macOSUpd10.12.1.pkg/Payload
00000000: 7062 7a78 0000 0000 0100 0000 0000 0000 pbzx............
00000010: 0100 0000 0000 0000 0031 0330 fd37 7a58 .........1.0.7zX
00000020: 5a00 0000 ff12 d941 04c0 f385 c401 8080 Z......A........
00000030: 8008 2101 1600 0000 506a 84e2 e3b8 13ef ..!.....Pj......
00000040: fe5d 0018 0ddf 07a4 347c 7c50 9853 8031 .]......4||P.S.1
00000050: 2d14 f703 6903 cf69 f214 76b0 93c0 a4c9 -...i..i..v.....
00000060: 774d 6fb0 8b3a 2257 4a55 04ad 289b cc4d wMo..:"WJU..(..M
00000070: b835 5db7 7e72 f7a8 dc15 7a9c 7755 800c .5].~r....z.wU..
00000080: 6060 d45f e078 f84f e537 4319 2d89 f72e ``._.x.O.7C.-...
00000090: 60c4 cdb0 6b54 9326 9321 3339 4a4f 1e75 `...kT.&.!39JO.u
000000a0: 8eb7 991d 8968 5e6f 45d4 24c9 e364 712b .....h^oE.$..dq+
000000b0: ef4e 9abc af70 e97a e5a3 1810 7f05 54df .N...p.z......T.
000000c0: 08d2 3060 9f8a a1e0 edb8 2b10 df23 789d ..0`......+..#x.
000000d0: 3e52 ee3e d6f0 468a bfee 3366 d39e 28db >R.>..F...3f..(.
Please suggest a way on how to extract the contents of Payload file. I have tried all he methods suggested in link1 and link2, including the method suggested in this external-link still no success. Seems like apple updates prior to Mavericks were pure xar and tar packages. With Mavericks and above apple changed the file format from a tar to pbzx(lzma).
please suggest an easy command line way to extract contents of the Payload file as i have to make use in my automation setup.
There is an undocumented option to pkgutil, --expand-full, which uses the same syntax as pkgutil --expand.
pkgutil --expand-full [pkg] [dir]
This will completely "unarchive" a pkg or mpkg file.
Since OSX 10.10, the Payload in the .pkg files is encoded as pbzx (which is in turn lzma compressed). It can no longer be extracted using gunzip. Check out the pbzx tool (a fork of the original which would not allow you to extract the Payload directly but only by passing the .pkg file directly).
Instead of
tar -xvf macOSUpd10.12.1.pkg/Payload
you can write
pbzx -n macOSUpd10.12.1.pkg/Payload | cpio -i
I have a certain file structure like this
>ID1
data about ID1....
................
................
>ID2
data about ID2....
................
................
................
................
>ID3
data about ID3....
................
................
...............
>ID1
data about ID1....
................
>ID5
data about ID5....
................
................
I want to remove these duplicate blocks of IDs. For eg in the above case it is ID1. It should be noted that only the ID part is same, the data after that could be different. However, I want to keep the first one and remove all the other ones. How can I do this in shell scripting manner?
In awk
awk '/^>/{p=!($0 in a);a[$0]}p' file1
I am using dtruss on MacOS X 10.8.5 in an attempt to see the conversation between a running application and an SSL server it talks to. Unlike strace on Linux, I'm not seeing full strings of data in the output, like I would expect to find as the program does send and recv on the file descriptor.
How can I get dtruss to show me the data which the app is sending and receiving with the SSL server?
Before anyone tells me to proxy the connections to an SSL server I control, yes I know this trick, and no this particular app is too smart to fall for it.
dtruss is both an elegant example of a script written for DTrace and a demonstration of what DTrace can accomplish. However, although its similarity to truss or strace is deeply welcome on the relatively barren OS X, I suspect that dtruss was never intended to be a complete substitute for either.
In any case, your question is a bit ambiguous: I'm not sure whether you are concerned that the strings that you see are truncated or that you don't see any strings at all for sendto() or recvfrom() (the underlying interfaces revealed by DTrace). I'll address both.
Firstly, DTrace collects data in the kernel; user-land buffers are obtained with the D language's copyin() or copyinstr() before being recorded and transmitted back to the consumer --- typically the dtrace(1) command. DTrace requires that its kernel buffer size be known at compile-time and therefore imposes a limit on the otherwise unpredictable length of a string. This limit is 256 bytes by default; if you are seeing truncation then you could change the limit by adding, e.g.,
#pragma D option strsize=512
below dtruss's existing pragma.
Secondly, dtruss is hard-coded to know about the formatting requirements of a variety of system calls. You don't see any buffer interpretation for sendto() or recvfrom() in its output because they're not handled explicitly in the source. There's nothing to stop you finding somewhere suitable to add them but you could instead write your own script:
bash-3.2# cat sr.d
#pragma D option rawbytes
syscall::sendto:entry,
syscall::recvfrom:entry
/pid == $target/
{
self->bufp = arg1;
self->size = arg2;
}
syscall::sendto:return,
syscall::recvfrom:return
/pid == $target && self->bufp && self->size/
{
printf("%s():\n", probefunc);
tracemem(copyin(self->bufp, self->size), 64);
printf("\n");
self->bufp = self->size = NULL;
}
bash-3.2# dtrace -qs ./sr.d -p 16988
sendto():
0 1 2 3 4 5 6 7 8 9 a b c d e f 0123456789abcdef
0: 68 65 6c 6c 6f 00 00 00 00 00 00 00 00 00 00 00 hello...........
10: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................
20: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................
30: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................
^C
bash-3.2#
Note that, as for strings, we're obliged to provide a hard limit on tracemem()'s use of DTrace's data-recording buffer. If the limit is rarely approached then this has the irritating result that the output can be overwhelming and mostly redundant. If you know that you're looking for strings then you could simply use copyinstr() instead; if you have a more modern DTrace implementation than my OS X 10.6.8 then you may find that you can write
tracemem(copyin(self->bufp, self->size), 64, self->size);
where the second argument is still a hard limit on the number of bytes recorded but the number of bytes displayed is limited by the optional third argument.
Finally, note that the user-land address is recorded on entry to the system call but used only on exit. This is a common idiom that allows the system call to fault-in the data if necessary --- DTrace won't do so itself and will produce an error at run-time if asked to trace a non-resident address.