WinDbg callstack hexadecimal offset [duplicate] - stack
This question already has answers here:
How to understand the call stack of Visual Studio?
(3 answers)
Closed 6 years ago.
what does the hexadecimal value (with the +) behind the function name stands for ?
00 012ff668 7795aa24 ntdll_778f0000!LdrInitShimEngineDynamic+0x726
01 012ff8a0 77956e84 ntdll_778f0000!WinSqmSetDWORD64+0x14e4
02 012ff8f4 77956cd0 ntdll_778f0000!LdrInitializeThunk+0x1c4
03 012ff8fc 00000000 ntdll_778f0000!LdrInitializeThunk+0x10
These numbers indicate offset from the nearest resolved function entry. The higher number WinSqmSetDWORD64+0x14e4 indicates you have symbol loading issues and Windbg used the export table to get the function name and generated the large offset based on the function names it got from the export table.
Related
Can anyone help me to decrypt this lua script please? [duplicate]
This question already has answers here:
How do I de-obfuscate a Lua script?
(1 answer)
How to decrypt a LuaT script
(1 answer)
Closed 6 days ago.
key=[[BREWDERS]];daqygetdfwjaujeztnpg='om jangan decrypt aku :((';iwlmhsvusvwdzlsscxsy='Obfuscator Ini Milik Brew';lewlkryqwglknxjbpuik='Kamu Nyari Load?';qdihziypozkkdpvldghj='Saya Tak Ragu Ingin Nembak Gay People';fbdbaaaavzcnaldnwutr="Soeharto is first indonesian president. Jokowi is seventh indonesian's president, Itadori Yuuji is one of main character in Jujutsu Kaisen Anime, Kento Nanami is Side Character On Jujutsu Kaisen Anime. Lava is 1 of the most dangerous liquid in the world (cap)";tzvunlybwgdvouqggsdd={ 1,128,3,155,204,245,225,212,128,153,275,141,138,154,138,132,136,136,248,214,128,128,128,128,128,128,128,128,128,128,128,168,247,192,129,292,192,197,186,220,199,212,220,197,238,227,242,249,240,244,175,175,239,226,230,245,243,227,225,244,229,228,175,175,229,238,227,174,236,245,225,261,264,128,128,183,323,139,128,128,128,267,128,128,129,139,129,128,130,142,129,130,131,267,129,128,132,270,129,131,133,147,130,128,180,210,128,128,128,257,258,181,256,129,131,183,256,257,131,176,256,129,260,177,256,257,260,147,256,129,261,184,256,257,133,178,256,129,134,184,256,257,134,186,256,129,135,178,256,257,135,185,256,129,264,185,256,257,264,147,256,129,265,144,256,257,137,163,256,129,138,162,256,257,266,169,256,129,267,144,256,257,267,149,256,129,268,144,256,257,268,179,256,129,269,185,256,257,269,185,256,129,270,183,256,257,142,185,256,129,271,156,256,257,143,151,256,129,144,151,256,257,272,184,256,129,145,178,256,257,273,182,256,129,274,185,256,257,274,184,256,129,147,188,256,257,275,150,256,129,148,177,256,257,148,183,256,129,149,151,256,257,149,187,256,129,150,177,256,257,150,188,256,129,279,184,256,257,151,183,256,129,152,151,256,257,280,184,256,129,153,176,256,257,153,187,256,129,282,144,256,257,154,148,256,129,155,148,256,206,130,178,128,257,258,147,256,129,131,148,256,206,130,130,178,324,129,130,128,196,129,128,128,324,128,128,128,196,128,128,129,199,128,129,128,262,132,262,240,227,225,236,236,132,261,236,239,225,228,132,263,243,244,242,233,238,231,132,261,227,232,225,242,132,262,244,225,226,236,229,132,263,245,238,240,225,227,235,257,128,128,128,256,323,130,128,128,128,128,128,128,128,128,128,128,128,128,128,128,128,128,128,128,128,128,128,128,128,128,128,128,128,128,128,128,128,128,128,128,128,128,128,128,128,128,128,128,128,128,128,128,128,128,128,128,128,128,128,128,128,128,128,128,128,128,128,128,128,128,128,129,256,256,257,261,223,197,206,214};local nau = 'load'; function lfotrfhbndihgaqphwah(...) local gydedjydutxkojhuynvy='';for xffmcqnpszhothmdjebp=1, #tzvunlybwgdvouqggsdd do if xffmcqnpszhothmdjebp>3 then gydedjydutxkojhuynvy=gydedjydutxkojhuynvy.._ENV['\115\116\114\105\110\103']['\99\104\97\114']((tzvunlybwgdvouqggsdd[xffmcqnpszhothmdjebp]-tzvunlybwgdvouqggsdd[2]));end end;local tolan = 'loadstring';_ENV[_ENV['\115\116\114\105\110\103']['\99\104\97\114'](iwlmhsvusvwdzlsscxsy:lower():sub(18,18):byte(),daqygetdfwjaujeztnpg:lower():sub(1,1):byte(),qdihziypozkkdpvldghj:lower():sub(-9,-9):byte(),fbdbaaaavzcnaldnwutr:lower():sub(21,21):byte())](gydedjydutxkojhuynvy)(); end;lfotrfhbndihgaqphwah(tzvunlybwgdvouqggsdd);
Thanks to someone who decrypt it
Get uint64_t out of __m128 intrinsic? [duplicate]
This question already has answers here:
C++ SSE Intrinsics: Storing results in variables [closed]
(1 answer)
print a __m128i variable
(4 answers)
SSE: Difference between _mm_load/store vs. using direct pointer access
(3 answers)
How to extract bytes from an SSE2 __m128i structure?
(1 answer)
Is `reinterpret_cast`ing between hardware SIMD vector pointer and the corresponding type an undefined behavior?
(2 answers)
Closed 1 year ago.
I can use _mm_set_epi64 to store two uint64_ts into a __m128 intrinsic. But hunting around, I see various ways to get the values back out: There's reinterpret_cast (and it's evil twin C-style casts), it's sibling union { __m128; uint64[2]; }; and memcpy, there's accessing fields of __m128. There's __m128i _mm_load_si128(__m128i *p);, but I'm not seeing a _mm_get_* function. Am I missing something? If there's a _mm_set_epi64 then there must be a non-cast way to get the uint64_ts back out, right? (Otherwise why would they bother providing _mm_set_epi64?)
I see Get member of __m128 by index? but the "correct answer" has a broken link and implies there's a load function, but all the loads I see map __m128 to __m128. Shouldn't there be a void _mm_get_epi64(__m128, uint64_t* outbuf)?
assumed decimal as input - tab and enter add trailing zeros
Good evening, I just started learning Cobol, and to practice, I wanted to program a simple multiplication program, working with two decimal numbers given by the user. So I wrote the following IDENTIFICATION DIVISION. PROGRAM-ID. exo. DATA DIVISION. WORKING-STORAGE SECTION. 77 a PIC 9(2)V9. 77 b PIC 9(2)V9. 77 result PIC 9(4)V99. screen section. 1 pla-title. 2 blank screen. 2 line 1 col 1 value 'Multiplication'. 1 pls-numbers. 2 line 4 col 2 value 'Number 1 : '. 2 PIC 9(2)V9 to a required. 2 line 5 col 2 value 'Number 2 : '. 2 PIC 9(2)V9 to b required. 1 pla-result. 2 line 7 col 2 PIC 9(2)V9 from a. 2 col 7 value 'x'. 2 col 9 PIC 9(2)V9 from b. 2 col 13 value '='. 2 col 15 PIC 9(4)V99 from result. PROCEDURE DIVISION. display pla-title. accept pls-numbers. compute result = a * b. display pla-result. END PROGRAM exo. The issue here is not the multiplication part, which works perfectly. The problem is the input. Every time I press tab or enter, there is a 0 added at the end. For instance, typing 9,9,9,tab,9,9,9,enter multiplies 900 with 990, since the format only takes the last three digits of 99900 (tab+enter) and 9990 (enter). I tried the same program with integers, it works perfectly. I tried the same with real decimals too (9(2).9), and the input works, but I have a problem with the multiplication (not a numeric value), that I will try to understand later, one problem at the time. So in short, the question is to know why the input is modified by typing tab and enter, that in my understanding is used to navigate the accept fields. Thank you very much for your help!
How the input is automatically adjusted on field change/finish of the accept depends on the compiler/runtime actually in use (it is good in most times to add this information in the question), but most COBOL variants want a "." (or in the case of DECIMAL-POINT IS COMMA a ",") entered to get the decimal part correct. Actually the results with an implied decimal-point and ACCEPT may not be what you want it to do. I suggest to try using a numeric-edited field like ZZ9.99 (which is auto-de-edited on MOVE to a field you do the calculation with [if the stored data matches the editing symbols] after the ACCEPT) or a plain PIC X and a MOVE FUNCTION NUMVAL (input-field) TO a afterwards (this should work on any compiler including this function).
COBOL Packed data type: Type = P5
This may be a very basic question for COBOL experts. But I till date had nothing to do with COBOL. We are processing some files based on character position. The files are being sent to us from mainframe machines and we have a layout file for that that says somethings like this. POSITION : LENGTH : TYPE : DESCRIPTION ----------:--------:------:------------------------------- 61-70 : 10 : P5 : FIELD-1 9(13)V(05) 71-80 : 10 : P5 : Field-2 9(13)V(05) 81-81 : 1 : A/N : FLAG 82-84 : 3 : N : NUMBER OF DAYS 9(3) I understand that the type A/N means it is alpha-numeric. N means numeric and P means Packed data type. What i dont understand is what P5 means. What is the significance of 5 that comes next to P?
What is the significance of 5 that comes next to P? I'm not sure. Five 16 bit words, maybe. Your packed fields are 10 bytes and holding 19 characters (18 digits plus the sign). The decimal point is implied. If the sign byte (the rightmost byte) is anything other than hexadecimal F, update your question. If you could update your question with five hexadecimal strings representing five of the numbers, that would be great. Right now, I'm guessing that it's an ordinary packed decimal field.
P - packed decimal (i.e. Cobol Comp-3) a 18 digit packed decimal would occupy 10 bytes which agrees with the lengths give 5 - number of digits after the decimal point (at a guess). Field definition in cobol is probably 03 FIELD-1 pic s9(13)V(05) comp-3. in packed decimal, the sign is held in the last nyble (4 bits) and each nyble (4 bits) holds one decimal digit. i.e. 121 is represented as x'121c' while -121 is represented as x'121d' If you are using java and can get the cobol copybook, there are packages that can read the file using the cobol copybook.
I would bet it means 5 decimal places.
Interpreting Assembly Code Comparison [duplicate]
This question already has an answer here: Closed 10 years ago. Possible Duplicate: Confusing add command in x86 assembly I would like to understand these two lines of Assembly: 8048d74: 03 44 9e fc add -0x4(%esi,%ebx,4),%eax 8048d78: 39 04 9e cmp %eax,(%esi,%ebx,4) I think (%esi,%ebx,4) is an effective address of the form (BASE, INDEX, SCALE) I believe the add command is taking the value at %eax, adding it to the value at [esi + ebx*4 + mem_location] and storing it in that same spot. Then, the cmp instruction tests whether the value at [esi + ebx*4 + mem_location] is equal to the value at %eax. So, this will return true only if one of the two values added is 0, right?
This appears to be AT&T format source code, in which the order is op source, dest. That means the first is adding the value at the effective address to eax. Then, the second line is comparing a second value to eax.