You can see from the pic, I've different output for the same variable folderMetadata.
I'm selecting the method in the functions stack and the pretend the output as always.
What's going on? (I'm in debug mode, just checked).
Update:
NSLog output:
folderMetadata {
AlbumLookup1 = "<e41e5700 f41e5700 e41e5700 c4b25600 e4b05600 e41e5700 241e5700 b4305700 34275700 00000000 00000000 a42c5700 00000000 00000000 00000000>";
AlbumLookup2 = "<141f5700 f41e5700 141f5700 c4b25600 e4b05600 141f5700 241e5700 c4305700 34275700 00000000 00000000 e42c5700 00000000 00000000 00000000>";
Artist = "<84235700 b4205700 a4205700 74df5600 e4b05600 84295700 f4325700 04335700 64275700 00000000 00000000 a4295700 00000000 00000000 00000000>";
one of the sideeffects of the optimization compiler does, hopefully going to be fixed in upcoming Xcode versions
Related
I'm working with elf64 files and i was wondering two things, the first is, in which segment the shstrtable is stored, because reviewing readelf -l doesn't appear. And the other question (coming from the first one) is it possible for a section not be inside a segment?
Also i noticed some 'gaps' between some segments. What is inside those gaps?
I am using the following example, that is an hello_world.c:
readelf -lW hello
El tipo del fichero elf es DYN (Fichero objeto compartido)
Entry point 0x1040
There are 11 program headers, starting at offset 64
Encabezados de Programa:
Tipo Desplaz DirVirt DirFísica TamFich TamMem Opt Alin
PHDR 0x000040 0x0000000000000040 0x0000000000000040 0x000268 0x000268 R 0x8
INTERP 0x0002a8 0x00000000000002a8 0x00000000000002a8 0x00001c 0x00001c R 0x1
[Requesting program interpreter: /lib64/ld-linux-x86-64.so.2]
LOAD 0x000000 0x0000000000000000 0x0000000000000000 0x000560 0x000560 R 0x1000
LOAD 0x001000 0x0000000000001000 0x0000000000001000 0x0001e5 0x0001e5 R E 0x1000
LOAD 0x002000 0x0000000000002000 0x0000000000002000 0x000118 0x000118 R 0x1000
LOAD 0x002de8 0x0000000000003de8 0x0000000000003de8 0x000248 0x000250 RW 0x1000
DYNAMIC 0x002df8 0x0000000000003df8 0x0000000000003df8 0x0001e0 0x0001e0 RW 0x8
NOTE 0x0002c4 0x00000000000002c4 0x00000000000002c4 0x000044 0x000044 R 0x4
GNU_EH_FRAME 0x00200c 0x000000000000200c 0x000000000000200c 0x000034 0x000034 R 0x4
GNU_STACK 0x000000 0x0000000000000000 0x0000000000000000 0x000000 0x000000 RW 0x10
GNU_RELRO 0x002de8 0x0000000000003de8 0x0000000000003de8 0x000218 0x000218 R 0x1
mapeo de Sección a Segmento:
Segmento Secciones...
00
01 .interp
02 .interp .note.gnu.build-id .note.ABI-tag .gnu.hash .dynsym .dynstr .gnu.version .gnu.version_r .rela.dyn .rela.plt
03 .init .plt .text .fini
04 .rodata .eh_frame_hdr .eh_frame
05 .init_array .fini_array .dynamic .got .got.plt .data .bss
06 .dynamic
07 .note.gnu.build-id .note.ABI-tag
08 .eh_frame_hdr
09
10 .init_array .fini_array .dynamic .got
in which segment the shstrtable is stored, because reviewing readelf -l doesn't appear.
It doesn't appear in any segment.
And the other question (coming from the first one) is it possible for a section not be inside a segment?
Yes.
Also i noticed some 'gaps' between some segments. What is inside those gaps?
Nothing. Segments tell the kernel or the runtime loader how to mmap the on-disk binary into memory. Since mmap operates on whole pages (4096 bytes here), the contents of memory between 0x560 and 0xFFF will be "whatever happens to be in the file at offsets 0x560 through 0xFFF, but the program shouldn't access it and the contents is effectively undefined. See also this answer.
I have used a symbol "__copy_start" inside my assembly code which is coming from linker script. symbol is defined as ABS in symbol table.
This symbol is used inside a macro to copy data from one memory location to another.
After looking at varenter code hereious ways to modify this symbol directly in elf i decided to write C code of my own to modify the symbol value.
To do that i traversed entire symbol table and did string match for the symbol i am interested in. When there is a symbol name match i just assigned symbol_table.st_value = new value.
To make sure the new value is taken i did readelf -s and checked that it does show the new value assigned by me.
Now, when i disassemble the modified elf i find that the new value has not taken effect and i still see the assembly code doing copy from old symbol value.
My question is:
Am i doing something wrong here? is it possible to change the symbol values in elf? If yes, please let me know the correct way to do it. How do i achieve what i intend to do here.
Note: I don't have the source code so taking this approach.
Thanks in advance,
Gaurav
wanted to add more information so that people can understand better.
copying the elf header below:
ELF Header:
Magic: 7f 45 4c 46 01 01 01 00 00 00 00 00 00 00 00 00
Class: ELF32
Data: 2's complement, little endian
Version: 1 (current)
OS/ABI: UNIX - System V
ABI Version: 0
**Type: EXEC (Executable file)**
Machine: Ubicom32 32-bit microcontrollers
Version: 0x1
Entry point address: 0xb0000000
Start of program headers: 52 (bytes into file)
Start of section headers: 33548 (bytes into file)
Flags: 0x6
Size of this header: 52 (bytes)
Size of program headers: 32 (bytes)
Number of program headers: 2
Size of section headers: 40 (bytes)
Number of section headers: 6
Section header string table index: 3
Here as you can see that file is of type executable.
output of readelf -S copied below:
There are 6 section headers, starting at offset 0x830c:
Section Headers:
[Nr] Name Type Addr Off Size ES Flg Lk Inf Al
[ 0] NULL 00000000 000000 000000 00 0 0 0
[ 1] .text PROGBITS 3ffc0000 004000 000ebc 00 AX 0 0 1
[ 2] .sdram PROGBITS 50000000 008000 0002e4 00 WA 0 0 1
[ 3] .shstrtab STRTAB 00000000 0082e4 000028 00 0 0 1
[ 4] .symtab SYMTAB 00000000 0083fc 0001c0 10 5 20 4
[ 5] .strtab STRTAB 00000000 0085bc 00019a 00 0 0 1
I am using one of the symbol named "__copy_start" in an instruction to copy the data from .sdram section to .text section. I was under an impression that i could go and change the symbol_table.st_value and then get the desired work done. But unfortunately that is not the case. Seems like it is already compiled and cannot be changed like this.
Any idea how this could be done would be really helpful.
Regards,
Gaurav
Are you sure that the object code actually uses a relocation to reference the data at the __copy_start symbol? Even for position-independent code, it is usually possible to turn section start addresses into relative addresses, which do not need a relocation. (That the symbol itself remains present with an absolute address does not change this.)
You can check this by using readelf -r or eu-readelf -r and examining the output. It is also visible in the objdump --dissassemble --reloc output.
I have a 32 bit app website running on IIS 7.5 that is randomly crashing and provides a hdmp file under the WER directory. Problem is the dump file is around 3GB and can't be read by the 32 bit Windbg tool as it gives an error that it is too big. The 64 bit version of Windbg will read it but when it comes to running any commands, it says it can't run as the crash dump is for a 32 bit app.
Is there a way to read this dump file or any way to make it smaller for future crashes? Is there a size limit on 32 bit crash dumps that Windbg can analyse ie 2GB? I'm a sys admin rather than a web developer, so this is all new to me.
UPDATE
Got some kind of output from !Analyse -v, although symbols haven't loaded properly direct from MS:
NTGLOBALFLAG: 0
APPLICATION_VERIFIER_FLAGS: 0
APP: w3wp.exe
ANALYSIS_VERSION: 6.3.9600.17336 (debuggers(dbg).150226-1500) amd64fre
MANAGED_STACK: !dumpstack -EE
SOS does not support the current target architecture.
MANAGED_BITNESS_MISMATCH:
Managed code needs matching platform of sos.dll for proper analysis. Use 'x86' debugger.
PRIMARY_PROBLEM_CLASS: WRONG_SYMBOLS
BUGCHECK_STR: APPLICATION_FAULT_WRONG_SYMBOLS_CLR_EXCEPTION
LAST_CONTROL_TRANSFER: from 72ec615a to 756fb727
STACK_TEXT:
1cdef038 72ec615a e0434352 00000001 00000005 KERNELBASE!RaiseException+0x58
1cdef0dc 72fd1bec 00000000 10f354c4 1cdef100 clr!RaiseTheExceptionInternalOnly+0x276
1cdef0f4 72fd1e1d 00000004 1cdef26c 72ec637e clr!RaiseTheException+0x86
1cdef11c 72fd1e4d 00000004 00000004 00000000 clr!RaiseTheExceptionInternalOnly+0x30a
1cdef150 72faef2d 8843cf04 00000000 1b8f51c0 clr!RealCOMPlusThrow+0x2f
1cdef278 72fae48a 00000000 1cdef2bc 8843ce3c clr!Thread::RaiseCrossContextException+0x37b
1cdef340 72e57c22 00000002 01e57c43 00000000 clr!Thread::DoADCallBack+0x2d3
1cdef398 00b4a9bd ffffffff 00b4a940 1cdef3d4 clr!UM2MDoADCallBack+0x92
WARNING: Frame IP not in any known module. Following frames may be wrong.
1cdef3cc 72cf9651 00000000 00c4f1c4 0000000e 0xb4a9bd
1cdef3f0 72cfa3b4 733e81f0 72cfa382 1cdef448 webengine4!W3_MGD_HANDLER::ProcessNotification+0x58
1cdef400 72e4de98 00c4f1c4 8843c96c 1cdef479 webengine4!ProcessNotificationCallback+0x32
1cdef448 72e519b1 1cdef479 1cdef47b 000b001c clr!UnManagedPerAppDomainTPCount::DispatchWorkItem+0x1c6
1cdef45c 72e52591 8843c914 72e5245b 00000000 clr!ThreadpoolMgr::ExecuteWorkRequest+0x42
1cdef4c4 72e5b4ad 00000000 00000000 776620c0 clr!ThreadpoolMgr::WorkerThreadStart+0x353
1cdef85c 751933ca 1b89d348 1cdef8a8 77599ed2 clr!Thread::intermediateThreadProc+0x4d
1cdef868 77599ed2 1b89d348 4e01fdde 00000000 kernel32!BaseThreadInitThunk+0xe
1cdef8a8 77599ea5 72e5b464 1b89d348 ffffffff ntdll!__RtlUserThreadStart+0x70
1cdef8c0 00000000 72e5b464 1b89d348 00000000 ntdll!_RtlUserThreadStart+0x1b
FOLLOWUP_IP:
clr!Thread::DoADCallBack+2d3
72fae48a 8b4508 mov eax,dword ptr [ebp+8]
SYMBOL_STACK_INDEX: 6
SYMBOL_NAME: clr!Thread::DoADCallBack+2d3
FOLLOWUP_NAME: MachineOwner
MODULE_NAME: clr
IMAGE_NAME: clr.dll
DEBUG_FLR_IMAGE_TIMESTAMP: 52310b2d
STACK_COMMAND: ~34s; .ecxr ; kb
FAILURE_BUCKET_ID: WRONG_SYMBOLS_e0434352_clr.dll!Thread::DoADCallBack
BUCKET_ID: APPLICATION_FAULT_WRONG_SYMBOLS_CLR_EXCEPTION_clr!Thread::DoADCallBack+2d3
ANALYSIS_SOURCE: UM
FAILURE_ID_HASH_STRING: um:wrong_symbols_e0434352_clr.dll!thread::doadcallback
FAILURE_ID_HASH: {15ee992e-553a-06bb-20c5-a254780b9452}
Followup: MachineOwner
Anybody any ideas???
Thanks a lot!
Since last week, Word and Excel are often crashing, even on very simple documents. Just now, Firefox also crashed. What can I do to repair it or find the real root cause?
I have already repaired Office installation using the Setup. All regular updates should be installed. Laptop is rebooted every day.
I have configured WinDbg to attach and this is what I get. I also have a dump, so if you need more information, I can still get it. Here's info from my first dump of Word:
0:020> .exr -1
ExceptionAddress: 11fdf91c
ExceptionCode: c0000005 (Access violation)
ExceptionFlags: 00000000
NumberParameters: 2
Parameter[0]: 00000008
Parameter[1]: 11fdf91c
Attempt to execute non-executable address 11fdf91c
0:020> kb
ChildEBP RetAddr Args to Child
WARNING: Frame IP not in any known module. Following frames may be wrong.
11fdf91c 75d05d3f 00000008 0dc0bbe8 fffffffe 0x11fdf91c
11fdfacc 75d38f82 bf3079e6 0dc0bbe8 00000000 ole32!COIDTable::ThreadCleanup+0xcb [d:\w7rtm\com\ole32\com\dcomrem\idobj.cxx # 1760]
11fdfb10 75d38ec3 00000000 11fdfb60 75e37724 ole32!FinishShutdown+0x9d [d:\w7rtm\com\ole32\com\class\compobj.cxx # 1035]
11fdfb30 75d2bac3 00000000 75d309ad 0dc0bbe8 ole32!ApartmentUninitialize+0x96 [d:\w7rtm\com\ole32\com\class\compobj.cxx # 1291]
11fdfb48 75d388e8 11fdfb60 00000000 00000000 ole32!wCoUninitialize+0x153 [d:\w7rtm\com\ole32\com\class\compobj.cxx # 2766]
11fdfb64 6e77314a 11fdfbf4 75f043c0 0b179b08 ole32!CoUninitialize+0x72 [d:\w7rtm\com\ole32\com\class\compobj.cxx # 2620]
11fdfb6c 75f043c0 0b179b08 00000000 00000000 NetworkItemFactory!FDBackgroundThreadHandler+0x21
11fdfbf4 75bf336a 0da0f624 11fdfc40 773a9f72 SHLWAPI!WrapperThreadProc+0x1b5
11fdfc00 773a9f72 0da0f624 66709c63 00000000 kernel32!BaseThreadInitThunk+0xe
11fdfc40 773a9f45 75f042ed 0da0f624 ffffffff ntdll!__RtlUserThreadStart+0x70
11fdfc58 00000000 75f042ed 0da0f624 00000000 ntdll!_RtlUserThreadStart+0x1b
0:020> vertarget
Windows 7 Version 7601 (Service Pack 1) MP (8 procs) Free x86 compatible
Product: WinNt, suite: SingleUserTS
kernel32.dll version: 6.1.7601.18229 (win7sp1_gdr.130801-1533)
Machine Name:
Debug session time: Wed Feb 5 14:55:55.241 2014 (UTC + 1:00)
System Uptime: 0 days 3:46:03.386
Process Uptime: 0 days 0:05:08.582
Kernel time: 0 days 0:00:03.822
User time: 0 days 0:00:11.528
If I recall correctly, it was related to a VOIP software called Netphone Client from Deutsche Telekom, which includes itself into other applications via a COM object.
Therefore this was exactly as projected by Hans Passant in the comments:
You are buried inside the COM plumbing with a clear hint that its internal state is corrupted. This is an environmental problem, some kind of DLL that gets injected into the process and screws things up. Long before the crash occurs so you'll have very little hope of diagnosing it with a debugger. Find the common source of the problem from the modules list. Suspect any shell extension, anti-malware, any utility similar to Dropbox. Use SysInternals' AutoRuns to disable them.
I don't remember how exactly I found the culprit, but I finally used a physical VOIP phone instead of the software + headset.
I would like to come up with the byte code in assembler (assembly?) for Windows machines to add two 32-bit longs and throw away the carry bit. I realize the "Windows machines" part is a little vague, but I'm assuming that the bytes for ADD are pretty much the same in all modern Intel instruction sets.
I'm just trying to abuse VB a little and make some things faster. So as an example of running direct assembly in VB, the hex string "8A4C240833C0F6C1E075068B442404D3E0C20800" is the assembly code for SHL that can be "injected" into a VB6 program for a fast SHL operation expecting two Long parameters (we're ignoring here that 32-bit longs in VB6 are signed, just pretend they are unsigned).
Along those same lines, what is the hex string of bytes representing assembler instructions that will do the same thing to return the sum of two 32-bit unsigned integers?
The hex code above for SHL is, according to the author:
mov eax, [esp+4]
mov cl, [esp+8]
shl eax, cl
ret 8
I spit those bytes into a file and tried unassembling them in a windows command prompt using the old debug utility, but I figured out it's not working with the newer instruction set because it didn't like EAX when I tried assembling something but it was happy with AX.
I know from comments in the source code that SHL EAX, CL is D3E0, but I don't have any reference to know what the bytes are for instruction ADD EAX, CL or I'd try it. (Though I know now that the operands have to be the same size.)
I tried flat assembler and am not getting anything I can figure out how to use. I used it to assemble the original SHL code and got a very different result, not the same bytes. Help?
I disassembled the bytes you provided and got the following code:
(__TEXT,__text) section
f:
00000000 movb 0x08(%esp),%cl
00000004 xorl %eax,%eax
00000006 testb $0xe0,%cl
00000009 jne 0x00000011
0000000b movl 0x04(%esp),%eax
0000000f shll %cl,%eax
00000011 retl $0x0008
Which is definitely more complicated than the source code the author provided. It checks that the second operand isn't too large, for example, which isn't in the code you showed at all (see Edit 2, below, for a more complete analysis). Here's a simple stdcall function that adds two arguments together and returns the result:
mov 4(%esp), %eax
add 8(%esp), %eax
ret $8
Assembling that gives me this output:
(__TEXT,__text) section
00000000 8b 44 24 04 03 44 24 08 c2 08 00
I hope those bytes do what you want them to!
Edit: Perhaps more usefully, I just did the same in C:
__attribute__((__stdcall__))
int f(int a, int b)
{
return a + b;
}
Compiled with -Oz and -fomit-frame-pointer it generates exactly the same code (well, functionally equivalent, anyway):
$ gcc -arch i386 -fomit-frame-pointer -Oz -c -o example.o example.c
$ otool -tv example.o
example.o:
(__TEXT,__text) section
_f:
00000000 movl 0x08(%esp),%eax
00000004 addl 0x04(%esp),%eax
00000008 retl $0x0008
The machine code output:
$ otool -t example.o
example.o:
(__TEXT,__text) section
00000000 8b 44 24 08 03 44 24 04 c2 08 00
Sure beats hand-writing assembly code!
Edit 2:
#ErikE asked in the comments below what would happen if a shift of 32 bits or greater was attempted. The disassembled code at the top of this answer (for the bytes provided in the original question) can be represented by the following higher-level code:
unsigned int shift_left(unsigned int a, unsigned char b)
{
if (b > 32)
return 0;
else
return a << b;
}
From this logic it's pretty easy to see that if you pass a value greater than 32 as the second parameter to the shift function, you'll just get 0 back.