কোড 9 (SEGV_MTESERR) বা কোড 8 (SEGV_MTEAERR) সহ SIGSEGV ক্র্যাশগুলি মেমরি ট্যাগিং ত্রুটি৷ মেমরি ট্যাগিং এক্সটেনশন (MTE) হল একটি Armv9 বৈশিষ্ট্য যা Android 12 এবং পরবর্তীতে সমর্থিত। MTE ট্যাগ করা মেমরির একটি হার্ডওয়্যার বাস্তবায়ন। এটি মেমরি সুরক্ষা বাগ সনাক্তকরণ এবং প্রশমনের জন্য সূক্ষ্ম দানাদার মেমরি সুরক্ষা প্রদান করে।
C/C++ এ, malloc() বা অপারেটর new() বা অনুরূপ ফাংশনে কল থেকে ফিরে আসা একটি পয়েন্টার শুধুমাত্র সেই বরাদ্দের সীমার মধ্যে মেমরি অ্যাক্সেস করতে ব্যবহার করা যেতে পারে, এবং শুধুমাত্র যখন বরাদ্দটি জীবিত থাকে (ফ্রি-এড নয় বা ডিলিট-এড)। এই নিয়মের লঙ্ঘন শনাক্ত করতে Android-এ MTE ব্যবহার করা হয়, ক্র্যাশ রিপোর্টে "Buffer Overflow"/"Buffer Underflow" এবং "Use After Free" সমস্যা হিসেবে উল্লেখ করা হয়েছে।
MTE এর দুটি মোড রয়েছে: সিঙ্ক্রোনাস (বা "সিঙ্ক") এবং অ্যাসিঙ্ক্রোনাস (বা "অসিঙ্ক")। প্রাক্তনটি আরও ধীরে ধীরে চলে তবে আরও সঠিক ডায়াগনস্টিক সরবরাহ করে। পরেরটি দ্রুত চলে, কিন্তু শুধুমাত্র আনুমানিক বিবরণ দিতে পারে। আমরা উভয়ই আলাদাভাবে কভার করব, যেহেতু ডায়াগনস্টিকগুলি কিছুটা আলাদা।
সিঙ্ক্রোনাস মোড MTE
MTE-এর সিঙ্ক্রোনাস ("সিঙ্ক") মোডে, SIGSEGV কোড 9 (SEGV_MTESERR) এর সাথে ক্র্যাশ হয়৷
pid: 13935, tid: 13935, name: sanitizer-statu >>> sanitizer-status <<< uid: 0 tagged_addr_ctrl: 000000000007fff3 signal 11 (SIGSEGV), code 9 (SEGV_MTESERR), fault addr 0x800007ae92853a0 Cause: [MTE]: Use After Free, 0 bytes into a 32-byte allocation at 0x7ae92853a0 x0 0000007cd94227cc x1 0000007cd94227cc x2 ffffffffffffffd0 x3 0000007fe81919c0 x4 0000007fe8191a10 x5 0000000000000004 x6 0000005400000051 x7 0000008700000021 x8 0800007ae92853a0 x9 0000000000000000 x10 0000007ae9285000 x11 0000000000000030 x12 000000000000000d x13 0000007cd941c858 x14 0000000000000054 x15 0000000000000000 x16 0000007cd940c0c8 x17 0000007cd93a1030 x18 0000007cdcac6000 x19 0000007fe8191c78 x20 0000005800eee5c4 x21 0000007fe8191c90 x22 0000000000000002 x23 0000000000000000 x24 0000000000000000 x25 0000000000000000 x26 0000000000000000 x27 0000000000000000 x28 0000000000000000 x29 0000007fe8191b70 lr 0000005800eee0bc sp 0000007fe8191b60 pc 0000005800eee0c0 pst 0000000060001000 backtrace: #00 pc 00000000000010c0 /system/bin/sanitizer-status (test_crash_malloc_uaf()+40) (BuildId: 953fc93301472d0b72709b2b9a9f6f30) #01 pc 00000000000014a4 /system/bin/sanitizer-status (test(void (*)())+132) (BuildId: 953fc93301472d0b72709b2b9a9f6f30) #02 pc 00000000000019cc /system/bin/sanitizer-status (main+1032) (BuildId: 953fc93301472d0b72709b2b9a9f6f30) #03 pc 00000000000487d8 /apex/com.android.runtime/lib64/bionic/libc.so (__libc_init+96) (BuildId: 6ab39e35a2fae7efbe9a04e9bbb14331) deallocated by thread 13935: #00 pc 000000000004643c /apex/com.android.runtime/lib64/bionic/libc.so (scudo::Allocator<scudo::AndroidConfig, &(scudo_malloc_postinit)>::quarantineOrDeallocateChunk(scudo::Options, void*, scudo::Chunk::UnpackedHeader*, unsigned long)+688) (BuildId: 6ab39e35a2fae7efbe9a04e9bbb14331) #01 pc 00000000000421e4 /apex/com.android.runtime/lib64/bionic/libc.so (scudo::Allocator<scudo::AndroidConfig, &(scudo_malloc_postinit)>::deallocate(void*, scudo::Chunk::Origin, unsigned long, unsigned long)+212) (BuildId: 6ab39e35a2fae7efbe9a04e9bbb14331) #02 pc 00000000000010b8 /system/bin/sanitizer-status (test_crash_malloc_uaf()+32) (BuildId: 953fc93301472d0b72709b2b9a9f6f30) #03 pc 00000000000014a4 /system/bin/sanitizer-status (test(void (*)())+132) (BuildId: 953fc93301472d0b72709b2b9a9f6f30) allocated by thread 13935: #00 pc 0000000000042020 /apex/com.android.runtime/lib64/bionic/libc.so (scudo::Allocator<scudo::AndroidConfig, &(scudo_malloc_postinit)>::allocate(unsigned long, scudo::Chunk::Origin, unsigned long, bool)+1300) (BuildId: 6ab39e35a2fae7efbe9a04e9bbb14331) #01 pc 0000000000042394 /apex/com.android.runtime/lib64/bionic/libc.so (scudo_malloc+36) (BuildId: 6ab39e35a2fae7efbe9a04e9bbb14331) #02 pc 000000000003cc9c /apex/com.android.runtime/lib64/bionic/libc.so (malloc+36) (BuildId: 6ab39e35a2fae7efbe9a04e9bbb14331) #03 pc 00000000000010ac /system/bin/sanitizer-status (test_crash_malloc_uaf()+20) (BuildId: 953fc93301472d0b72709b2b9a9f6f30) #04 pc 00000000000014a4 /system/bin/sanitizer-status (test(void (*)())+132) (BuildId: 953fc93301472d0b72709b2b9a9f6f30)
সমস্ত MTE ক্র্যাশ রিপোর্টে সাধারণ রেজিস্টার ডাম্প এবং ব্যাকট্রেস রয়েছে যেখানে সমস্যাটি সনাক্ত করা হয়েছিল। MTE দ্বারা শনাক্ত করা একটি ত্রুটির জন্য "কারণ:" লাইনে আরো বিস্তারিত সহ উপরের উদাহরণের মতো "[MTE]" থাকবে। এই ক্ষেত্রে, সনাক্ত করা নির্দিষ্ট ধরনের ত্রুটি ছিল একটি "ব্যবহার করার পরে বিনামূল্যে", এবং "0x7ae92853a0 এ একটি 32-বাইট বরাদ্দের মধ্যে 0 বাইট" আমাদের বরাদ্দের আকার এবং ঠিকানা এবং বরাদ্দের অফসেট বলে দেয় যা আমরা অ্যাক্সেস করার চেষ্টা করেছে।
MTE ক্র্যাশ রিপোর্টে অতিরিক্ত ব্যাকট্রেসও অন্তর্ভুক্ত থাকে, শুধুমাত্র সনাক্তকরণের বিন্দু থেকে নয়।
"ব্যবহার করুন বিনামূল্যের পরে" ত্রুটিগুলি ক্র্যাশ ডাম্পে "অবরাদ্দকৃত দ্বারা" এবং "বরাদ্দকৃত" বিভাগগুলিকে যুক্ত করে, এই মেমরিটি ডিললোকেট করার সময় (এটি ব্যবহার করার আগে!), এবং এটি পূর্বে বরাদ্দ করা সময় স্ট্যাক ট্রেসগুলি দেখায়৷ এগুলি আপনাকে বলে যে কোন থ্রেডটি বরাদ্দ/বরাদ্দকরণ করেছে। এই সাধারণ উদাহরণে সনাক্তকারী থ্রেড, বরাদ্দ করা থ্রেড এবং ডিললোকেটিং থ্রেড তিনটিই একই, তবে আরও জটিল বাস্তব-বিশ্বের ক্ষেত্রে এটি অগত্যা সত্য নয়, এবং তাদের মধ্যে পার্থক্য রয়েছে তা জেনে রাখা একটি সঙ্গতি খুঁজে পাওয়ার ক্ষেত্রে একটি গুরুত্বপূর্ণ সূত্র হতে পারে। - সম্পর্কিত বাগ।
"বাফার ওভারফ্লো" এবং "বাফার আন্ডারফ্লো" ত্রুটিগুলি শুধুমাত্র একটি অতিরিক্ত "বরাদ্দকৃত" স্ট্যাক ট্র্যাক প্রদান করে, যেহেতু সংজ্ঞা অনুসারে সেগুলি এখনও ডিলোকেটেড করা হয়নি (বা তারা "ব্যবহার করার পরে বিনামূল্যে" হিসাবে দেখাবে):
Cause: [MTE]: Buffer Overflow, 0 bytes right of a 32-byte allocation at 0x7ae92853a0 [...] backtrace: [...] allocated by thread 13949:
এখানে "ডান" শব্দের ব্যবহার লক্ষ্য করুন: এর মানে আমরা আপনাকে বলছি যে বরাদ্দের শেষের কত বাইট ভুল অ্যাক্সেস ছিল; একটি আন্ডারফ্লো বলবে "বাম", এবং বরাদ্দ শুরুর আগে অনেক বাইট হবে।
একাধিক সম্ভাব্য কারণ
কখনও কখনও SEGV_MTESERR রিপোর্টে নিম্নলিখিত লাইন থাকে:
Note: multiple potential causes for this crash were detected, listing them in decreasing order of likelihood.
এটি ঘটে যখন ত্রুটির উত্সের জন্য বেশ কয়েকটি ভাল প্রার্থী থাকে এবং আমরা প্রকৃত কারণটি বলতে পারি না। আমরা সম্ভাব্যতার আনুমানিক ক্রমানুসারে এই ধরনের 3 জন প্রার্থীকে প্রিন্ট করি এবং বিশ্লেষণটি ব্যবহারকারীর উপর ছেড়ে দিই।
signal 11 (SIGSEGV), code 9 (SEGV_MTESERR), fault addr 0x400007b43063db5
backtrace:
[stack...]
Note: multiple potential causes for this crash were detected, listing them in decreasing order of probability.
Cause: [MTE]: Use After Free, 5 bytes into a 10-byte allocation at 0x7b43063db0
deallocated by thread 6663:
[stack...]
allocated by thread 6663:
[stack...]
Cause: [MTE]: Use After Free, 5 bytes into a 6-byte allocation at 0x7b43063db0
deallocated by thread 6663:
[stack...]
allocated by thread 6663:
[stack...]উপরের উদাহরণে, আমরা একই মেমরি ঠিকানায় দুটি সাম্প্রতিক বরাদ্দ শনাক্ত করেছি যা অবৈধ মেমরি অ্যাক্সেসের উদ্দেশ্য লক্ষ্য হতে পারে। এটি ঘটতে পারে যখন বরাদ্দগুলি বিনামূল্যে মেমরি পুনরায় ব্যবহার করে - উদাহরণস্বরূপ, যদি আপনার ক্রম থাকে যেমন নতুন, বিনামূল্যে, নতুন, বিনামূল্যে, নতুন, বিনামূল্যে, অ্যাক্সেস। আরো সাম্প্রতিক বরাদ্দ প্রথম মুদ্রিত হয়.
বিস্তারিত কারণ নির্ধারণ হিউরিস্টিকস
একটি ক্র্যাশের "কারণ" মেমরি বরাদ্দ প্রদর্শন করা উচিত যেটি অ্যাক্সেস করা পয়েন্টারটি মূলত থেকে উদ্ভূত হয়েছিল। দুর্ভাগ্যবশত, MTE হার্ডওয়্যারের একটি অমিল ট্যাগ সহ একটি পয়েন্টার থেকে একটি বরাদ্দে অনুবাদ করার কোনো উপায় নেই৷ একটি SEGV_MTESERR ক্র্যাশ ব্যাখ্যা করতে, Android নিম্নলিখিত ডেটা বিশ্লেষণ করে:
- দোষ ঠিকানা (পয়েন্টার ট্যাগ সহ)।
- স্ট্যাক ট্রেস এবং মেমরি ট্যাগ সহ সাম্প্রতিক হিপ বরাদ্দের একটি তালিকা।
- কাছাকাছি বর্তমান (লাইভ) বরাদ্দ এবং তাদের মেমরি ট্যাগ.
ফল্ট অ্যাড্রেস এ যেকোন সম্প্রতি ডিলোকেটেড মেমরি যেখানে মেমরি ট্যাগ ফল্ট অ্যাড্রেস ট্যাগের সাথে মেলে সেটি একটি সম্ভাব্য "ব্যবহার করুন ফ্রি" কারণ।
যে কোনো কাছাকাছি লাইভ মেমরি যেখানে মেমরি ট্যাগ ফল্ট অ্যাড্রেস ট্যাগের সাথে মেলে তা একটি সম্ভাব্য "বাফার ওভারফ্লো" (বা "বাফার আন্ডারফ্লো") কারণ।
যে বরাদ্দগুলি দোষের কাছাকাছি - হয় সময় বা স্থান - সেগুলি দূরে থাকাগুলির চেয়ে বেশি সম্ভাবনাময় বলে বিবেচিত হয়৷
যেহেতু ডিলোকেটেড মেমরি প্রায়শই পুনঃব্যবহৃত হয়, এবং বিভিন্ন ট্যাগ মানের সংখ্যা ছোট (16-এর কম), এটি বেশ কিছু সম্ভাব্য প্রার্থী খুঁজে পাওয়া অস্বাভাবিক নয়, এবং স্বয়ংক্রিয়ভাবে প্রকৃত কারণ খুঁজে পাওয়ার কোন উপায় নেই। এই কারণেই কখনও কখনও MTE রিপোর্ট একাধিক সম্ভাব্য কারণ তালিকাভুক্ত করে।
এটি বাঞ্ছনীয় যে অ্যাপ বিকাশকারী সম্ভাব্য কারণগুলি থেকে শুরু করে সম্ভাব্য কারণগুলি দেখেন৷ স্ট্যাক ট্রেসের উপর ভিত্তি করে সম্পর্কহীন কারণগুলি ফিল্টার করা প্রায়শই সহজ।
অ্যাসিঙ্ক্রোনাস মোড MTE
MTE এর অ্যাসিঙ্ক্রোনাস ("async") মোডে, SIGSEGV কোড 8 (SEGV_MTEAERR) এর সাথে ক্র্যাশ হয়৷
যখন একটি প্রোগ্রাম একটি অবৈধ মেমরি অ্যাক্সেস সম্পাদন করে তখন SEGV_MTEAERR ত্রুটিগুলি অবিলম্বে ঘটে না৷ ইভেন্টের পরেই সমস্যাটি শনাক্ত করা হয় এবং প্রোগ্রামটি সেই সময়ে বন্ধ হয়ে যায়। এই পয়েন্টটি সাধারণত পরবর্তী সিস্টেম কল, তবে এটি একটি টাইমার ইন্টারাপ্টও হতে পারে - সংক্ষেপে, যেকোন ইউজারস্পেস থেকে কার্নেল ট্রানজিশন।
SEGV_MTEAERR ত্রুটিগুলি মেমরি ঠিকানা সংরক্ষণ করে না (এটি সর্বদা "------" হিসাবে দেখানো হয়)। ব্যাকট্রেস সেই মুহূর্তের সাথে মিলে যায় যে মুহূর্তে অবস্থা শনাক্ত করা হয়েছিল (অর্থাৎ পরবর্তী সিস্টেম কলে বা অন্য কনটেক্সট সুইচের সময়), এবং যখন অবৈধ অ্যাক্সেস সম্পাদিত হয়েছিল তখন নয়।
এর মানে হল যে একটি অ্যাসিঙ্ক্রোনাস MTE ক্র্যাশে "প্রধান" ব্যাকট্রেস সাধারণত প্রাসঙ্গিক নয় ৷ অ্যাসিঙ্ক মোড ব্যর্থতাগুলি সিঙ্ক মোড ব্যর্থতার চেয়ে ডিবাগ করা অনেক বেশি কঠিন। প্রদত্ত থ্রেডের কাছাকাছি কোডে একটি মেমরি বাগ উপস্থিতি দেখানো হিসাবে তারা ভালভাবে বোঝা যায়। সমাধির পাথর ফাইলের নীচের লগগুলি আসলে কি ঘটেছে তার একটি ইঙ্গিত প্রদান করতে পারে। অন্যথায়, সিঙ্ক মোডে ত্রুটিটি পুনরুত্পাদন করা এবং সিঙ্ক মোড প্রদান করে এমন আরও ভাল ডায়াগনস্টিক ব্যবহার করা প্রস্তাবিত পদক্ষেপ!
উন্নত বিষয়
হুডের অধীনে, মেমরি ট্যাগিং প্রতিটি হিপ বরাদ্দের জন্য একটি এলোমেলো 4-বিট (0..15) ট্যাগ মান নির্ধারণ করে কাজ করে। এই মানটি একটি বিশেষ মেটাডেটা অঞ্চলে সংরক্ষণ করা হয় যা বরাদ্দ করা হিপ মেমরির সাথে মিলে যায়। malloc() বা অপারেটর new() এর মতো ফাংশন থেকে ফিরে আসা হিপ পয়েন্টারের সবচেয়ে উল্লেখযোগ্য বাইটে একই মান নির্ধারণ করা হয়।
যখন প্রক্রিয়ায় ট্যাগ চেকিং সক্ষম করা হয়, তখন CPU স্বয়ংক্রিয়ভাবে পয়েন্টারের উপরের বাইটটিকে মেমরি ট্যাগের সাথে প্রতিটি মেমরি অ্যাক্সেসের জন্য তুলনা করে। যদি ট্যাগগুলি মেলে না, CPU একটি ত্রুটির সংকেত দেয় যা একটি ক্র্যাশের দিকে পরিচালিত করে।
সম্ভাব্য ট্যাগ মানগুলির সীমিত সংখ্যক কারণে, এই পদ্ধতিটি সম্ভাব্য। যেকোন মেমরি অবস্থান যা একটি প্রদত্ত পয়েন্টার দিয়ে অ্যাক্সেস করা উচিত নয় - যেমন সীমার বাইরে, বা ডিললোকেশনের পরে ("ড্যাংলিং পয়েন্টার") - একটি ভিন্ন ট্যাগ মান থাকতে পারে এবং একটি ক্র্যাশ হতে পারে৷ একটি বাগ এর কোনো একক ঘটনা সনাক্ত না করার একটি ~7% সম্ভাবনা রয়েছে৷ যেহেতু ট্যাগ মানগুলি এলোমেলোভাবে বরাদ্দ করা হয়েছে, তাই পরের বার এটি ঘটলে বাগ সনাক্ত করার একটি স্বাধীন ~93% সম্ভাবনা রয়েছে৷
ট্যাগের মানগুলি ফল্ট অ্যাড্রেস ফিল্ডের পাশাপাশি রেজিস্টার ডাম্পে দেখা যেতে পারে, যেমনটি নীচে হাইলাইট করা হয়েছে। এই বিভাগটি ট্যাগগুলি একটি বুদ্ধিমান উপায়ে সেট করা হয়েছে কিনা তা পরীক্ষা করতে এবং একই ট্যাগ মান সহ অন্যান্য কাছাকাছি মেমরি বরাদ্দগুলি দেখতে ব্যবহার করা যেতে পারে কারণ তারা রিপোর্টে তালিকাভুক্তগুলির বাইরে ত্রুটির সম্ভাব্য কারণ হতে পারে৷ আমরা আশা করি যে এটি মূলত ডেভেলপারদের পরিবর্তে MTE নিজেই বা অন্যান্য নিম্ন-স্তরের সিস্টেম উপাদানগুলির বাস্তবায়নে কাজ করা লোকেদের জন্য কার্যকর হবে।
signal 11 (SIGSEGV), code 9 (SEGV_MTESERR), fault addr 0x0800007ae92853a0 Cause: [MTE]: Use After Free, 0 bytes into a 32-byte allocation at 0x7ae92853a0 x0 0000007cd94227cc x1 0000007cd94227cc x2 ffffffffffffffd0 x3 0000007fe81919c0 x4 0000007fe8191a10 x5 0000000000000004 x6 0000005400000051 x7 0000008700000021 x8 0800007ae92853a0 x9 0000000000000000 x10 0000007ae9285000 x11 0000000000000030 x12 000000000000000d x13 0000007cd941c858 x14 0000000000000054 x15 0000000000000000 x16 0000007cd940c0c8 x17 0000007cd93a1030 x18 0000007cdcac6000 x19 0000007fe8191c78 x20 0000005800eee5c4 x21 0000007fe8191c90 x22 0000000000000002 x23 0000000000000000 x24 0000000000000000 x25 0000000000000000 x26 0000000000000000 x27 0000000000000000 x28 0000000000000000 x29 0000007fe8191b70 lr 0000005800eee0bc sp 0000007fe8191b60 pc 0000005800eee0c0 pst 0000000060001000
ক্র্যাশ রিপোর্টে একটি বিশেষ "মেমরি ট্যাগ" বিভাগও উপস্থিত হয় যা ত্রুটি ঠিকানার চারপাশে মেমরি ট্যাগ দেখায়। নীচের উদাহরণে, পয়েন্টার ট্যাগ "4" মেমরি ট্যাগ "a" এর সাথে মেলেনি।
Memory tags around the fault address (0x0400007b43063db5), one tag per 16 bytes: 0x7b43063500: 0 f 0 2 0 f 0 a 0 7 0 8 0 7 0 e 0x7b43063600: 0 9 0 8 0 5 0 e 0 f 0 c 0 f 0 4 0x7b43063700: 0 b 0 c 0 b 0 2 0 1 0 4 0 7 0 8 0x7b43063800: 0 b 0 c 0 3 0 a 0 3 0 6 0 b 0 a 0x7b43063900: 0 3 0 4 0 f 0 c 0 3 0 e 0 0 0 c 0x7b43063a00: 0 3 0 2 0 1 0 8 0 9 0 4 0 3 0 4 0x7b43063b00: 0 5 0 2 0 5 0 a 0 d 0 6 0 d 0 2 0x7b43063c00: 0 3 0 e 0 f 0 a 0 0 0 0 0 0 0 4 =>0x7b43063d00: 0 0 0 a 0 0 0 e 0 d 0 [a] 0 f 0 e 0x7b43063e00: 0 7 0 c 0 9 0 a 0 d 0 2 0 0 0 c 0x7b43063f00: 0 0 0 6 0 b 0 8 0 3 0 0 0 5 0 e 0x7b43064000: 0 d 0 2 0 7 0 a 0 7 0 a 0 d 0 8 0x7b43064100: 0 b 0 2 0 b 0 4 0 1 0 6 0 d 0 4 0x7b43064200: 0 1 0 6 0 f 0 2 0 f 0 6 0 5 0 c 0x7b43064300: 0 1 0 4 0 d 0 6 0 f 0 e 0 1 0 8 0x7b43064400: 0 f 0 4 0 3 0 2 0 1 0 2 0 5 0 6
একটি সমাধির পাথরের অংশ যা সমস্ত রেজিস্টার মানগুলির চারপাশে মেমরি বিষয়বস্তু দেখায় তাদের ট্যাগ মানগুলিও প্রদর্শন করে।
memory near x10 ([anon:scudo:primary]): 0000007b4304a000 7e82000000008101 000003e9ce8b53a0 .......~.S...... 0700007b4304a010 0000200000006001 0000000000000000 .`... .......... 0000007b4304a020 7c03000000010101 000003e97c61071e .......|..a|.... 0200007b4304a030 0c00007b4304a270 0000007ddc4fedf8 p..C{.....O.}... 0000007b4304a040 84e6000000008101 000003e906f7a9da ................ 0300007b4304a050 ffffffff00000042 0000000000000000 B............... 0000007b4304a060 8667000000010101 000003e9ea858f9e ......g......... 0400007b4304a070 0000000100000001 0000000200000002 ................ 0000007b4304a080 f5f8000000010101 000003e98a13108b ................ 0300007b4304a090 0000007dd327c420 0600007b4304a2b0 .'.}......C{... 0000007b4304a0a0 88ca000000010101 000003e93e5e5ac5 .........Z^>.... 0a00007b4304a0b0 0000007dcc4bc500 0300007b7304cb10 ..K.}......s{... 0000007b4304a0c0 0f9c000000010101 000003e9e1602280 ........."`..... 0900007b4304a0d0 0000007dd327c780 0700007b7304e2d0 ..'.}......s{... 0000007b4304a0e0 0d1d000000008101 000003e906083603 .........6...... 0a00007b4304a0f0 0000007dd327c3b8 0000000000000000 ..'.}...........